클린 코드에 대한 오해와 진실
오해1. 클린 코드에 신경을 쓰면 개발 시간이 느려진다.
너무 코드를 깨끗하고 예쁘게 짜는 것에만 치중하면 정작 필요한 기능 구현과 로직 작성에 걸리는 시간이 오래 걸린다고 생각할 수 있습니다. 하지만 깨끗하고 예쁜 코드는 오히려 개발을 빠르게 하기 위해서 중요합니다. 개발자는 코딩을 할 때, 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘습니다. 즉, 새 코드를 짜면서 끊임없이 반복하여 기존 코드를 읽습니다. 실제로 개발할 때, 코드를 작성하는 시간보다 새로 작성할 코드를 기존 코드 베이스에 녹여낼 방법을 찾기 위해 기존 코드를 읽는 시간이 훨씬 길다는 것을 조금 신경 써보면 금방 눈치챌 수 있습니다. 따라서 더 읽기 쉬운 코드는 개발 속도를 향상시킵니다. 또한, 클린 코드를 좋아하는 사람들이 너무 변수 네이밍에 지나치게 집착하기 때문에 시간낭비를 한다는 것도 사실이 아닙니다. 클린 코드에 익숙해지면 오히려 변수명 등 작명에 고민하는 시간이 거의 없어집니다. 몇 가지 규칙에 의해서 기계적으로 작명할 수 있어서 네이밍을 빨리 할 수 있기 때문입니다.
오해2. 클린 코드는 타인에 대한 배려이므로 협업 상황에서만 좋다.
더 읽기 쉬운 코드는 협업 상대에 대한 배려라고 인식하는 경우도 있습니다. 물론 맞는 말이지만 혼자서 개인 프로젝트를 하더라도 자신이 짠 코드를 며칠 뒤에 다시 봤을 때 읽기 힘든 경우를 겪어보신 분들이 많을 것입니다. 내가 대충 짠 코드도 내가 짠 것이기 때문에 나중에 보면 알아볼 수 있다는 것은 큰 교만입니다. 실제로 해보면 이것은 쉽지 않습니다. 따라서 클린 코드는 나를 위한 배려이며 나를 위해서 실천해야 하는 것입니다.
오해3. 클린 코드는 코드의 가독성에만 영향을 줄 뿐, 설계와는 관련이 없다.
더 읽기 쉬운 코드는 더 고치기 쉬운 코드를 의미하기도 합니다. 더 고치기 쉬운 코드는 더 좋은 설계를 가졌다는 뜻입니다. ETC(easier to change)는 좋은 설계의 핵심입니다. 따라서 클린 코드는 좋은 설계의 핵심입니다. 설계를 잘하기 위해서 종종 DDD(Domain Driven Design)같은 것을 도입하기도 하는데, DDD에서 보편 언어를 모든 코드에서 사용하라는 원칙이 있습니다. DDD에서도 좋은 설계를 위해서는 누구나 쉽게 읽을 수 있는 언어로 코드를 작성해야 한다고 말하고 있는 것입니다.
또한 클린 코드는 SOLID를 기반으로 함수와 클래스가 지켜야 할 규칙들을 제시하고 있습니다. SOLID는 좋은 설계를 위한 기본 조건 중 하나입니다.
오해4. 클린 코드는 변수명 같은 것만 신경 쓸 뿐, 코드의 논리적 전개의 퀄리티를 높이지 않는다.
클린 코드는 코드의 논리적 가독성을 높입니다. 추상화 수준에 따라 코드를 전개하는 내려가기 규칙을 지키면 코드는 일관된 논리를 가지게 되므로 다음 라인에 어떤 코드가 나올지 예상하면서 읽을 수 있게 됩니다.
클린 코드 실천 마인드
나쁜 코드로 치르는 대가는 큽니다. 시간이 지날수록 생산성은 극도로 악화됩니다. 많은 시간이 지난 후에는 리팩터링 비용이 처음부터 다시 시작하는 비용보다 커질 수도 있습니다. 따라서 나쁜 코드는 보이는 즉시 제거하는 것이 베스트입니다. 이를 위해 보이스카우트 규칙을 제시합니다. 보이스카우트 규칙은 '캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.'입니다. 마찬가지로 체크아웃할 때보다 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않습니다.
일정에 쫓기더라도 좋은 코드를 작성해야 합니다. 관리자들은 늘 일정과 요구사항을 강력하게 밀어붙이는데 그것은 그들의 책임이기 때문입니다. 반면 좋은 코드를 사수하는 것은 우리 개발자들의 책임입니다. 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르는 것은 우리의 책임 영역을 버리고 관리자의 책임 영역만 도와주는 것입니다. 그러다가 나중에 돌이킬 수 없을 정도로 코드가 나빠져서 비용 문제가 표면 위로 나오기 시작하면 관리자는 그것을 개발자의 탓으로 할 것입니다. 그리고 우리는 그것을 변명할 수 없습니다. 따라서 우리의 책임을 다하기 위해 관리자와 소통하고 협상하는 스킬을 가져야만 합니다.
구체적인 실천 방안
일관된 네이밍 규칙 정하기
일관된 규칙이 있으면 네이밍에 고민하는 시간을 줄일 수 있습니다. Restful api나 Domain Driven Design을 해보셨다면 뛰어난 프로그래머들이 네이밍 규칙에 어떤 철학을 적용하기를 원하는지 감을 잡을 수 있을지도 모릅니다. 일반적으로 널리 사용되는 규칙으로는 함수는 동사로 시작한다라던가, 클래스나 객체는 명사 이름을 사용한다와 같은 것들이 있습니다. 매 프로젝트마다 불편했던 네이밍 규칙들을 개선해나가면서 자신만의 규칙을 정립해보세요.
코드 오토 포매팅 적용하기
IDE는 유용합니다. 들여쓰기 범위, 문단 간 띄어쓰기 등 지켜졌으면 좋겠는 규칙들을 자동화시킬 수 있습니다. 특히 IDE에서 파일을 save할 때 오토 포매팅을 하도록 설정해서 사용해보세요.
주석 사용하지 말기
주석을 사용하는 일반적인 이유는 코드의 품질이 나쁘기 때문입니다. 따라서 주석을 사용하고 있다면 주석을 제거하기 위해 코드를 어떻게 개량할 수 있는지를 고민해봐야 합니다. 대부분의 경우 네이밍을 잘하고 모듈을 작은 단위로 쪼개어 사용하다보면 주석의 많은 부분이 해소됩니다. 그리고 테스트 코드가 주석의 좋은 대안이 될 수 있습니다.
테스트 코드 쓰기
테스트 코드는 코드의 품질을 극도로 올릴 수 있는 수단입니다. 테스트 코드는 본 코드보다 가독성이 좋으며, 본 코드에 유연성, 유지보수성, 재사용성을 제공해줍니다. 본 코드 전에 테스트 코드를 먼저 작성하고, 테스트의 실행을 자동화하여 코드의 변경이 있을 때마다 테스트의 통과 여부를 바로바로 알 수 있도록 합니다. 이것을 효율적으로 하기 위해서 테스트의 실행은 빨라야 하며, 테스트가 스스로 통과/실패를 판단할 수 있는 자가검증을 할 수 있어야 합니다.
함수, 클래스, 모듈은 SOLID를 지키기
단일 책임 원칙은 모듈의 변경 이유를 하나로 제한합니다. 모듈의 책임이 명확해지므로 변수명 작명이 쉬워집니다. 간결한 이름이 떠오르지 않는다면 모듈의 크기가 너무 커서 그렇습니다. 모듈의 이름이 모호하다면 모듈의 책임이 너무 많아서 그렇습니다. 또한 단일 책임 원칙을 위해 함수는 사이드 이팩트를 만들지 않아야 합니다. 이것을 지키는 것은 예측가능성을 높여줍니다.
개방 폐쇄 원칙은 수정을 쉽게 만듭니다. 리스코프 치환 원칙은 유연성을 제공합니다. 인터페이스 분리 원칙은 불필요한 코드를 제거합니다. 의존성 역전 원칙은 안정된 추상화를 만듭니다.
오류 코드 대신 예외 코드 사용하기
try블록은 트랜잭션과 비슷합니다. try블록 안에 코드가 실패하면 catch에서는 애플리케이션의 상태를 try실행 이전 상태로 일관성있게 유지해야 합니다. try-catch-finally문부터 작성하면 try블록에서 무슨 일이 생기든 호출자가 기대하는 상태를 정의하기 쉬워집니다.
null을 전달하거나 반환하지 말기
null 반환은 일거리를 늘릴 뿐만 아니라 문제를 호출자에게 떠넘깁니다. 좋은 방법은 null대신 예외나 특수 사례 객체를 반환하는 것입니다. 예를 들어 정상적인 경우 배열을 반환하기로 되어있다면 null이 아니라 빈 배열을 반환할 수 있는지를 검토해봅니다.
동시성 방어 하기
단일 책임 원칙을 지켜 동시성 코드와 동시성이 아닌 코드를 분리합니다. 동시성 하나만 다루는 것도 충분히 어렵기 때문입니다. 객체는 불변 객체를 사용합니다. 읽기 전용으로만 사용하면 동시 업데이트의 문제를 해소할 수 있습니다. 스레드도 마찬가지로 가능한 독립적으로 구현하여 공유자원을 사용하지 않습니다. 만약 공유자원이 있다면 최대한 줄이고 캡슐화합니다. 언어, 라이브러리, 실행 모델을 이해하고 올바른 동시성 코드를 작성합니다. 동기화하는 메서드들 사이의 의존관계를 이해하고 동기화하는 부분을 최대한 작게 만듭니다. 시스템을 종료하는 코드는 초기부터 고민하고 구현합니다.
이 포스트는 로버트 C. 마틴의 클린 코드를 읽고 그 내용을 기반으로 재창작한 글입니다. 책에서는 훨씬 더 자세하게 클린 코드의 중요성과 구체적인 가이드라인들을 배울 수 있습니다. 아직 클린 코드에 감이 안온다거나 더 자세하게 배워보고 싶다면 이 책을 읽는 것은 최고의 선택지가 될 수 있습니다.
(이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.)
최근댓글