#acl +All:read

실용주의 프로그래머

== 7. 중복의 해악 ==

=== 개발자 간의 중복 ===

그 반면 발견하거나 다루기 가장 어려운 유형의 중복은 한 프로젝트에서 일하는 서로 다른 개발자 사이에서 발생한다. 전체 기능 집합이 부주의하게 중복될 수 있고, 그런 중복은 수년 동안 발견되지 않을 수 있으며, 이는 결국 유지 보수 문제로 귀결될 것이다. 우리는 미국 어떤 주의 정부 컴퓨터 시스템이 Y2K 호환성 검사를 받은 이야기를 직접 들었다. 그 검사는 10,000개 이상의 프로그램을 포함했는데, 각각의 프로그램은 저마다만의 사회보장번호 확인 코드가 있었다.

높은 차원의 해법으로, 깨끗한 설계와 강력하고 기술적인 프로젝트 리더, 그리고 그 설계 내에서 책임의 분배가 제대로 이해되도록 하는 것, 이런 것들로 개발자 간의 중복 문제를 다루어라. 그렇지만 모듈 차원이라면 그 문제를 알아채기란 더욱 어렵다. 분명한 책임 영역으로 나뉘어지지 않는 공통 필요 기능이나 데이터는 여러 번 거듭 구현될 가능성이 있다.

우리가 느끼기에 최선책은 개발자간에 적극적이고 빈번한 소통을 장려하는 것이다. 공통의 문제를 다루기 위한 토론장을 만들어라. (과거 프로젝트들에서 우리는 개발자들이 아이디어를 교환하고 질문을 할 수 있는 닫힌 유즈넷 뉴스그룹을 만들었다. 이것은 대화 내용의 모든 역사가 영구히 저장되면서도 외부의 침입 위험이 없는 의사소통의 장을 가능케 한다. 심지어는 여러 사이트에 걸쳐서도 가능하다.) 한 사람의 팀원을 프로젝트 사서가 되도록 임명하라. 그의 일은 지식 교환을 도와주는 것이다. 소스 트리의 한 가운데에 유틸리티 루틴과 스크립트들이 저장될 수 있는 장소를 마련하라. 그리고 의례히 비공식적으로 혹은 코드 리뷰시 다른 사람의 소스코드와 문서를 읽도록 하라. 다른 사람의 것들을 기웃거리는게 아니고, 거기서 배우는 것이다. 그리고 기억하라. 접근은 상호적이다. 다른 사람이 여러분의 코드를 들여다 본다고 해서 기분 나빠하지 말 일이다.

여러분이 조성해야 할 환경이란 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고, 또 재사용하기 쉬운 환경이다. 만약 그게 쉽지 않다면 사람들은 하지 않을 것이다. 그리고 만약 재사용에 실패한다면 지식 중복의 위험을 각오해야 한다.
----
CategoryBook