클린코드를 읽는 이유는 말 그대로 깨끗한 코드를 짜기 위함이다.

그렇다면 "나쁜 코드"는 무엇일까?

사실 정의하기에는 각각 다양한 정의가 나오기때문에 딱 잘라서 말하기 힘들다.

굳이 정의하자면.. 클린코드에서 권장하는 예시들이 있는데 그것들이 나쁜 코드라고 할 수 있을 것 같다.

"나쁜 코드"는 내가 이제까지 개발하면서 알게모르게 아니 알면서도 많이 썼던 것 같다.

나는 만 3년차까지 si업체, 소위말하면 IT인력을 파견하는 것이 주 회사인 곳에서 일해왔다.

3개월~6개월까지 다양하게 파견다니면서 새로운 서비스를 만들었었다.

서비스를 만드는데에, 분석과 설계단계에서 기간을 산출하는게 맞다고 본다.

하지만 내가 파견갔던 곳은 먼저 기간을 정해놓고 분석과 설계, 그리고 기능을 만들어 결국 서비스하는 하나의 어플리케이션을 만들었다.

시간(기간)이 중요한 곳에서의 나의 코딩의 산출물들은 다시 소스를 보면 정말 가관이다.

예를 들면, 컨트롤러에 비지니스 로직을 작성한것도 있고, 불필요한 주석과 로그들, 생각없이 짠 중복된 코딩들 .. 등등이 눈에 보였다.

하지만 그때엔 나는 기간내에 개발한것에 대해 뿌듯했었다.

그게 시간이 지나고나니 그저 결과물만 보고 코딩을 해왔던 것 같다.

현재에는 서비스를 하는 업체에서 일하고 있는데, 내가 si에서 개발했던 소스를 해당 업체가 서비스하면서 운영한다고 생각하니 정말 내가 부끄럽고 그 업체가 불쌍하다.

책에서도 비슷한 내용이 나온다.

처음부터 소위말하는 나쁜코드로 결과물만 바라보고 코딩하게 된다면 처음에는 생산성은 높을 수 있으나, 점점 생산성은 0이 되버리고 만다.