리팩토링시기

나는 Fowler 's Refactoring 책의 대부분을 읽었으며 과거의 크고 작은 많은 응용 프로그램을 리팩토링했습니다.

내가 가르치기 어려운 것들 중 하나는 "언제나"리팩토링하는 것입니다. 나는 과거에 놀랍게도 잘 맞는 직감에 근거하여 이것을하는 경향이있다. 그러나 코드 조각을 단독으로 남겨 두어야하는지 아니면 리팩터링해야하는지에 대해 사람들과 토론 할 때 "장 점검"을 지키기가 어렵습니다.

나는 이것에 대해 더 엄격한 접근법이 있어야한다고 생각하지만 그것이 무엇인지 확실하지 않습니다.

나는 "코드 냄새", 적 록색 리 팩터 및 기타 생각을 이해하지만, 리팩터링하기 가장 좋은 시간은 처음 코드를 작성할 때가 아니라 코드를 사용하고 두 번째 또는 세 번째로 생각하는 것입니다. 실제로 문제이며 실제로 사용되고 있습니다.

리팩토링 리팩토링의 비용은 비용보다 작을 때 하지 리팩토링.

그러나 "비용"을 측정하십시오. 예를 들어 코드가 제대로 구현되지 않아 사소한 버그를 수정하는 데 몇 시간 또는 며칠이 걸립니까? 리팩토링을 통해 더 많은 고객을 확보하거나 용량을 늘리거나 성능을 개선하여 기존 고객을 더 행복하게 만들 수 있습니까?

1. 함수 의 순환 복잡도 가 5 미만입니까?
2. 그 링크를 따르지 않고 순환 적 복잡성이 무엇인지 완전히 이해 했습니까?
3. 기능을 통한 모든 경로에 대해 자동화 된 테스트 또는 문서화 된 테스트 사례가 있습니까?
4. 기존 테스트 사례가 모두 통과됩니까?
5. 1 분 이내에 기능과 모든 주요 사례를 설명해 주시겠습니까?
6. 그렇지 않은 경우 약 5 분이 소요됩니까?
7. 10 분?
8. 함수에 주석이 포함 된 100 줄 미만의 코드가 있습니까?
9. 육안 검사만으로이 코드에 오류가 없다고 동의하는 다른 두 명의 개발자를 찾을 수 있습니까?
10. 이 기능은 한 곳에서만 사용됩니까?
11. 기능이 성능 목표 (시간 / 메모리 / CPU)를 충족합니까?

채점

위의 "아니오"답변을 추가하십시오.

• 0-1-왜 리팩토링에 대해 생각하겠습니까? 이전 개발자의 명명 규칙이 마음에 들지 않기 때문에 변수 이름을 바꾸고 싶을 것입니다.
• 2-5-약간의 조정이 필요할 수 있지만이 범위의 제품에 대한 프로덕션 릴리스는 유지하지 않습니다.
• 6-8-알겠습니다. 아마도이 문제를 해결해야 할 것입니다. 우리는 이것을 계속 다시 검토 할 것입니다. 여전히 울타리에 있지만, 그것은 매우 용의자입니다
• 9+-리팩토링의 주요 후보입니다. (테스트 케이스 작성은 리팩토링의 한 형태입니다)

당신의 직감이 아마도 당신이 아마도 리팩토링을해야한다고 말하고있을 때, 당신이 너무 늦게 당신이 너무 중요한 것을 버리고 있다고 말하는 것은 당신의 본능 일 것입니다.

나는 "코드 냄새", 적 록색 리 팩터 및 기타 생각을 이해하지만, 리팩터링하기 가장 좋은 시간은 처음 코드를 작성할 때가 아니라 코드를 사용하고 두 번째 또는 세 번째로 생각하는 것입니다. 실제로 문제이며 실제로 사용되고 있습니다.

리팩토링에는 두 가지 수준이 있습니다. 첫 번째는 처음 코딩 할 때 나타나는 명백한 문제입니다. 이것들은 선행 비용이 거의 들지 않는 작은 최적화입니다. 메소드와 클래스를 작게 유지하고 DRY 및 SRP를 준수하는 것과 같은 것들. 그런 다음 디자인의 주요 결함을 처리하는 추가 단계가 있으며, 코드가 2 마일이 될 때까지는 분명하지 않을 수 있습니다. 이 두 번째 단계는 당신이 말하고 있지만, 나중에 리팩토링이 너무 비싸지 않도록하기 위해 나중에 구상하려는 노력이 쉽고 비용이 적게 드는 방식으로 코드를 작성해야합니다. 이는 초기 리팩토링을 의미합니다.

Jeff가 자신의 답변에서 언급했듯이 , 특히 작업량이 많고 위험이 더 높은 회사에서 "시간은 돈입니다" . 코드가 가능한 최상의 상태에 있는지 확인하는 데 소요되는 시간은 나중에 쉽게 리팩토링해야했던 내용을 알아볼 때 시간이 절약되는 것입니다.

소프트웨어를 작성할 때 코드를 개선하는 데 소요되는 모든 시간은 나중에 필요할 때 절약 할 수 있습니다. 리팩토링이 빠를수록 나중에 변경되는 것이 더 명확 해집니다. 미래의 기술 부채에 대해 오늘 달러로 계약금을내는 것과 같습니다.

