[클린코드] 들어가며

이 글은 유지보수 가능한 코딩의 기술 자바편을 요약 및 정리하여 작성한 내용임을 밝힙니다. 필자가 작성하는 내용은 책의 내용을 그대로 사용하여 작성한 부분도 많지만 인용하여 작성한 부분도 있기 때문에 보다 정확하고 자세한 내용을 위해 해당 책을 구매하여 보시는 것을 추천드립니다.

개발자로 살아가면서 흔히들 어떻게 하면 개발을 잘 할 수 있을까? 에 대해 고민들을 많이 했을거라고 생각합니다. 필자도 개발자로 살아가면서 이에 대해 많이 고민을 하고 있고, 클린코드가 하나의 방법이라고 생각하고 있습니다. 클린코드가 무엇인지 아직 잘 모르시는 분들도 있을거라고 생각합니다. 저 또한 아직 명확하게 알지는 못하지만 유지보수 가능한 코딩의 기술 자바편을 통해 학습하면서 보다 책임감 있는 코드를 짤 수 있는 개발자가 되기를 소망하며 정리해 보도록 하겠습니다.

필자는 책을 보기 전에 책의 뒷 편이나(정확한 명칭을 잘 모르겠네요…) 목차, 작가의 말을 유심히 보는 편입니다. 작가가 독자들에게 전하고자 하는 내용들을 파악하고 책을 읽는 것이 이해하는데 많은 도움이 된다고 생각하기 때문입니다. 여느 때와 같이 유지보수 가능한 코딩의 기술 자바편 뒷 편을 보면서 개인적으로 클린코드에 대한 짧고 명확한 정의라고 생각하는 문구를 발견하였습니다. 다음과 같습니다.

컴퓨터가 이해할 수 있는 코드는 바보라도 짤 수 있다. 유능한 프로그래머는 인간이 이해할 수 있는 코드를 짠다.

- 마틴 파울러

우리나라 대부분의 SI 환경처럼 일정에 급급하여 코드 품질보다는 성과 위주의 환경에서 유지보수성 있는 코드를 작성하기란 쉽지 않다고 생각합니다.(모든 SI 환경이 유지보수성 있는 코드를 작성하지 않는 것은 아니며, 그렇다고해서 다른 환경에서는 유지보수성이 좋은 코드를 작성한다는 말도 아닙니다) 하지만 이 책의 옮긴이가 말한 현실적으로 잘 지켜지지 않는 원칙이라도, 원칙은 원칙이고 마땅히 존재해야 합니다. 비록 모든 상황에 100% 들어맞는 완벽한 원칙은 아닐지라도, 원칙을 갖고 일을 하는 사람과 원칙 없이 대충 하루를 보내는 사람은 아주 큰 차이가 있습니다. 라는 말 처럼 원칙을 갖거나 혹은 알면서 일하는 사람과 그렇지 않는 사람의 차이는 크다고 생각합니다. 그 차이는 시간이 지날수록 더욱 더 벌어진다고도 생각합니다.

1. 유지보수성이란?

소프트웨어 시스템을 고치기 쉽고 어려운 정도를 유지보수성이라고 합니다. 유지보수성은 소스 코드의 속성에 따라 달리집니다. 이 책은 소스 코드의 속성이 무엇인지 알아보고 고치기 쉬운 소스 코드를 작성하는데 유용한 10대 가이드라인을 제시합니다. 국제 표준 규격 ISO/IEC 25010:2011에 따르면 소프트웨어 품질 아래와 같이 분류합니다.

• 유지보수성
• 기능 안정선
• 성능 효율성
• 호환성
• 사용성
• 믿음성
• 보안성
• 휴대성

이 책은 위의 분류 중 유지보수성에 집중하여 가이드라인은 제시합니다.

**Note: ** 유지보수성이 나쁘다 == 개발자들이 기존 코드를 관리하고 고치는데 너무 많은 시간을 허비한다.

1.1. 소프트웨어 유지보수의 4대 유형

소프트웨어 유지보수를 아래와 같이 4가지 유형으로 분류할 수 있습니다.

• 버그를 발견하고 고친다 - 교정형 유지보수
• 운영 환경의 변화(운영체제 또는 다른 기술의 업그레이드)에 따라 시스템을 변경한다. - 적응형 유지보수
• 시스템 사용자의 신규/변경 요청사항을 반영한다. - 완료형 유지보수
• 품질을 높이고 앞으로 닥칠 버그를 방지할 방안을 모색한다. - 예방형 유지보수

2. 유지보수의 중요성

앞서 말했듯이 유지보수성은 ISO 25010에 규정된 소프트웨어 제품의 8대 품질 특성 중 하나로 방대한 주제이지만 크게 두가지로 분류하자만 아래와 같습니다.

• 유지보수를 제대로 하지 않으면 비즈니스 업무에 매우 큰 영향을 끼친다.
• 유지보수는 다른 품질 특성을 가능케 한다.

2.1. 유지보수는 다른 비즈니스에 지대한 영향을 끼친다.

