Clean Code - 1장 깨끗한코드 훑기

시간이 쫓겨서, 맡은 업무가 지루해서 등 다양한 이유로 양산하는 나쁜 코드는 가장 느리게 가는 방법이다.

나쁜 코드에 발목이 잡히기 시작하면 그 땐 이미 늦었을지도 모른다. 코드에 있어서 만큼은 늦었다고 생각할 때가 진짜 늦은 것이라는 표현이 옳을지도 모른다.

나쁜 코드는 나쁜 코드를 양산한다. ‘깨진 유리창 이론’과 마찬가지로 내가 개발하고 있는 코드의 환경이 나쁜 코드로 구성되어 있다면 나 역시 ‘나 혼자 해봐야..’라는 생각으로 나쁜 코드를 양산하게 될 확률이 높다.

나중은 결코 돌아오지 않는다. 지금. 여기서부터 깨끗한 코드를 작성하기 시작해야만 한다.

나쁜 코드는 개발 속도를 크게 떨어뜨린다.

코드가 하도 엉망이라 프로젝트 진행 속도가 더딘 경험이 많다.

대표적으로 인증/인가 기능을 구현할 때 기존의 코드가 너무 엉망이라 해독하기가 어려운 바람에 새롭게 구성하는데 시간이 많이 걸렸다.

나쁜 코드가 쌓일수록 생산성은 떨어진다.

kai-s를 개발할 당시 경력직 팀원 한 분과 같이 개발을 했는데, 별개의 기능을 맡아 추가하는 와중 이상하게 기존에 작동하던 기능이 되지 않는 현상이 발견되었다.

팀원이 기존의 코드를 그대로 copy-paste하여 새로운 기능을 추가했는데 해당 코드 기존 코드를 덮어버리면서 문제가 발생한 것이다.

팀원의 안일한 개발을 탓 할수도 있겠지만, 돌이켜보면 기존의 코드가 분리하기 어려운 스파게티 코드라서 생긴 문제라는 생각도 든다.

즉, 나쁜 코드가 나쁜 코드를 양산하게 되면서 전체적인 팀 생산성에 문제를 끼치게 되었다.

이 역시 kai-s를 개발할 당시 내가 가졌던 불만과 분노를 회고하면서 반성을 하게 된다.

어떤 요구사항이 있을 때 원래의 설계를 뒤집는 방향이라는 핑계로 불만과 분노를 표출했다.

하지만 저자는 잘못은 전적으로 프로그래머에게 있다.라고 말한다.

우리가 전문가답지 못했던 탓이다.

좋은 코드를 사수하는 일은 바로 프로그래머의 책임이다.

비록 사수가, 상사가, 동료가 좋은 코드를 만드는데 드는 다양한 핑계를 내놓는다고 하더라도 나까지 이에 수긍하고 따르는 행동은 전문가 답지 못한 태도다.

나쁜 코드의 위험을 이해하지 못하는 주변의 말을 그대로 따르는 행동은 전문가답지 못하다.

기한을 맞추는 유일한 방법, 가장 빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

대가들의 생각을 살펴보자.

의존성을 최대한 줄여야 유지보수가 쉬워진다. … 깨끗한 코드는 한 가지를 제대로 한다.

이에 더해 깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드다.

한 가지를 제대로 하는 코드는 다시말해 책임이 응집되어 있는 코드를 의미한다.

나쁜 코드는 너무 많은일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 집중한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한 길만 걷는다.

깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다.

깨끗한 코드는 다른 사람이 고치기 쉬운 코드다. 또한 단위 테스트와 인수 테스트가 존재한다.

깨끗한 코드를 테스트 케이스와 연관짓는 조언이다. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 이 말은 큰 코드보다 작은 코드에 가치를 둔다

객체가 여러 기능을 수행한다면 여러 객체로 나눈다. (단일 책임, 응집도와 관련)

메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러개로 나눈다.

중복 제거에만 신경써도 깨끗한 코드에 한 발 다가선다. (여기서 말하는 중복은 단순히 코드 중복이 아니라 의미 중복에 해당한다고 보면 될 것 같다.)

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