중복 코드를 수락 할 수있는 예외적 인 경우가 있습니까?

우리는 세 가지 API를 빌드해야하는 소프트웨어 프로젝트를 진행하고 있습니다. 하나는 홈 뱅킹 채널, 하나는 대행사 채널 , 다른 하나 는 모바일 채널입니다.

대행사 API는 모든 기능을 갖추고있어 가장 완벽한 API입니다. 그 다음에는 약간 작은 Home API와 모바일 API가 있습니다.

여기서 설계자는 공통 계층 (모든 API가 공유하는 교차 채널 EJB 서비스)을 만들었습니다. 그러나 API는 다릅니다.

API 간에는 큰 차이가 없습니다. 대기업 팀은 대행사 채널을 시작으로 홈 채널에 맞게 조정하고 있습니다. 우리는 홈 앱에 특별히 객체를 보강하고 있습니다. 그렇지 않으면 코드는 API간에 95 % 유사합니다. API는 Spring MVC를 기반으로 구축되었으며 컨트롤러, 모델 및 일부 유틸리티가 있습니다.

기본적으로 컨트롤러는 BO를 ChannelObject에 매핑하고 (적절한 장소가 아닌 것 같습니다) 일부 추가 유틸리티와 직렬 변환기를 수행합니다. 지금은 모두 중복되었습니다. 그들은 중복의 이유는 API를 독립적으로 원하기 때문이라고 말합니다. "내일 우리가 대행사 나 모바일과 다른 행동을 원한다면 우리는 어려움을 겪지 않을 것입니다."

중복 코드를 수락해야하는 경우가 있습니까?

복제 는 올바른 일이 될 수 있지만 이러한 이유로는 할 수 없습니다.

"현재 코드베이스에서이 세 곳이 다르게 동작하기를 원할 수도 있습니다"라고 말하는 것은 대규모 복제의 좋은 이유가 아닙니다. 이 개념은 모든 시스템에 적용될 수 있으며 중복 을 정당화 하는 데 사용될 수 있습니다 .

복제는 전체 비용이 많이 드는 것 제거하는 경우에만 허용되어야한다 지금 (지금 좋은 생각 할 수는 없지만 하나가 될 수 있습니다 확신 할 다른 이유로 - 프로그래밍의 거의 모든 (A)보다 트레이드 오프 오히려입니다 법).

당신이하고있는 일에 대한 올바른 해결책은 예를 들어 지금 전략에 복제 된 행동이나 클래스로 행동을 모델링 한 다음 같은 클래스의 세 인스턴스 를 사용하는 다른 패턴으로 추출하는 것일 수 있습니다 . 당신이 때 그런 식으로, 할 세 가지 장소 중 하나의 동작을 변경하려면, 당신은 단지 새로운 전략을 만들고 한 곳에서 그 인스턴스를해야합니다. 이렇게하면 클래스를 추가하고 나머지 코드베이스를 거의 그대로 유지하면됩니다.

Ruby 생태계의 유명한 소프트웨어 엔지니어이자 저자 인 Sandi Metz는 훌륭한 블로그 게시물 과 복제와 추상화의 관계에 대해 이야기 합니다. 그녀는 다음 결론에 온다

중복은 잘못된 추상화보다 훨씬 저렴합니다.

그리고 나는 그녀에게 완전히 동의합니다. 이 인용문에 더 많은 문맥을 알려 드리겠습니다. 때로는 올바른 추상화를 찾는 것이 매우 어렵습니다. 그러한 경우 중복을 줄이기 위해 추상화가 필요 합니다 . 그러나 나중에 추상화가 모든 경우에 해당되는 것은 아닙니다. 그러나 모든 것을 다시 바꾸고 다른 길을가는 것은 비용이 많이 듭니다 (더 나은 설명을 위해서는 그녀의 이야기를보십시오!).

예, 저에게있어, 복제를 받아들이는 것이 올바른 결정 인 예외적 인 경우가 있습니다. 특히 앞으로 올 일이 확실하지 않고 요구 사항이 변경 될 수 있습니다. 귀하의 게시물에서 나는 지금 많은 중복이 있다고 생각하지만, 동료들은 이것이 변경되어 두 응용 프로그램이 서로 연결되지 않을 것을 제안합니다. 제 생각에는 이것은 유효한 주장이며 일반적으로 무시할 수 없습니다.

사람들 이 "내일이라면" 이라는 단어로 디자인에 대해 추론하기 시작 하면 , 이것은 특히 나에게 큰 경고 신호입니다. 반대의 결정보다 변경 또는 되돌리기가 더 어려운 지불.

코드를 복제하면 단기간 동안의 노력이 줄어들지 만 코드의 중복 된 행 수에 비례하여 거의 즉시 유지 관리 노력이 증가합니다. 코드가 복제되면 잘못된 결정이라고 판명되면 중복을 제거하기가 어려워지며, 코드를 복제하지 않는 경우에도 DRY를 고수하면 나중에 중복을 도입하기가 쉽습니다. 잘못된 결정이었습니다.

더 큰 조직에서는 DRY 원칙보다 다른 팀의 독립성을 선호하는 것이 때때로 유리합니다. API의 95 % 공통 부분을 추출하여 중복을 제거하면 새로운 구성 요소 두 개가 독립적 인 두 팀을 연결하게되므로 이것이 현명한 결정이 아닐 수 있습니다. 반면에 리소스가 제한되어 있고 두 API를 유지 관리하는 팀이 하나 뿐인 경우 이중 노력을 기울이지 않고 불필요한 코드 중복을 피하는 것이 그들 자신의 이익이 될 것이라고 확신합니다.

"Home"및 "Agency"API가 완전히 다른 응용 프로그램에서만 독점적으로 사용되거나 "Home"컨텍스트에서도 사용할 수있는 API를 기반으로 구성 요소 빌드를 작성하려는 경우 차이가 있습니다. "Agency"컨텍스트에서와 같이 이 상황에서 API의 공통 부분이 정확히 동일하면 (공통 부분이 복제되지 않은 경우에만 보장 할 수 있음) 이러한 구성 요소의 개발이 훨씬 쉬워집니다.

따라서 서로 다른 하위 팀이 있고 각 팀마다 각기 다른 일정과 리소스를 가진 각 API를 담당하는 경우, 코드를 복제 할 때가되었지만 "사례"가 아닙니다.

결합을 방지하기위한 복제 . 두 개의 큰 시스템이 있고 동일한 라이브러리를 사용하도록 강제한다고 가정 해 봅시다. 두 시스템의 릴리스주기를 연결했을 수 있습니다. 이것은 나쁘지는 않지만 한 시스템이 변경을 도입해야한다고 가정 해 봅시다. 다른 하나는 변경 사항을 분석해야하며 영향을받을 수 있습니다. 때로는 문제가 발생할 수 있습니다. 두 당사자가 변경 사항을 조정할 수 있더라도 관리자, 테스트, 종속성 및 소규모 자치 팀의 끝을 거치는 많은 회의가 될 수 있습니다.

자율성과 독립성을 얻기 위해 중복 코드의 가격을 지불하고 있습니다.