코드 유지 관리 : 일관성을 유지하기 위해 새 코드를 확장 할 때 나쁜 패턴을 유지합니까?

프로젝트의 기존 모듈을 확장해야합니다. 나는 그 방식이 마음에 들지 않습니다 (복사 / 붙여 넣기 코드와 같은 많은 안티 패턴 관련). 여러 가지 이유로 완전한 리팩터링을 수행하고 싶지 않습니다.

내가해야합니까 :

• 기존 관리자가 잘못 생각하더라도 다음 관리자에게 혼란을주지 않고 코드베이스와 일관성을 유지하기 위해 기존 규칙을 사용하여 새로운 메소드를 작성합니까?

또는

• 코드에 다른 패턴을 도입하더라도 기분이 좋은 것을 사용하려고합니까?

첫 번째 답변 후 Precison이 편집되었습니다.

기존 코드는 엉망이 아닙니다. 따르고 이해하기 쉽습니다. 그러나 좋은 디자인으로 피할 수있는 많은 상용구 코드를 도입하고 있습니다 (결과 코드는 따르기가 어려워 질 수 있습니다). 내 현재의 경우 좋은 오래된 JDBC (스프링 템플릿 내장) DAO 모듈이지만 이미이 딜레마에 빠졌고 다른 개발자 피드백을 찾고 있습니다.

시간이 없어 리팩토링하고 싶지 않습니다. 그리고 시간이 지나도 완벽하게 작동하는 모듈 전체에 리팩토링이 필요하다는 것을 정당화하기는 어렵습니다. 리팩토링 비용은 그 이점보다 더 클 것입니다. 기억하십시오 : 코드는 지저분하거나 복잡하지 않습니다. 나는 거기에 몇 가지 메소드를 추출 할 수 없으며 여기에 추상 클래스를 소개합니다. 디자인에 결함이 있습니다 (극단적 인 'Keep It Stupid Simple'의 결과라고 생각합니다)

따라서 질문은 다음과 같이 질문 할 수도 있습니다.
개발자는 어리석은 지루한 코드를 유지하거나 어리석은 지루한 코드를 수행 할 도우미를 원하십니까?

마지막 가능성의 단점은 몇 가지 내용을 배우고 전체 리팩토링이 완료 될 때까지 쉬운 바보 지루한 코드를 유지해야 할 수도 있다는 것입니다)

리팩토링은 작은 단계로 수행하는 것이 가장 좋으며 코드를 커버하기 위해 단위 테스트가있는 경우에만 수행하는 것이 좋습니다. (아직 테스트를하지 않은 경우 먼저 테스트를 작성하려고 노력한 다음 그때까지 가장 단순하고 가장 무차별적이고 자동화 된 리팩토링을 고수하십시오. 이에 대한 큰 도움은 Michael Feathers의 레거시 코드 로 효과적으로 작업하는 것 입니다.)

일반적으로 코드를 만질 때마다 코드를 약간 향상시키는 것이 목표입니다. 찾은 것보다 코드를 더 깔끔하게 유지 하여 보이 스카우트 규칙 ( Robert C. Martin이 만든)을 따르십시오 . 새 코드를 추가 할 때는 기존 불량 코드와 분리하여 유지하십시오. 예를 들어 긴 메소드의 중간에 묻지 말고 별도의 메소드에 대한 호출을 추가하고 새 코드를 거기에 넣으십시오. 이런 식으로 기존 코드베이스 내에서 더 큰 청정 (er) 코드 섬을 점진적으로 성장시킵니다.

최신 정보

리팩토링 비용은 그 이점보다 더 클 것입니다. [...] 개발자로서, 당신은 쉬운 바보 지루한 코드를 유지하거나 당신의 장소에서 바보 지루한 코드를 수행하는 도우미를 원하십니까?

나는 이것이 내가 핵심이라고 믿는 것을 강조했다. 리팩토링의 비용과 이점을 평가 하기 전에 항상 평가할 가치가 있습니다. 귀하의 경우와 마찬가지로 대부분의 리팩토링 리소스는 제한되어 있으므로 현명하게 사용해야합니다. 최소한의 노력으로 가장 많은 이점을 얻는 리팩토링에 소중한 시간을 보내십시오.

창의적인 마음으로, 물론 완벽하고 아름답고 우아한 코드를 생성하고 나의 이상과 닮지 않은 모든 것을 다시 작성하는 것을 선호합니다 :-) 실제로, 나는 사용자의 실제 문제를 해결하는 소프트웨어를 생산해야합니다. 장기적으로 돈의 가치를 극대화하는 것에 대해 생각해야합니다.

리팩토링의 이점은 코드를 장기적으로 이해, 유지, 수정 및 확장하기위한 시간과 노력이 충분히 절약 된 경우에만 나타납니다 . 따라서 코드 조각-그러나 추악한 경우-거의 또는 전혀 손대지 않은 경우, 알려진 버그가 없으며 가까운 미래에 내가 만질 필요가있는 향후 기능을 알지 못합니다. 평화롭게.

리팩토링 할 시간이없고 코드를 유지 보수 할 수 있으므로 일관성을 유지하십시오. 다음에 견적에 리팩토링을 포함 시키십시오.

일관성을 유지하면 주변 코드의 모양이 좋은 경우 다음 개발자에게만 도움이됩니다. 현재 코드를 이해하고 변경 사항을 추가 할 올바른 "확장 점"을 찾는 데 얼마나 걸 렸는지 생각해보십시오. 현재 추세를 따르면 다음 사람은 기존 코드와 변경해야 할 때 새 코드를 이해해야합니다.