서비스를 운영하다보면 교정형 유지보수와 완료형 유지보수는 끊임없이 쏟아지는 것을 대부분 경험하고 있으실 거라고 생각합니다. 유지보수 효율을 높이면 새 기능 구현 등 다른 업무에 인력을 투입할 여유가 생기고 신속한 개선이 이루어지면 신제품 및 새로운 서비스 출시를 앞당길 수 있습니다. 비즈니스 측면에서 볼 때 동일한 개발자 인력 구성으로 보다 좋은 효율을 만드는 것도 중요하지만 그 보다 더욱 중요한 것은 비즈니스 시장을 선점하냐 못하느냐입니다.

2.2. 유지보수는 다른 품질 특성을 가능케 한다

유지보수성이 뛰어난 시스템은 보안 버그 수정 등 다른 품질 영역의 개선을 도모하기 쉽습니다. 좀 더 일반적으로 말하면, ISO 25010에서 규정된 성능, 기능 안정성, 보안 등 유지보수를 제외한 7개 품질 특성에 관해 소프트웨어 시스템을 최적화하려면 소스 코드 변경을 불가피 합니다.

3. 유지보수 3대 원칙

• 단순한 가이드라인을 지키기만 해도 유지보수성은 나아진다.
• 유지보수성은 나중으로 미룰 문제가 아니라 개발 프로젝트 시작 단계부터 반드시 염두에 두어야 하고 하나씩 실천하는 자세가 중요하다.
• 지키 않으면 다른 가이드라인들보다 결과가 더 안 좋은 가이드라인이 있다. 가이드라인을 충실히 잘 따를수록 소프트웨어 시스템의 유지보수성이 좋아진다. -> 가이드라인의 위반 심각도는 제시합니다.(양호한 위반, 심각한 위반 등)

이 책의 저자는 유지보수의 3대 원칙에 대해 설명하고 있지만 필자는 그 중 중요하다고 생각하는 두가지 원칙에 대해서 설명합니다.

3.1. 단순한 가이드라인을 지키기만 해도 유지보수성은 나아진다.

필자는 세상에 완벽한 가이드라인이란 존재하지 않는다고 생각합니다. 한 예로 들자면, 불필요한 추상화를 통해서 오히려 가독성이 떨어지고 코드베이스가 증가할 때도 있으며, 성능이 중요한 로직의 경우 성능 효율성 때문에 유지보수성을 배제하고 작성할 때도 있습니다. 다만 이 책에서 제시하는 가이드라인은 지키려고 노력한다면 완벽하지는 않지만 충분한 유지보수를 보장하는 제품을 생산할 수 있도록 도와줍니다.

3.2. 유지보수성은 나중으로 미룰 문제가 아니라 하나씩 실천하는 자세가 중요하다

유지보수성은 개발 프로젝트를 시작할 때문에 고민할 문제입니다. 10대 가이드라인 중 하나를 어겼다고하여 전체 시스템 유지보수성에 얼마나 큰 영향을 미칠지는 가늠하기는 힘들지만, 유지보수 가능한 시스템을 구축하려면 개발자 전원이 가이드라인을 지키는 것이 중요합니다.

4. 유지보수성 가이드라인

10대 가이드라인에 대해 미리 간단하게 정리해 보겠습니다.

• 코드 단위를 짧게 하라
  • 단위(메서드, 생성자)는 짧을수록 분석, 테스트, 재사용하기가 좋습니다.
• 코드 단위는 간단하게 작성하라
  • 결정 포인트가 적을수록 단위를 분석/테스트하기 더 쉽습니다.
• 코드는 한 번만 작성하라
  • 사본에 버그를 발견하면 사본마다 코드를 수정해야 하므로 소스 코드 중복은 무조건 피해야 합니다. 중복읜 회귀 버그를 일으키는 원인이 되기도 합니다.
• 단위 인터페이스를 작게 하라
  • 파라미터가 적은 단위는 테스트, 재사용하기 편합니다.
• 관심사를 모듈로 분류하라
  • 느슨하게 결합된 모듈(클래스)이 고치기가 쉽고 시스템을 더울 모듈화하는 방향으로 이끕니다.
• 아키텍처 컴포넌트를 느슨하게 결합하라
  • 느슨하게 겨랍된 최상위 시스템 컴포넌트가 수정하기가 더 쉽고 시스템을 모듈화할 여지가 많습니다.
• 아키텍처 컴포넌트의 균형을 잡아라
  • 컴포넌트가 넘치거나 모자라지 않게 크기를 거의 비슷하게 균현을 맞춰 모듈화한 아키텍처는 관심사를 분리할 수 있고 고치기가 쉽습니다.
• 코드 베이스를 작게 하라
  • 덩치 큰 시스템은 분석, 수정, 테스트할 때 코드가 더 많이 필요해서 유지보수가 쉽지 않고 작은 시스템에 비하면 코드 라인당 유지보수 생산성도 떨어집니다.
• 테스트를 자동화 하라
  • 테스트를 자동화하면 수정한 결과를 거의 실시간으로 피드백 받을 수 있습니다. 손으로 하는 테스트는 확장하기 어렵습니다.
• 클린 코드를 작성하라
  • 코드베이스에 TODO나 죽은 코드 같은 무의미한 아티팩트를 늘어 놓으면 새로운 팀원이 들어와도 생산적으로 근무하기 어렵습니다. 결국, 유지보수는 비효율적으로 이루어 집니다.