리팩토링 : 코드 정리를위한 멋진 단어가 아닌가? [닫은]

Martin Fowler의 저서 "리팩토링 : 기존 코드의 디자인 개선"이 나오기 전에 우리는 코드 "아키텍처"와 사소한 변경 "정리"에 대한 주요 변경 사항을 호출했습니다. 리팩토링 기술인 IMO는 우리가 영원히 해왔 던 상식적인 일입니다.

리팩토링이 새로운 것이라 생각하십니까? 아마도 코드 정리 시간을 할당하도록 관리를 속일 수있는 방법일까요?

리팩토링은 언덕보다 나이가 많기 때문에 새로운 것은 아닙니다.

리팩토링은 정리되지 않습니다. 글쎄, 가능하지만 청소에만 국한되지는 않습니다.

동작을 유지하면서 응용 프로그램의 아키텍처 (대규모 또는 소규모)를 조정합니다.

즉, 애플리케이션의 일부가 어제 완벽하게 깨끗하고 훌륭했지만 오늘날의 새로운 기능은 새로운 기능에 맞게 해당 부분을 조정해야합니다.

기존 기능을 중단하고 싶지 않으므로 리팩토링 인 동작을 유지하면서 애플리케이션 구조를 조정합니다.

이것은 코드에 어떤 변화가 있더라도 항상 테스트를 실행해야한다는 것입니다.

코드를 정리하는 중입니다. 본질적으로 프로그래머 (특히 Martin Fowler)는 코드를 정리할 때마다 동일한 작업을 수행하는 경향이 있음을 알았습니다. 그들은 깔끔한 방법과 관련된 코드 문제와 프레스토를 정의하고 표시했습니다! 리팩토링이 탄생했습니다.

디자인 패턴과 동일합니다. 사람들은 특정 문제에 대해 동일한 접근 방식을 반복해서 사용하는 경향이 있음을 알게되었습니다. 그들은 접근 방식에 레이블을 지정하고 정의했으며 이제는 코드에서 수십 가지 패턴을 사용하지 않는 한 실제 프로그래머가 아닌 것 같습니다.

리팩토링에는 마술이 없습니다. 그것은 오래된 관행을 설명하는 새로운 전문 용어입니다.

우리는 회사에서 세 가지 별도의 작업을 수행하고 세 가지에 시간을 할당합니다.

• 리팩토링 : 코드 구조를 변경하여 동작을 유지합니다.

예 : 네 가지 작업을 수행하는 추악하고 읽을 수없는 100 줄 방법을 각각 25 줄씩 4 개의 재사용 가능한 방법으로 나누기

• 정리 : 동작이나 구조를 수정하지 않고 코드를 더 읽기 쉽게하기 위해 약간 수정하는 작업으로 구성됩니다.

예 :이 코드가 더 이상 필요하지 않은지 확인한 후 주석이 달린 코드를 제거하십시오.

• StyleCop / FxCop 규칙 적용 : 코드가 기본 StyleCop 또는 FxCop 규칙 집합과 일치하는지 확인하고 그렇지 않은 경우 해당 규칙과 일치하도록 수정합니다.

예 : 추가 Culture.Invariant의 string.Format(또는 더 적합한 다른 배양).

따라서 필자의 경우 리팩토링은 정리와 매우 다릅니다 . 정리 작업을 수행 할 때, 난 다시는 단위 테스트를 실행할 필요가 없습니다 : 코드 이전 일 경우, 그것은 것입니다 정리 한 후 작동합니다. 즉, 빈 줄을 제거하거나 코드 작동을 멈출 것이라는 주석을 추가했기 때문이 아닙니다. 반면에, 오래된 코드의 복잡한 부분을 리팩터링하면 실수를 할 수 있으므로 리팩토링 후에 단위 테스트를 실행해야합니다.

리팩토링은 코드에 지식을 추가합니다. 이름이 잘못되었다는 것을 알고 있다면 더 나은 이름을 지정하십시오. 더 잘할 수있는 것을 알고 있다면 더 좋은 것으로 바꿉니다.

더 나은 프로그램을 만들기 위해 작고 큰 단계가 많이 있습니다.

나는 "리팩토링은 코드를 정리하기위한 멋진 단어"에 동의하지만 "그냥"이 아니라 사람들은 이유를 위해 멋진 단어를 사용합니다. 때로는 영리 해 보이고 싶거나 때로는 더 크고 정확한 의미를 전달하기 때문에 IMHO 리팩토링 (때때로 잘못 사용하더라도)이 후자를 의미합니다.

"정리"는 "비트 재 포맷"에서 "큰 청크 재 작성"에 이르기까지 모든 것을 의미 할 수 있습니다.

"리팩토링"은 구체적으로 "코드를 조금씩 변경하고 동일한 기능을 유지하면서 더 나은 디자인으로 변환하도록 설계된 것"과 같은 것을 의미합니다. 그리고 당신이하는 일에 대한 모범 사례가 있습니다. 일부는 임시적이지만 단위 테스트 사용, 새로운 기능이나 클래스로 함수의 일부 추출 등 사람들이 배울 수 있고 배우는 일반적인 원칙이 있습니다. .

