1. 깨끗한 코드

나쁜 코드

나쁜 코드는 왜 만들어질까?

• 코드 작성에 충분한 생각할 여유가 없다고 생각할 때
• 코드를 다듬는데 시간을 보냈다가 업무 진행이 느려질 때

등등... 여러가지 이유로 기능만 구현한 경험이 있을 것이다. 그리고 나중에 돌아와 다시 코드를 수습하겠다고 다짐도 했을 것이다.

나도 인턴쉽을 하면서 이러한 생각을 동일하게 했었다. 경험이 부족했던 나는 기능구현도 힘들었고 빠르게 빠르게 API를 만들어내는 것이 개발자로서 일을 잘하는 것이라고 생각했다.
그래서 직관적이지 않은 함수 및 클래스 이름을 짓거나, 모듈마다 추상화 수준을 다르게 하는 등, 코드의 질을 떨어뜨리는 행위를 했다. 물론 클린 코드에 대한 개념이 부족했던 것도 있었다.

나중에 돌아와 코드를 재작성해야지 하며 다짐했었다.
하지만 그 나중은 결코 돌아오지 않았다.

우리 회사는 PR을 할 때마다 교육 담당자 분이 코드 리뷰를 해준다. 그 결과 사실 상 코드 한줄 한줄마다 코맨트가 달리는 사고가 발생했고 코드를 하나하나 다 수숩하느라 다른 일을 하지 못하고 일이 계속 밀렸던 경험이 있었다.

르블랑의 법칙(Leblanc’s Law)
나중은 절대 돌아오지 않는다.

나쁜 코드로 치루는 대가

나쁜 코드를 짜면 유지 보수가 어려워지고 코드를 복구하기 위한 시도를 하게 된다. 또 다른 새로운 작업이 생긴 것이기에 추가 인력을 투입한다는 결정을 내리게 된다.
하지만 이 추가 인력들은 새로운 코드에 대한 이해가 부족하여 결국엔 나쁜 코드를 양산하게 된다. 그러면 이에 대한 복구 시도가 있게 될 것이고 위의 이미지대로 이 과정들이 무한이 반복되게 될 것이다.

생산성대 시간을 고려하여 그래프를 만든다면 위와 같은 형태가 나타나게 된다.

이를 해결하기 위해선 평소에 코드 작성할 때 깨끗한 코드를 만들어내는 습관이 필요하다!!!

좋은 코드

그렇다면 깨끗한 코드는 어떻게 짤까?

• 우와하고 효율적인 코드
• 논리 간단, 의존성 줄이기, 오류 처리는 철저히 하기
• 성능을 최적으로 유지
• 클래스와 함수에게 단일한 책임을 지게 하기

그렇다면 깨끗한 코드는 어떤 특징을 가질까?

• 단순하고 직접적

• 잘 쓴 문장처럼 읽힘

• 설계자의 의도를 숨기지 않음

• 명쾌한 추상화와 단순한 제어문으로 가득함

• 고칠 곳이 없음

• 작성자가 이미 모든 사항을 고려함

• 모든 테스트 통과

• 중복이 없음

• 시스템 내 모든 설계 아이디어를 포함

• 클래스, 매서드 수를 최대한으로 줄임

  흔히들 다음 4 가지만 고려하면 클린 코드를 구현할 수 있게 된다고 알려져 있다.

  • 중복을 피하라
  • 한 기능만 수행하라
  • 제대로 표현하라
  • 작게 추상화하라