[개발자의 서재/추천] 밥아저씨의 "클린코드" 리뷰

이번에 준비한 것은 밥아저씨의 "클린코더" 리뷰의 다음 순서인 "클린코드" 리뷰입니다.
좋은 코드를 작성하기 위한 구체적인 방법을 설명해줍니다.
실제 예시를 이용해서 설명된 방법을 토대로 리팩토링하는 과정을 하나하나 보여주기 때문에 아주 좋은 지침서인 것 같습니다.
이번 글도 제가 이해한 내용과 중요하다고 생각하는 내용들을 바탕으로 작성되었습니다.
다른 견해가 있다면 많은 가르침 부탁드립니다!

---

빠르게 가는 유일한 방법은 제대로 가는 것이다.

좋은 코드를 작성하기 위해서는 크게 컨벤션, 테스트, 메소드-클래스-시스템, 동시성, 그리고 리팩토링 이 5가지 사항들을 잘 고려해야 한다.
각각의 사항들을 자세히 살펴보자.

컨벤션(convention)

1. 이해하기 쉬워야 한다.
2. 필요한 정보를 쉽게 찾을 수 있어야 한다.
3. 잘못된 정보를 전달하지 않는다.
4. 팀/조직 내에서는 컨벤션을 일관성 있게 적용해야 한다.

컨벤션은 특정 조직에서 지켜야하는 관습 혹은 관례를 뜻한다. 그렇다면 개발자가 지켜야하는 관습은 뭐가 있을까?
대표적으로 명명법(Naming Convention), 주석(Comment), 들여쓰기(Indent)가 있고 이외에도 코드 리뷰 컨벤션, README.md 컨벤션 등이 있다.
컨벤션을 삼엄하게 지키는 조직일수록 다양하고 자세한 컨벤션을 가지고 있지만 가장 중요한 원칙은 변하지 않는다.
전반적으로 가독성, 중복 제거, 일관성을 요구한다는 점에서 코드 작성의 기본 원칙과 유사하다고 생각한다(애초에 코드 역시 협업자에게 전하는 글이라고 생각한다).

테스트

1. 테스트 코드를 통해서 모든 코드가 최소 한번씩은 실행되어야 한다.
2. 테스트 코드는 목적에 알맞게 추상화가 되어야 한다.
3. 테스트 케이스는 빠르고, 의존성이 없고, 코드가 변경될 때마다 실행되어야 한다.

테스트는 최소한의 기능 동작 확인이다. 최소한이라는 말은 적어도 위의 규칙을 지켜야 한다는 뜻이다.

규칙1을 지키기 위해서는 1차적으로 TDD를 적용하는 것이 좋다(TDD에 관해서는 다른 TDD 도서 리뷰에서 더 자세히 다룰 예정이라서 이번 리뷰에서는 아주 간단한 내용만 다뤄보겠다).
TDD를 적용할 수 있는 아주 간단한 과정은 다음과 같다.

1. 실패하는 최소한의 테스트 케이스를 작성한다.
2. 작성한 테스트 케이스가 통과할만큼만 코드를 작성한다.
3. 테스트 케이스에서 요구사항을 검증하지 않는 최소 부분을 찾고 보완한다.
4. 테스트 케이스가 요구사항을 정확히 검증하고, 코드가 완성될 때까지 2-3 반복

이런 방식으로 개발을 진행하면 아주 빠른 주기로 코드를 작성하고 작성된 코드를 검증할 수 있다.

규칙2를 지키기 위해서는 Domain Specific Language(DSL)과 같은 추상화가 필요하다.
다시 말해, 메소드와 클래스를 추상화하듯이 테스트 케이스를 작성할 때에도 추상화가 필요하다는 뜻이다.

테스트 케이스는 촉촉해야 한다. 라는 좋은 트윗이 있었는데 "이것과 상충되는 것 아니냐"라는 의견이 있을 것 같다.
하지만 이는 해당 트윗에서도 설명된 것처럼 DAMP 원칙 역시 절대적인 것이 아니다. 각 문맥에 맞게 적절한 추상화와 모듈화를 통해서 협업자들이 이해하기 쉬운 테스트 케이스를 작성해야 한다.

규칙3을 지키기 위해서는 의존성 역전 원칙(DIP)과 CI를 활용해야 한다.
테스트 케이스의 실행 시간을 증가시키는 가장 큰 원인 중 하나는 데이터베이스와 같은 백엔드 서비스이다.
작성된 코드가 백엔드 서비스에 직접적인 의존성을 가지지 않도록 의존성 주입(DI) 기술을 활용해야 한다.

• 인터페이스 혹은 추상 클래스를 이용해서 쉽게 구현할 수 있다.

CI 같은 경우에는 코드가 커밋될 때마다 혹은 메인 브랜치와 병합되기 전에 테스트 케이스 자동 실행과 같은 정책을 준수해야 한다.

