나는 이것이 실제로 두 가지 질문이라고 생각합니다. 나는 두 가지에 모두 대답하려고 노력할 것입니다.

1) 코드베이스에서 중복 코드를 줄이는 방법은 무엇입니까?
이렇게하면 비즈니스 로직이 중복되어 버그가 줄어들고 코드를 유지 관리 할 필요가 줄어든다는 이점이 있습니다. 이를 방지하는 가장 좋은 방법은 다른 답변에서 언급 한 것처럼 의사 소통을 통하는 것입니다. 본인은 지식을 올바르게 전파하기 위해 코드 검토 책임을 동등하게 공유해야한다는 추가 경고와 함께 코드 검토를 사용하는 것이 좋습니다. 또한 유용한 코드가 존재하는 문제를 누군가가 해결할 때 개발자가 종종 인식 할 수 있도록 매일 스탠드 업을 사용해야합니다. 또한 지식 공유를 늘리고 프로그래머를 훈련시키는 데 도움이되는 코드 쌍을 고려해야합니다.

또한 가능하면 같은 방에서 가능한 한 가깝게 개발자를 만나는 것이 좋습니다. 많은 공유 화이트 보드와 공간. 그런 다음 함께 식사를 위해 보내십시오. 개발자가 “결합”할수록 서로 더 잘 커뮤니케이션 할 수 있습니다.

Wiki 또는 문서 코드와 유사한 것을 사용하는 것이 좋습니다. 아무리 훈련 된 개발자가 문서화를 시도하더라도 원래 코드에서 벗어나게됩니다. 보다 효과적인 접근 방식은 예제 스타일 테스트에서 스펙을 사용하는 것입니다. 여기에는 코드를 사용해야하는 방식을 명확하게 설명하는 코드가 문서화되어 있으며, 예제를 변경하지 않고 코드를 변경하면 테스트가 실패합니다.

이미 중복 코드가 많은 대형 코드베이스가 있으므로 리팩토링 작업을 수행해야합니다. 잘라내어 붙여 넣지 않은 중복 코드를 찾기가 어려울 수 있습니다. 따라서 변경 기록을 분석하는 것이 좋습니다. 자주 변경되는 파일을 찾습니다. 실제 중복 코드를 나타내지 않고 정리할 가치가 있으면 캡슐화에 문제가 있음을 나타냅니다. 코드 변경 사항에 대해 버그 수정 기록을 분석 할 수 있으면 수정이 필요한 특정 핫스팟이있을 수 있습니다. 이러한 핫스팟을 분석하면 많은 비즈니스 로직이 개발자가 한 곳에서만 변경 한 두 번의 변경이 필요하다는 사실을 깨닫지 못하고 중복 된 비즈니스 로직으로 인한 것입니다.

2) 다른 프로젝트에서 사용할 수있는 공유 위젯, 컴포넌트, 라이브러리 등을 만드는 방법은 무엇입니까 ?
이 경우 비즈니스 로직을 래핑하지 말고 유용한 프레임 워크 코드를 공유해야합니다. 공유 구성 요소 집합을 만들고 유지 관리하는 데 드는 비용이 상당히 클 수 있으며 수행 할 가치가있는 인스턴스를 예측하기가 어려울 수 있기 때문에 이는 까다로운 균형이 될 수 있습니다. 여기서 제안하는 접근법은 3 가지 파업 규칙입니다. 비슷한 코드를 두 번 작성하는 것에 대해 걱정하지 말고 세 번째로 수행해야 할 때 공유 구성 요소로 리팩토링하십시오. 이 시점에서 이것이 유용 할 것임을 확신 할 수 있으며 구성 요소에 대한 광범위한 요구 사항을 잘 알고 있습니다. 분명히 개발자들 사이의 의사 소통은 여기서 매우 중요합니다.

가능한 많은 공유 구성 요소를 오픈 소스로 만드십시오. 비즈니스 로직이 아니므로 경쟁사에게 많은 이점을 제공하지는 않지만 추가 검토 자와 유지 관리자를 무료로 얻을 수 있습니다.

답변