나쁜 코드
80년대 후반 커다란 인기를 끌었던 앱이 있었는데, 제품 업데이트 주기가 점차 늘어지기 시작했고, 이전 버전의 버그가 여전히 존재했으며, 프로그램 로딩 시간이 길어지고, 앱이 죽는 횟수도 늘어갔고, 결국 이 회사는 망했다.
출시에 바빠 코드를 마구 짰어요.
기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 유지보수가 불가능할 수준에 이르게 되었다고 한다.
개발자라면 누구나 나쁜코드에 당한 기억이 있을 것이다.
왜 나쁜 코드를 짰을까?
- 이 기능이 급하게 붙어야해서
- 제대로 짤 시간이 없다고 생각해서
- 코드를 다듬는 것에 시간을 쏟았다가 욕 먹을 거 같아서
- 같은 코드를 계속 보는 것이 지겨워서
- 이외에도 밀린 업무가 많아서
- 나중에 고치면 된다고 생각해서
등의 이유로 클린코드를 미루고, 단지 기능이 돌아간다는 것에 안도감을 느끼며 지나쳤을 것이다.
르블랑의 법칙(Leblanc's Law)
- 나중은 결코 오지 않는다. (Later Equals Never)
나쁜 코드로 치르는 대가
- 개발 속도를 크게 저하시킨다.
- 유지보수가 어려워 진도가 안나간다.
- 빨리빨리에 집착하다보면 1-2년만 지나면 굼뱅이처럼 느려지게 된다.
- 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다.
- 조금만 고치면 된다가 불가능하다.
- 작은 로직의 변화임에도, 많은 코드를 봐야하기 때문이다.
- 인력을 충원하더라도 생산성이 크게 개선되지 않는다.
- 뒤늦게 클린코드의 중요성을 깨달았을 땐, 리팩토링에 엄청난 시간을 쏟아야 할 것이다.
꾸준히 빠르게 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
대부들의 말씀
- 유지보수를 위한 코드
- 에러 처리
- 성능 최적화
- 한 가지 기능만 수행
- 가독성 강조
명쾌한 추상화 - 사실에 기반하며, 반드시 필요한 내용만 담아야 한다.
- 가독성 강조
- 다른 사람의 유지보수성
- 한 가지 기능만 수행
- 코드는 작을수록 좋다.
- 중복을 피하라
- 한 기능만 수행하라
- 제대로 표현하라
- 작게 추상화하라
- 코드를 보며 짐작했던 기능이 그대로 수행된다면 깨끗한 코드