• github에서 지원하는 github action을 사용하면 쉽고 간단하게 설정할 수 있다.

 

메소드-클래스-시스템

1. SOLID 원칙을 준수한다.
2. 유스케이스에 알맞는 적정기술을 사용해야 한다.

SOLID 원칙을 준수하면 가독성 좋고, 유지보수하기 쉬운 코드를 작성할 수 있다! 하지만 SOLID 원칙은 내용이 방대하기에 다른 포스팅에서 자세히 다루도록 하겠다.

유스케이스에 알맞는 적정기술이라고 썼지만 오버엔지니어링을 피하라는 뜻이었다. DAU 100명 대의 서비스가 서버 인스턴스를 100개 이상 실행시킬 필요는 없다. 굳이 캐시어사이드 패턴을 적용할 필요도 없다. kubernetes 같은 복잡한 툴을 사용할 필요도 없다.
지금이 비즈니스 로직에 집중해야 될 때인지, 배포에 집중해야 할 때인지, 운영에 집중해야 할 때인지 고민하며 기술을 도입해야 한다.

동시성

1. 동시성 코드끼리는 분리한다.
2. 동시 읽기, 쓰기가 일어나는 부분(메모리, 객체)들은 각별히 주의한다.

동시성이 이렇게 따로 분류되는 것에 의아함을 느끼는 분들도 있을 것이다. 사실 멀티쓰레드 혹은 멀티 프로세싱이 적용된 코드도 일반 코드와 다를 것이 없다.
그럼에도 불구하고 이렇게 따로 공간을 마련한 이유는 소프트웨어의 대다수의 버그가 동시성 문제로 발생하고, 기본적인 주의사항들을 잊어버리기 때문이다.

1번 같은 경우에는 많은 사람들이 동의할 것이라고 생각한다. 하나의 클래스에서 여러 개의 쓰레드가 생성되는 이유는 주로 공통적으로 접근하는 클래스 변수 때문이다. 하지만 클래스 변수만 공통적으로 접근할뿐 역할은 전혀 다르다. 그렇지 않다면 비슷한 역할을 수행하는 서로 다른 쓰레드들 때문에 발생하는 레이스 컨디션으로 종잡을 수 없는 버그가 발생할 것이다.

2번도 당연한 것이지만 부주의하게 넘어가는 경우를 종종 보곤 했다. thread-safe 데이터 타입 혹은 뮤텍스를 이용해서 동시 읽기, 쓰기가 일어나는 부분들에서 레이스 컨디션이 일어나는 것을 방지해야 한다.

리팩토링

위의 방법들을 계속해서 적용하며 코드로부터 악취가 나지 않게 유지해야 한다.

개발자들이 좋은 코드를 작성하고자 하는 노력을 그만두는 대표적인 2가지 순간들이 있다.

• 첫번째는 소프트웨어가 요구사항대로 동작하는 순간이다.
  요즘 들어 애자일 철학이 "악취가 나는" 코드도 동작하기만 하면 상관없다는 의견들을 듣곤 한다. 하지만 이는 운영, 유지보수 단계의 개발비용의 증가로 인해 결국에는 프로젝트를 끝장내버릴수도 있다는 사실을 모르기 때문이다.
• 두번째는 좋은 코드를 "한번" 작성한 순간이다.
  한번 작성한 좋은 코드에 만족하고 변경 혹은 추가되는 요구사항들을 기존 코드에 끼워맞추곤 한다. 새로운 요구사항들은 구조적으로 최적화되지 않은 코드에 억지로 끼워넣어지고 결과적으로 코드가 더럽혀지게 된다.
  이를 방지하기 위해서는 계속해서 리팩토링을 해야 한다.

또한, 진행 중인 리팩토링이 소프트웨어의 릴리즈에 영향을 주면 안된다.
"코드가 너무 더러워서 리팩토링을 진행해야 합니다. 앞으로 6달동안 릴리즈는 불가능합니다."와 같은 의견은 명백히 잘못된 것이다. 리팩토링은 작게, 그리고 연속적으로 진행되어야 한다. 이를 위해서라도 SOLID 원칙과 유스케이스에 알맞는 적정기술을 사용해야 한다.

---

P.S 1 다른 리뷰도 찾아봤습니다!

• 사례를 소개하며 내용을 알려주는 리뷰
  • https://techblog.woowahan.com/2620/
• 내용 정리가 잘되어 있는 리뷰
  • https://mangkyu.tistory.com/132

P.S 2 책 구매 링크를 공유드리려던 중에 yes24, 교보문고, 알라딘, 쿠팡을 찾아봤는데
교보문고, 알라딘이 빠르게 주문하면 당일배송 혹은 익일 배송이 가능하더라구요.
따로 커미션이 붙은 링크가 아니기에 걱정하지 않으셔도 됩니다 ㅎㅎ

참고: 포스트 대표 이미지는 https://techblog.woowahan.com/2620/ 에서 참고했습니다 :)