[개발자의 서재] "실용주의 프로그래머" 7. 중복의 해악

1. 소프트웨어 개발에서 중복이란

소프트웨어 개발은 문제에 대한 지식(조건, 해결책 등)을 코드로 풀어나가는 행위라고 할 수 있습니다. 따라서 개발 과정에서 일어나는 중복은 결국 지식의 중복이라고 할 수 있습니다.

이런 관점에서 중복들을 다음 4가지로 1) 강요된 중복, 2) 부주의한 중복, 3) 참을성 없는 중복, 4) 개발자 간의 중복 분류할 수 있었습니다.

2. 강요된 중복

강요된 중복의 예시로는 로직이 중복되는 API, 추상 클래스와 구상 클래스에 중복으로 작성되는 주석, 테스트 케이스 문서들이 있습니다. 이런 상황에서 개발자들은 중복을 피할 수 없다고 생각합니다. 하지만 코드 생성기를 통한 인터페이스 자동 생성, 주석에서 고차원적인 내용과 저차원적인 내용 분리, 문서 - 코드 연동 시스템 구축을 통해서 중복을 제거할 수 있습니다.

• 코드 생성기는 기술적으로 적용해본 적이 없어서 상당히 어려울 것이라고 예상만 하고 있습니다.
• 주석에서도 추상화 단계를 고려하며 작성하는데 이것이 중복을 제거하는 결과를 가져왔네요.
• 예전에 cucumber를 잠깐 사용했었는데 테스트 시나리오와 테스트 코드를 연동시키는 것이 어떤 작업인지 경험할 수 있었습니다.

3. 부주의한 중복

부주의한 중복은 설계 단계에서의 실수라고도 할 수 있습니다. 두 개의 점을 갖는 Line 클래스를 예시로 들 수 있습니다. Line 클래스는 두 점 뿐만 아니라 두 점 간의 거리인 length라는 필드도 가지고 있습니다.
여기서 부주의한 중복이 발생할 수 있는 가능성이 생깁니다. 점이 바뀔 때 length 필드가 업데이트 되지 않는 경우입니다. length의 값을 저장하는 것이 아닌 두 점을 이용하여 계산하는 방식으로 활용한다면 문제를 해결할 수 있습니다.이렇게 부주의한 중복은 데이터 정규화, 의존성 제거 등 설계 단계에서 제거될 수 있습니다.

• 이런 문제를 데이터베이스의 trigger로 해결하거나 업데이트 함수를 보완하는 것으로도 해결할 수 있습니다.
• 그렇지만 개발자가 데이터의 유효성이 보장되는 것을 계속해서 확인해야 하기 때문에 생산성을 저하시킬 수 있습니다!

4. 참을성 없는 중복

참을성 없는 중복은 HOTFIX 혹은 리팩토링이 귀찮아서 코드를 중복으로 작성하는 경우를 말합니다.

• 기억합시다. "빠르게 가는 유일한 길은 올바르게 가는 것이다."

5. 개발자 간의 중복

개발자 간의 중복은 팀 내 소통이 원활하게 이뤄지지 않아서 똑같은 코드, 문서가 중복으로 작성되는 경우를 말합니다. 팀내 소통을 장려하여 문제를 해결해야 하는데요. 프로젝트 전용 토론장을(github discussion, 슬랙 채널 등) 만들고 팀원 중 한 명을 프로젝트 사서(스터디 정리 당번?)로 임명하여 지식 공유의 책임을 부여하는 방법이 있습니다.

• 결국 사람이 하는 일이기 때문에 소통만큼 중요한 것이 또 없을 것 같습니다.
• 새로운 것을 만든다기보다는 기존의 것을 제대로 활용하기 쉬운 환경을 조성하는 것입니다.