어쨌든 리팩토링은 소프트웨어가 이미 완벽하고 안정적 ​​일 때 신비한 미래가 될 때까지 연기해야 ​​할 일이 아닙니다. 나중에 말뚝이 훨씬 높고 제품을 변경하기가 훨씬 어려울 때 위험이 증가하기 때문입니다. 리팩토링은 일상 활동의 일부 여야하며 이것이 언급 한 Red-Green-Refactor 철학의 본질입니다.

귀하의 질문은 각 개발자 및 프로그래밍 담당 관리자에 의해 다르게 답변 될 수 있다고 생각합니다.

개인적으로 선호하는 것은 새로운 것을 배우거나 모범 사례를 개선 할 때마다 가능한 코드를 리팩터링하는 것입니다. 해당 상황에 가장 적합한 표준이 무엇인지 배우 자마자 코드를 표준으로 유지하고 싶습니다. 동일한 소프트웨어를 오랫동안 사용하는 소규모 회사이기 때문에이 작업을 수행 할 수 있습니다.

시간이 돈이 큰 더 큰 소프트웨어 개발 회사에서는이 시점에서 배운 더 나은 방법으로 설계를 시작하는 것이 좋을 것입니다. 특정 소프트웨어의 버전 2까지 리팩토링에 대해 걱정하지 마십시오.

리팩토링시기를 가르치는 것이 실제로 현재 회사에 달려 있다고 생각합니다.

"리팩터링시기?"

짧은 대답 : 냄새가 나거나 개선 될 수있는 코드를 발견 할 때마다 ( Boy Scout Rule )

실제로, 이것은 일어난다 :

• TDD주기의 리 팩터 단계에서 체계적으로 TDD를 연습하는 경우, 즉 테스트가 녹색이되고 새 테스트를 작성하기 전에.
• 코드 검토 결과
• 레거시 코드를 인계 할 때
• 어색하게 설계된 코드를 사용할 때
• 기타

리팩토링에 대해 처음 알게되었을 때, 멘토가 말했습니다 : "두 번, 코를 잡고, 세 번, 리팩토링." (고마워요, Josh!) 구체적으로 말하면, 당신이 세 번째로 같은 코드 블록을 작성하려고 할 때 (또는 비슷한 코드 패턴) 리팩토링 할 때입니다. 나는 지난 10 년 동안 그것을 따랐으며, 그것이 충분히 경험할 수있는 소리라는 것을 알았습니다.

강력한 리팩토링 지원 기능이있는 Eclipse 또는 유사한 IDE를 사용하면 리팩토링을 수행하는 노력이 줄어 듭니다. IDE 지원을 통해 추가 노력으로 보지 않고 "제 3 회"를 맞이하자마자 리팩토링 할 가능성이 높아집니다.

또한 TDD는 리팩토링으로 테스트를 계속 실행할 수 있으며 아무런 문제가 없음을 알기 때문에 큰 도움이됩니다.

정의에 의한 리팩토링은 프로세스입니다. 즉, 리팩토링 작업을 수행 할 여가 시간을 찾기 위해 노력하지 말고 더 잘 작성할 수있는 코드 코드를 발견 할 때마다 항상 리팩토링을 유지해야합니다.

개인적으로 저는 진화적인 프로토 타입을 작성하는 것이 더 간단하다고 말합니다. 작동하는 코드와 예상 코딩 표준을 충족 할 때까지 리팩토링합니다. 또 다른 좋은 예는 기능을 추가하고 기존 코드를 리팩터링하여 재사용 할 수 있도록하는 것입니다.

20 년간의 프로그래밍 과정에서 사람들이 고수 할 수 있고 관리자가 시간을 할애 할 수있는 유일한 경험 법칙이 있습니다. 리팩토링은 다이어트와 같습니다. "칼로리 / 칼로리 부족"은 체중 감량의 공식이지만 사람들이 준수 할 다이어트로 해석되지는 않습니다.

작업하면서 지속적으로 리팩토링하십시오. 하루 종일 여러 빨강-녹색 리 팩터 주기를 갖도록 테스트 주도 개발을 사용하십시오 . 터치 한 코드 부분 만 리팩토링하십시오.

자신을 더 확신하면이 요법과 다를 수 있습니다.

프로젝트 소유자와 코드의 품질에 대한 답변을 요구하는 사람의 요구에 달려 있다고 생각합니다. 다른 사람의 돈이 문제가 될 때 당신은 단순히 그것을 결정할 수 없습니다.

기술적 인 이유로 여러 가지가 있습니다.

• 코드에 버그가있는 경우이 장소를 잘못 이해했으며 여기에 더 많은 오류가 숨겨 질 가능성이 매우 높으며 연결된 코드 부분을 개발하려는 시도에 큰 문제가있을 수 있습니다. 따라서이 장소는 리팩토링이 가능한지 확인해야합니다.
• 또 다른 이유는 기능을 추가하거나 변경할 때 이전 코드가 변경 / 추가에 매우 불편하고 나중에 변경 / 추가 할 수 있기 때문입니다. 물론 비용의 균형을 유지해야합니다.
• 아마도 가장 심각한 이유는 코드를 변경하고 테스트 할 수없는 경우입니다.