시간에 쫓기다 보면 코드를 마구 치게 된다. 종족, 회사는 프로덕트를 출시하기 바빠 코드 퀄리티를 신경 쓸 겨를이 없이 마구 코드를 치곤 한다. 여기서부터 코드가 엉망이 되기 시작한다. 그러다 프로덕트가 잘 되면 기능을 추가하고, 추가할수록 코드는 더욱 엉망이 된다. 결국 감당할 수 없이 코드가 엉켜버려, 버그를 해결할 수도 없는 지경이 된다.
개발을 하는 사람이라면 누구든지 나쁜 코드를 짜 본 적이 있을 것이다. 급했거나, 코드 작업이 너무 지겨웠거나, 다른 업무가 밀려있었거나 어떤 이유에서든지. 일단은 작동하는 프로그램을 보고 안심하며 '나중에 고쳐야지'하고 다짐하며 돌아선다. 하지만, 나중은 결코 오지 않는다.
나쁜 코드를 작성한 대가는 무자비하다. 코드가 엉망이면 프로젝트 진도가 매우 느려진다. 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기고, 한 번 변경하는데 코드를 읽는 시간이 너무 길어진다. 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.
만약 새로운 사람이 시스템 설계에 미숙하다면, 그는 설계 의도에 맞는 변경과 설계 의도에 반하는 변경을 구분하지 못한다. 또한, 코드를 생산성있게 개선해야 한다는 압박에 시달리게 된다. 결국은 나쁜 코드를 더 많이 양산한다.
기존 프로젝트에 나쁜 코드가 쌓여 더 이상 일을 할 수 없는 지경에 다다라서, 결국은 재설계를 하게 된다. 재설계를 위한 새로운 팀을 구성한다. 물론 재설계를 하는 동안 기존 시스템은 유지되어야 하므로, 계속 유지보수한다. 새 시스템이 기존 시스템 기능을 100% 따라잡지 않는 한, 대체는 없다.
결국 시간을 들여 깨끗한 코드를 만드는 노력은, 비용을 절감하는 최선인 방법인 것이다.
나쁜 코드의 책임은 오롯이 프로그래머에게 있다. 촉박한 일정, 구조를 뒤엎는 새로운 요구사항, 관리자의 잘못 등 여러 상황이 있었겠지만 그럼에도 불구하고 좋은 코드를 사수하지 못한 것은 프로그래머의 책임이다.
나쁜 코드의 위험을 이해
자지 못하는 관리자 말을 그대로 따르는 프로그래머는 전문가답지 못하다.
깨끗한 코드를 작성할 줄 아는 것과 깨끗한 코드와 나쁜 코드를 구분할 수 있는 것은 다르다. 둘을 잘 구분하는 것이 곧 클린 코드 작성 능력을 보장하지는 않는다. 깨끗한 코드를 작성하려면 '코드 감각'을 체득해야 한다. '코드 감각'이 있는 프로그래머는 나쁜 모듈을 알아보는 데서 그치지 않고, 좋은 모듈로 개선할 방안을 떠올리고 최고의 방안을 실행할 계획을 세운다.
깨끗한 코드는 어떤 특징을 갖고 있을까? 전문가들은 아래와 같은 의견을 내놓았다.
코드를 짜는 사람은 저자이다. 저자에게는 독자가 있고, 저자는 독자와 잘 소통할 책임이 있다. 내가 짠 코드를 다른 독자들이 읽기 판단을 내린다는 사실을 기억해야 한다.
새 코드를 짜면서 우리는 기존 코드를 읽는다. 사실, 코드를 읽는 시간 대 짜는 시간의 비율은 10:1을 넘는다. 그만큼 읽기 쉬운 코드는 매우 중요하다. 코드를 읽기 쉽게 만들면 새로 짜기도 쉬워진다. 그러므로 급하고 서둘러 끝내야 한다면, 읽기 쉽게 만들면 된다.
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
시간이 지나도 언제나 코드를 깨끗하게 유지해야 한다는 의미이다. 군대에서 강조하는 '전장 정리'와 비슷한 규칙이다. 한꺼번에 많은 노력을 들이는 대신 그때그때마다 하나하나씩 정리해 나가면 어떨까? 변수 이름 하나를 더욱 의미있게 고치고, 함수를 조금 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하는 것으로 충분하다. 이렇게 하면, 프로젝트 코드는 시간이 지날수록 코드가 좋아질 것이다.