코드를 의미있는 함수로 리팩토링하면 다음 사람이 발생하는 상황을보다 쉽게 ​​이해할 수 있으며 변경 사항을 추가하기 위해 더 적은 노력을 기울여야합니다. 이런 식으로 생각하십시오. 다음 사람이 당신이라고 가정하십시오. 이 코드 블록, 현재보고있는 엉망 또는보다 논리적으로 구성된 것을 다시 방문 할 때보고 싶은 것은 무엇입니까?

일관성 이 최우선입니다. 분명히 올바른 생각을 가진 모든 사람은 어디에서나 복사 붙여 넣은 상용구 대신 우아한 DRY 솔루션을 선호 하지만 , 동일한 코드베이스에서 하나의 일관되게 적용하는 것보다 두 가지 다른 접근법을 정말로 선호합니까? 누군가가 더 똑똑한 솔루션을 개발하여 일관성없이 적용한다면 어떨까요? 그런 다음 같은 일을하는 세 가지 방법이 있습니다.

개발자가 무언가를 수행하는 "더 나은 방법"을 찾아서 코드베이스에 일관되게 적용하지 않아서 지저분한 코드가 많이 보였습니다. 시간이 지남에 따라 새로운 패턴을 점진적으로 적용하는 것이 계획되고 조정 된 전략의 일부라면 효과가있을 수 있지만 일관되게 구현 된 모든 패턴은 전체 시스템을 악화시킬 위험이 있습니다.

작은 단계에서 리팩토링을 고려하여 각 단계를 전체 코드베이스에 한 번에 적용 할 수 있습니다. 예 : 보일러 플레이트의 작은 부분을 각 반복에서 도우미 기능으로 추출합니다. 시간이 지남에 따라 도우미 클래스의 모든 상용구가 완성됩니다. 그것은 설계되지 않았지만 커져서 정말 못 생겼지 만 모든 코드가 한 곳에 있기 때문에 지금 고칠 수 있습니다.

중복 코드를 제거하는 리팩토링은 좋은 리팩토링이며 마감 시간이 임박하지 않은 한 연기해서는 안됩니다. 한 번 리팩토링하는 데 소요 된 시간은 향후 구현에서 시간이 지남에 따라 쉽게 구성됩니다. 리팩토링 덕분에 내부 작업이 더 이상 보이지 않으므로 이해하기가 더 쉬워지고 따르기가 더 어려워집니다.

제 생각에는 리팩토링 된 코드를 따르기가 더 어렵다는 일반적인 오해입니다. 이것은 일반적으로 리팩토링 대상에 익숙하고 리팩토링 결과에 익숙하지 않은 사람들의 주장입니다. 새로 온 사람들에게는 리팩토링 된 결과가 더 명확해질 것입니다.

모든 버그 / 기능은 나중에 중앙 위치에서 수정 / 구현할 수 있으며 응용 프로그램의 어느 곳에서나 자동으로 사용할 수 있습니다. 이것은 일반적으로 과소 평가되는 큰 이득입니다. 일반적으로 구성 요소의 전체 리팩토링에는 시간이 오래 걸리지 않습니다. 버그로 인해 손실 된 시간과 비교했을 때 리팩토링 될 수있는 코드를 이해해야하는 경우 리팩토링 비용이 최소화됩니다.

Péter Török의 답변 관련 업데이트 : "시간이 걸리기 때문에"리팩토링을 연기해도 나중에 리팩토링하는 시간이 증가합니까? 리팩토링은 더 자주 수행 될 때 오래 걸리지 않습니다.

제품에 아무 것도 추가하지 않고 어렵고 완전히 다른 질문 인 코드를 작성하는 데 며칠이 걸릴 것이라고 상사에게 설명하는 방법. :)

쉽게 확장 할 수있는 고유 한 스타일로 새 코드를 도입하면서 이전 코드보다 Facade로 작동하는 새 인터페이스 / 클래스를 만들 수 없습니까?

앞으로 잘해라. 잘라 내기 및 붙여 넣기 대신 기능을 사용하십시오. 리팩토링이 필요하지는 않지만 향후 리팩토링을위한 기초를 제공합니다.

개발자는 쉬운 바보 지루한 코드를 유지하거나 어리석은 지루한 코드를 수행하는 도우미를 원하십니까?

수정 된 질문을 이해하지 못합니다. 본인은 대부분의 사람들이 "멍청한 지루한 코드"를 유지하지 않기를 원한다고 생각합니다. 도우미가 무슨 뜻인지 모르겠습니다. 죄송합니다.

포스터는 지금 큰 변화를 일으키지 않음으로써 자신의 질문에 대답했습니다. 좋은 선택. 비즈니스에 가장 적합한 것이 무엇인지 개발자의 오만에 문제가 있습니다. 교활한 사람에 대한 큰 리팩토링 ... 당신은 당신의 상사보다 더 잘 알고 있기 때문에? 유능한 관리자라면 누구나 혜택을 누릴 수 있습니다.

리팩토링이 선택 사항이 아닌 경우, 질문은 올바른 시간, 장소 등에 대한 토론이됩니다. 일관성은 매우 중요합니다. 그러나 오래 지속 된 코드는 종종 "갱신"의 혜택을받습니다. 다른 사람들은 이것을 논의했습니다 ...