새로운 기능에 중점을 둔 프로젝트에서 깨지지 않은 기존 코드를 리팩터링해야합니까?

응용 프로그램에 새로운 기능을 추가하려는 소규모 프로젝트를 감안할 때 도입 된 변경 사항은 특정 영역의 코드 업데이트와 관련된 일부 기존 코드에 영향을줍니다. 구현하는 동안 업데이트 된이 코드 중 일부를 리팩토링 후보로 찾았습니다.

영향을받는 구성 요소에 대한 회귀 테스트가 필요한 리팩토링에 적합한 시간입니까 (따라서 원래 프로젝트의 일부가 아닌 범위를 도입 할 가능성이 있습니까)? 아니면 기능을 연기하고 완성해야하며 리팩토링을위한 별도의 프로젝트가 있어야합니다 (비즈니스 사용자가 코드 유지 관리 기능을 중요시하지 않는 한 기능을 추가하지 않는 프로젝트를 완전히 후원하지 않을 수도 있기 때문에 조금 주저하지만)?

물론.

리팩토링은 작업중인 "통과"프로젝트에서 수행해야합니다. 모든 테스트 (단위, 시스템 및 합격 수준)가 통과하면 제품이 요구 사항을 충족한다는 것을 알 수 있습니다. 리팩토링하면 모든 테스트가 계속 통과하는지 계속 확인할 수 있습니다. 테스트가 실패하기 시작하면 문제가있는 것이므로 수정해야합니다. 테스트에 실패한 경우 리팩토링하기 전에 리팩토링이 시스템 기능을 변경하지 않도록 항상 리팩토링하기 전에 수정해야합니다.

또한 리팩토링을 수행하고 시간과 예산을 계속 제공 할 시간과 리소스가 있다고 가정하면 리팩토링을하기에 완벽한 시간입니다. 이제 리팩토링을 통해 시스템을보다 쉽게 ​​이해하고 유지 관리 할 수 ​​있으므로 더 많은 새로운 기능을 추가할수록 더욱 쉬워집니다. 코드 썩음 및 소프트웨어 엔트로피 와 싸워야 합니다 .

Joel Etherton 이 의견에서 지적한 것처럼 리팩토링 범위를 관리해야합니다. 곧 기능을 추가 할 시스템 부분의 리팩토링에 초점을 맞추고 리팩토링을 수행하여 새로운 기능을보다 쉽게 ​​작업하거나 추가 할 수 있습니다. 정적 분석, 메트릭 도구 및 코드 검토를 사용하면 가장 중요한 영역을 식별 할 수 있습니다. 리팩토링을했기 때문에 마감일을 놓치지 않으려면 계속해서 고객에게 가치를 더해야합니다.

리팩토링에 가치가없는 고객을 언급했습니다. 일반적으로 고객은 코드의 품질이 아니라 제품의 품질에 관심이 있습니다. 리팩토링을 사용하면 높은 품질의 제품을 유지하고 변화하는 고객 요구에 맞는 제품을 계속 제공 할 수 있습니다. 일정에 따라 리팩토링 할 시간을 협상하십시오 (고객은 Y 일 동안 X 기능을 원하고 Y + Z 일 또는 XN 기능을 얻을 수 없는지 확인하여 디자인, 리팩토링 및 구현에 시간을 소비 할 수 있는지 확인) 할 수있다.

아래 질문에 답해보십시오. 그러면 결정을 내리기가 쉬울 것입니다. "깨지지 않으면 고치지 말라"는 지혜는 유혹적이지만 항상 전문적인 업무에 적용되는 것은 아닙니다.

0-이 코드에 대한 고객 불만이 있습니까?

1- 응용 프로그램 기능에 필요합니까?

2- 현재 코드는 유해합니까?

3- 변화의 비용은 가치가 있습니까?

4 비용을 감당할 수 있습니까?

5 이것이 조직에 귀하의 기술을 가장 잘 활용하는 것입니까?

6-변경 사항으로 인해 사용자가 새 변경 사항을 다시 설치해야합니까? 고객에게 해당 사항을 정당화 할 수 있습니까?

7- 잘못된 수정의 위험을 감수 할 수 있습니까?

8- 변경 사항이 프로젝트 외부의 다른 코드에 영향을 줍니까?

9-이 제품은 진화하는 제품입니까, 안정적인 제품입니까? 진화하고 있다면 다음 릴리스에 변경 사항을 포함시킬 수 있습니까?

곧 리팩토링하고 자주 리팩토링하십시오.

여유가 있다면 (시간, 돈 등)해야합니다.

때로는 시간이 부족하거나 코드 유지 보수 개입을 위해 돈을 얻지 못하거나 가능한 한 빨리 프로젝트를 완료하고 싶다고 생각하기 때문에 리팩토링에 리소스가 필요하기 때문에 이것을 말합니다. 그러나 그 외에는 항상 리팩토링하기에 좋은 시간입니다.

최신 코드를 원하고 특히 새로운 기능을 추가 할 때 코드에 실제로 일부 변경이 필요하다고 생각되면 변경해야합니다.

버전 제어 시스템을 사용하면 실제로 프로젝트를 새로운 브랜치로 포크 할 수 있으므로 현재 코드에 전혀 영향을 미치지 않습니다.

새로운 기능을 구현하기 위해 리팩토링이 필요한 경우 새로운 개발의 일환으로 리팩토링을 수행하고 고려해야합니다.

코드가 중복되면 편집이 다른 곳이 아닌 한 곳에서 수행되므로 장기적으로 비용이 많이 듭니다 (개인 및 회사 모두).

기존 기능에 문제가 발생하지 않았 음을 입증 할 수있는 자동화 된 단위 테스트 또는 회귀 테스트와 같은 일련의 테스트가 필요합니다.

리팩토링이 "행하기에 좋은"것이라면, 즉 새로운 기능에 의해 직접 영향을받는 코드가 아니라면 그대로 두겠습니다. 변화를 위해 변화를 소개하고 있습니다.

코드를 리팩터링하면 새로운 기능을 쉽게 추가 할 수 있습니다. 이것이 이론입니다. 새로운 기능의 범위에 이것을 포함하십시오. 이런 방식으로 비즈니스 사용자로부터 바이 인을 얻을 가능성이 높습니다. 이 경우, 당신은 매력적인 논쟁을하고 리팩토링을위한 시간을 정당화 할 수 있어야합니다. 이들이 개발 과정에서 필요한 부분이며 이의 제기가 적다는 것을 이해하기를 바랍니다. 이 직접적인 혜택을 항상 증명할 수있는 것은 아닙니다.