우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그 때 그 시절 우리는 르블랑의 법칙(leblanc's Law)을 몰랐다.
나중은 결코 오지 않는다. - p.4
매번 얽히고설킨 코드를 '해독'해서 얽히고설킨 코드를 더한다.
시간이 지나면서 쓰레기 더미는 점점 높아지고 깊어지고 커진다. 청소할 방법이 없다. 불가항력이다. - p.5
시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이라는 사실을 인정하리라. - p.6
나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다. - p.7
기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. - p.7
깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
좋은 소설과 마찬가지로 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야한다. - p.10
중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. - p.14
깨끗한 코드는 읽으면서 놀랄 일이 없어야한다.
프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다.
언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다. - p.15
나는 아직도 사실 좋은 코드가 무엇인지 잘 모르지만 나쁜 코드에 대한 경험이 있기 때문에 나쁜 코드에 대해 다룬 내용들이 특히 공감이 많이 갔다.
나쁜 코드에 대한 데이터가 있으니 좋은 코드가 무엇인지 배우고 구분하는 능력을 기르면 되지 않을까? 싶어 이 책을 꼭 끝까지 읽어야겠다는 결심을 하게 되었다.
몇 년 전에 SI에서 유지보수를 하면서 나쁜 코드로 고생한 경험이 있었고,덕분에 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다는 것을 알 수 있었다. 알 수 없는 변수명, 일관성 없는 코드, 중복 코드, 불필요한 쿼리 등을 보면서 책에서 말한 것처럼 깨끗한 코드를 유지하지 않으면 시스템에 많은 부하를 가져다 준다는 무서운 사실도 알게 되었다..ㅎ
코드를 분석하는데도 시간이 많이 소모가 되는 것은 물론, 추후에도 중복 작업이 많아져서 리팩토링의 필요성을 느껴 7명의 팀원들과 나쁜 코드들을 걷어내는 작업을 한 적도 있었다. 나쁜 코드를 걷어내면서 장기적으로 봤을 때 시간적으로나 비용적으로나 수많은 비용들이 드는구나, 시간이 더 들더라도 깨끗한 코드를 만드는 것이 중요하다는 것을 깨닫게 된 좋은 계기였다.
물론 나도 예외는 아니였다...
남들과 다를 바 없이 기간에 쫓기면서 기능 구현에 급급했던 내 모습을 되돌아보면서 반성할 수 있었다.
'나중에 리팩토링 하면 되겠지'라고 합리화를 하면서 나중으로 미루기도 했었는데 앞으로는 그 때를 고려한 변경하기 쉬운 코드를 구현하는 습관을 들여야겠다. 책에서도 르블랑 법칙을 언급하면서 나중은 결코 오지 않는다고 한다.
아무리 기능이 굴러가게 짠 코드여도 의존성이 높아서 수정은 물론 재활용이 어렵고 남이 알아보기 어려운 코드는 결코 좋은 코드가 될 수 없겠구나라는 생각이 들었다. 역시 기본에 충실하면서 좋은 습관을 들이는 노력을 해야겠다.
저명한 개발자들이 내린 클린코드의 정의는 조금씩 다르면서도 말하고자 하는 것은 같았다.
아직 1장밖에 안 읽었지만 내가 생각하는 '좋은 코드'는 모두가 이해하기 쉬운 가독성이 좋은 코드라고 생각한다.
테스트 케이스가 없는 코드는 깨끗한 코드가 아니다.
아무리 코드가 우아해도, 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.
테스트 코드의 중요성을 알고 있었으나, 해야하는데 미뤄지는 숙제와도 같았다.
테스트 하기 좋은 코드란 어떤 코드인가..?🤔
좋은 코드는 테스트를 하기 쉽다고 하니 좋은 코드를 구현하는 방법부터 터득하는 것이 우선인 것 같다.
또한 테스트 케이스의 중요성에 대해 다룬 9장 단위테스트에서 배우게 될 내용도 기대된다.