주니어 필수 완독 도서 클린코드를 아라보자

클린코드의 필요성

프로그래머라면 누구나 유지 보수와 재사용성을 강조한다. 애자일 문화가 트랜드로 떠오르고 SPA방식이 발전하면서 그것의 중요성은 더욱 커졌다. 개발을 스터디 하면서 매번 강조를 받았겠지만, 유지 보수와 재사용성의 범위라는건 주관적인 것이라 잘 와닿지 않았던 것이 사실이다. 또 개발 스케줄과 코드 퀄리티의 비례적인 관계?(또 꼭 그런것만은 아닌것 같다..) 때문에 유지 보수와 재사용성의 범위를 보수적이게 잡고 작업했던 것 또한 사실이다. 하지만 그렇게 만들어진 MVP는 추후 발목이 잡힐 일이 반드시 생긴다...반드시..

나쁜 코드에 발목이 잡혀 고생한 기억이 있는가? 조금이라도 프로그램을 짜봤다면 필경 수없이 경험했으리라. 심지어 이름도 있다. '고행'이라 부른다. 우리는 나쁜 코드를 헤쳐나간다. 엉킨 덩굴과 숨겨진 함정으로 가득한 늪지를 힘겹게 헤쳐나간다. 단서나 실마리를 찾으려 발버둥치지만 소용이 없다. 눈앞에는 무의미한 코드만 끝없이 펼쳐진다. 프로그래머라면 누구나 당연히 나쁜코드로 고생한 경험이 있다. 그렇다면 묻겠다. 어째서 나쁜 코드를 짰는가? 급해서? 서두르느라? 아마 그랬으리라. 제대로 짤 시간이 없다고 생각해서, 코드를 다듬느라 시간을 보냈다가 상사한테 욕 먹을까봐, 지켜워서 빨리 끝내려고, 다른 업무가 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고...
?
우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각하고, 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼고, 그래도 안돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한다. 물론 다시 돌아와 나중에 손보겠다 다짐하지만 나중은 결코 오지 않는다.

나쁜 코드가 쌓일 수록 팀 생산성은 떨어진다.
생산성 대 시간이라는 그래프를 보면 알 수 있듯이 나쁜 코드의 초기 작업속도는 번개같다. 번개같이 나아가다 결국 0이라는 생산성에 수렴한다. 쓰레기 코드에 파묻혀 고행의 시간에 빠진 결과다.

태도

코드가 정말이지 너무도 엉망이라 몇 시간으로 예상한 업무가 몇 주로 늘어진 경험이 있는가? 한 줄만 고치면 되리라 예상했다가 모듈을 수백 개 건드린 경험이 있는가? 너무 자주 접하는 모습이다. 코드가 왜 그렇게 되었을까? 좋은 코드가 어째서 순식간에 나쁜 코드로 전락할까? 우리는 온갖 이유를 들이댄다. 원래 설계를 뒤집히는 방향으로 요구사항이 변했다고 불평한다. 일정이 촉박해 제대로 할 시간이 없었다고 한탄한다. 하지만 우리는 작업 가능성을 파악하고, 작업시 들게 되는 공수를 산정하며, 스케쥴 회의를 통해 주최가 되어 결정한다. 우리가 결정한 스케쥴 기간안에 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 그렇게 산정한 기간에는 돌아가는 코드를 만드는게 아니라 제대로 코드를 작성하는 것이다.

1.기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
2.깨끗한 코드는 한 가지를 제대로 한다.
3.의존성을 최대한 줄여야 유지보수가 쉬워진다.
4.오류는 명백한 전략에 의거해 철저히 처리한다.
5.원칙없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
6.깨끗한 코드는 단순하고 직접적이다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
7.아무리 코드가 우아해도 테스트 케이스가 없으면 소용없다.
8.중복을 피하라, 한 기능만 제대로 수행해라, 작게 추상화 하라
9.코드를 읽으면서 짐작했던 기능을 그대로 수행한다면 깨끗한 코드라 불러도 된다.