"코드 정리를위한 시간 할당으로 관리를 속이십시오"라고 말합니다. 그러나 "리팩토링"이라고 말하면 명확성에 대한 꾸준한 투자가 이제 미래의 효율성 배당금을 지불 할 것이라는 개념을 올바르게 전달한다면 이는 "속임수"가 아니라 명확하고 효과적인 의사 소통입니다.

리팩토링은 정규화가 관계형 데이터에 대한 것이므로 코딩하는 것입니다. 응용 프로그램에서 개념을보다 명확하고 명확하며 효율적으로 표현하는 과정입니다.

용어 리팩토링을 이해하는 방법에 따라 다릅니다. 대부분의 사람들에게 이것은 행동을 바꾸지 않고 구조를 개선하는 과정입니다. 동의한다면,이 책이 나오기 오래 전에 이루어졌습니다. 나는 (다른 많은 것들 중에서도) 책을 쓰기 전에 수업의 이름을 바꾸고 수업을 추출하고 분석법을 추출했기 때문에 알고 있습니다. 리팩토링이라고 부르지는 않았지만 본질적으로 정확히 똑같은 일을하고있었습니다.

개인적으로 리팩토링은 사람들이 현재 "자동화 된 코드 리팩토링"이라고 부르는 것입니다. 즉, IDE 내에서 다양한 리팩토링 기술을 지원합니다. 이것은 내가 전에하고 있었던 것에 대한 진정한 개선입니다 (실제로 매우 고통 스럽습니다). 한 클래스에서 변경을 수행 할 수 있으며 이것이 나머지 소프트웨어에 어떤 영향을 미칠지 걱정하지 않아도됩니다. Martin은 리팩토링 기술을 알고리즘으로 표현하여 다양한 IDE에서 구현할 수있는 시점까지 공식화했다고 생각합니다.

따라서 리팩토링을 프로세스로 이해하면 새로운 것이 아닙니다. 자동화라고 생각하면 크게 개선됩니다. 합리적으로 큰 프로젝트에서 몇 가지 핵심 클래스의 이름을 바꾸어 (문자 그대로, IDE의 리팩토링 옵션을 사용하지 않음) 이유를 확인하십시오.)

리팩토링은 실제로 코드 "정리"이지만 코드를 재구성하는 것입니다. 우리 팀에서는 리팩토링이 보통 후자입니다. "리 팩터"사례가있는 경우 코드를 새로운 아키텍처 나 정보 모델과 일치 시키거나보다 효율적으로 만들기 위해 코드를 재구성 할 시간을 할당합니다.

코드 "정리"는 특별히 할당 된 시간없이 지속적으로 수행하는 작업입니다. 나를 위해 "정리"는 일반적으로 이름을 바꾸거나 주석을 정리하는 등입니다.

나는 아니오라고 말할 것입니다.

리팩토링 프로세스에 정리가있을 수 있지만 본질이 아닙니다.

정리 는 이전 코드가 깨끗하지 않다는 가정하에 제공됩니다. 실제로 개발자는 원래 코드가 이미 깨끗하더라도 코드를 리팩터링합니다.

DRY 는 리팩토링의 핵심 요소입니다.

기존 코드베이스에 새 코드를 추가 할 때 DRY 원칙으로 인해 리팩토링이 자연스럽게 수행됩니다.

그냥 내 0.02

코드를 정리하는 것은 집을 정리하는 것과 같습니다. 리팩토링은 벽을 찢고 다른 곳에 놓는 것과 같습니다.

다른 사람이 집을 청소할 때 목표는 물건을 깨끗하게 정리하는 것이므로 아무것도 찾을 수 없습니다. 리팩토링은 방, 옷장, 캐비닛, 선반, 쓰레기통 등을 짓고 라벨을 붙일 것입니다. 여전히 같은 물건을 대부분 보유하고 있습니다 (부엌에서 구운 치즈 샌드위치를 ​​만들고 거실에서 먹을 수는 있습니다). 쉽게 찾을 수 있고 새로운 물건을 넣을 수있는 효율적인 장소가 있습니다.

'리팩토링'이라는 용어는 대수에서 우아하게 차용되었습니다. 이는 용어를 단순화하여 동일한 결과를 생성 함을 의미합니다. 우아 할뿐만 아니라 혁신적이었습니다. 많은 사람들을 놀라게 한 수준에서 코드에 대한 유한 한 접근 방식이 필요했습니다. 그래서 그 용어 자체는 중요하고 도움이되었습니다.

리팩토링은 동작을 변경하지 않고 구조를 개선하고 있습니다. 엄격한 의미에서 리팩토링은 우수한 테스트 규칙을 수반합니다. "정리"할 때 반드시 필요한 것은 아닙니다.

둘은 가장자리에서 약간 겹치지 만 집 청소와 집 개조의 차이점입니다. 정리는 리팩토링이 수행하는 동안 구조적 변경을 의미하지는 않습니다.

"리팩토링"은 실제로 "아키텍처"와 동일하지만 "기능 변경 없음"이라는 의미가 더 강력합니다. 또한 일반적인 아키텍처를 재사용 가능한 청크로 "계산"하는 구조 변경의 관점에서 더 명확합니다.