Book Review : 유지보수 가능한 코딩의 기술

누가 코드를 이따위로 짠 거야? 나 일 못 해!!! 다른 사람의 코드를 작업하다가 좌절한 경험이 있는가? 서비스가 성장하면 혼자 작업하던 코드도 여러 명이 작업해야 하고, 코드 규모가 커질수록 쉽게 고칠 수 없는 코드로 변하고 만다. 새로운 기능을 개발하는 시간보다 기존 코드를 읽고 수정하는 시간이 더 오래 걸리고, 코드 수정 비용이 급격하게 증가하게 된다. 프로젝트 마감? 마감은 늘어나라고 있는 거 아닌가? 이 책에서는 소프트웨어 개선 그룹(SIG)의 컨설턴트들이 자바로 작성된 JPacman 오픈 소스를 예로 들어 유지보수 가능한 소프트웨어를 만드는 10가지 원칙을 설명한다. 특정 기술에만 해당하는 지표나 변별력이 없는 지표는 제외했다. 팀에서 지키면 최소한 읽을 수 있고, 유지보수가 가능한 코드를 작성할 수 있는, 현실적인 지침을 제시한다. 개발팀의 서가에 이 책은 반드시 꽂혀 있어야 한다.

<출처 : 다음 책 소개>

★★★★☆

 소프트웨어의 품질은 유지보수성, 기능 안정성, 성능 효율성, 호환성, 사용성, 믿음성, 보안성, 휴대성이라는 여덟가지 특성으로 분류한다고 합니다. (ISO 25010) 이 책은 그 중 유지보수성에 대한 책 입니다. 업무를 하다보면 처음 부터 신규 구현을 하는 경우도 있겠지만 대개 유지보수에 많은 시간을 드리곤 합니다. 비단 업무의 비율로 치지 않더라도 유지 보수성이란 것이 비지니스나 품질에 지대한 영향을 끼친다는 사실은 자명 합니다.

 이 책에서는 유지보수성 10대 가이드 라인을 각 장별로 제시하고 있습니다. 각 장별 예시로 제시된 코드나 내용의 난이도가 높지 않고 군더더기가 없어 약간의 실무 경험이 있으시다면 공감하며 책을 읽어 나가실 것이라 생각 됩니다. 10대 가이드 라인은 아래와 같습니다.

  1. 코드 단위를 짧게 하라 : 메소드 단위는 15라인을 넘어가지 않게 작성해야 해당 메소드를 이해하고, 테스트하고, 재사용하기 쉬워 유지 보수성이 좋아질 수 있습니다. 

  2. 코드 단위는 간단하게 짜라 : 복잡한 if-else 구문과 같이 코드 복잡성을 높이는 방식을 제한해야 합니다. 단위 당 분기점은 4개 이하로 제한하고 복잡한 단위는 더 잘게 나누어 서로 뭉쳐 있지 않게 해야 합니다. 그래야 단위 별 수정 및 테스트가 쉬워지고 유지보수 성이 개선 됩니다.

  3. 코드는 한번만 작성하라 : 코드를 복사하지 않습니다. 이 책에서 중복 코드는 정말 정말 기피해야 할 대상으로 보고 있습니다. 코드를 복사하면 여러 곳에서 버그를 고쳐야 하기 때문에 비효율적이고 에러가 나기 쉽습니다. 중복 코드의 경우 생성하지 않는 것이 무엇보다 중요 합니다. 참고로 이미 어느 정도 개발이 완료된 패키지에서의 중복 코드는 PMD 에 포함된 CPD 를 통해 검출 할 수 있습니다.

  4. 단위 인터페이스를 작게 하라 : 단위당 파라미터 개수는 4개 이하로 제한하는 것이 좋습니다. 만약 파라미터가 너무 길어진다면 이들을 객체로 추출 하는 것도 좋습니다. (예, x1, y1, x2, y2 ---> Rectangle) 

  5. 관심사를 모듈로 분리하라 : 모듈 간 결합을 느슨하게 하기 위해 큰 모듈을 삼가해야 합니다. 개별 모듈로 나누어 일을 시키고 구현 상세는 인터페이스 안으로 감추는 것이 좋습니다. 그리하여 보다 느슨하게 결합된 코드베이스 상에서 수월하게 내용을 미리 실피고 실행할 수 있습니다.

  6. 아키텍처 컴포넌트를 느슨하게 결합하라 : 메소드, 클래스 단의 리팩토링 못지 않게 최상위 수준의 컴포넌트 간의 리팩토링 역시 중요 합니다. 최상위 수준의 컴포넌트 간 결합도를 낮추어야 합니다. 다른 컴포넌트 모듈에 호출을 받는 형태로 공개된 모듈 내부의 상대적인 코드량을 최소화하는 방향으로 결합도 낮춤이 진행되야 합니다. 그리하여 각 컴포넌트의 독립성을 유지하고 유지보수성을 개선할 수 있습니다.

  7. 아키텍쳐 컴포넌트의 균형을 잡아라 : 최상위 수준의 컴포넌트 개수와 상대적 크기의 균형을 잡아야 합니다. 컴포넌트의 개수는 9개 정도(6 ~ 12개 사이) 되도록 소스 코드를 조직화 하고 컴포넌트의 크기를 대략 균등하게 맞추는 것이 좋습니다. 

  8. 코드 베이스를 작게 하라 : 코드베이스를 가능한 작게 하는 것이 좋습니다. 코드베이스가 커지는 걸 막고 시스템 크기를 적극적으로 줄여야 합니다. 이를 위한 다양한 가이드 라인이 있겠지만 이 책에서는 적극적으로 오픈소스 라이브러리 / 프레임워크 사용을 권장하고 있습니다. 단, 이때 해당 라이브러리의 코드는 고치지 않는 것이 중요합니다. 코드를 고치는 순간, 해당 라이브러리가 결국 코드 베이스에 포함되는 것이나 마찮가지기 때문에 라이브러리 업데이트를 매번 따라가고 분석해야하는 어려움이 있을 수 있습니다.

  9. 테스트를 자동화 하라 : 당연합니다. 개발자가 일일히 손으로 한땀 한땀 테스트 하고 있을 수 없습니다. 자동화 할 수 있는 것들은 모두 자동화로 돌리는 것이 좋습니다.

 10. 클린 코드를 작성하라 : "스스로 프로라고 자부한다면 클린 코드는 필수다. - 로버트 C. 마틴" 클린 코드를 작성하는 7대 규칙이 있습니다. 

• 단위 수준의 코드 악취를 남기지 말라.

• 나쁜 주석을 남기지 말라.

• 주석 안에 코드를 남기지 말라.

• 죽은 코드를 남기지 말라.

• 긴 식별자 이름을 남기지 말라.

• 매직 상수를 남기지 말라.

• 제대로 처리 안 한 예외를 남기지 말라.

 책의 뒷 표지에는 좋은 코드에 대한 구루(GURU) 들의 한마디들이 적혀 있습니다. 그 중 첫 번째를 소개하자면,

' 컴퓨터가 이해할 수 있는 코드는 바보라도 짤 수 있다. 유능한 프로그래머는 인간이 이해할 수 있는 코드를 짠다.' 라는 문구다. 결국 개발이든 일이든 혼자하는 것이 아니라 같이 하는 것임을 깨닫고 이를 코드 품질 향상에도 적응 할 수 있어야 할 것 같습니다. 

 요즘 회사에서 코드 리뷰 강화! 코드 품질 강화!를 외치고 있다면, 일독하실 것을 권해 드립니다.