[Clean Code] 클린 코드 - 1

깨끗한 코드

코드를 최대한 다양한 각도에서 살펴본다.
그렇게 연습한 것들을 토대로, 좋은 코드와 나쁜 코드를 구분할 수 있으며, 좋은 코드를 작성 또는 나쁜 코드를 좋은 코드로 바꾸는 실력도 생길 것이다.

코드는 존재한다

해당 책은 코드를 다룬다.
누군가는 코드보다 모델/요구사항에 집중해야한다고 생각할 것이다.
하지만 코드는 요구사항을 상세히 표현하는 수단이다.

언젠가 코드를 사동으로 생성하는 시대가 온다고 한다.
하지만 위에서 말했듯, 요구사항을 코드가 표현한다.

나쁜 코드

80년 대에 Killer App이 개발되었다. 많은 사용자들이 해당 앱을 사용했고, 인기도 많았다.
하지만 언젠가부터 버전 릴리즈가 늦춰지고, 버그가 남아있고, 죽는 횟수가 증가했다.
이러한 불편한 UX로 인해 사용자들은 떠났고, 회사는 망했다.
그 이유는 출시에 바빠 코드를 마구 짯다. 기능을 추가할수록 코드는 엉망이 되어버렸다.

(대학생 시절, 처음으로 앱을 개발했을 때가 생각이 난다. 처음 사용해보는 Unity엔진과 C#언어는 물론 어려웠다. 또한, 프로젝트를 최대한 빨리 런칭하고 싶었기에 별다른 공부는 안했다. '하다보면 차차 알게되겠지..' 라는 생각이었다. 물론 진행을 하면서 습득했던 것들은 있었다. 하지만 그렇게 습득한 것들이 나쁜 것이었고, 나쁜 코드를 작성하는 방법이었다. 그렇게 런칭된 게임은 그 후로는 다시는 쳐다보지 못하는 코드를 갖게 되었다.)

왜 나쁜코드를 작성하게 되는가?
급해서, 서둘러서, 코드를 다듬느라 시간을 보내면 팀의 일정에 누가 될까봐, 상사한테 한소리를 들을까봐, 지겨워서 등 정말 많은 이유로 인해 나쁜 코드를 그대로 배포하는 상황이 많다.
또한, 내가 짠 쓰레기 코드를 보며 나중에 꼭 손보겠다고 생각한 경험이 있다. 당시에는 "그래도 돌아가는 게, 안돌아가는 것보다는 훨씬 낫지"라며 말이다. 그 당시에는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

코드가 엉망이라 프로젝트 진도가 안나가는 경험도 있을 것이다.
"나쁜 코드는 개발 속도를 크게 떨어뜨린다."
코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 얽히고설킨 코드를 '해독'해서 새로운 얽히고설킨 코드를 더한다.
시간이 지나면서 그 부피는 점점 더 커져갈 것이고, 청소할 방법은 없어진다.

• 나쁜 코드가 쌓일수록 팀의 생산성을 떨어진다. 그러다 0에 수렴하기 때문에 관리층은 복구를 시도한다.
  • 생산성 증가를 위해 새로운 인력을 투입!
    • But, 새 인력들은 시스템 설계에 대한 조예가 깊지 않다. 결국 팀과 새로운 인력은 압력에 시달리고 결국은 나쁜 코드를 더 양산한다.