https://book.naver.com/bookdb/book_detail.naver?bid=7390287 

 

Clean Code

로버트 마틴은 이 책에서 혁명적인 패러다임을 제시한다. 그는 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제해 책 한 권에 담았

book.naver.com

 

클린 코드. 유명하고 프로그래머라면 정말 많이 추천받는 책입니다.

 

저도 아마 대학을 졸업했을 즈음 추천을 받아 구입했는데요.

사놓고 제대로 정독한 적이 없는 것 같아서 매일 1 챕터씩 정리하면서 읽어보려고 합니다.

너무 자세한 내용을 적으면 책의 저작권을 침해하니까요. 중요한 키워드와 Inspiration을 준 문구들을 위주로 제가 가진 경험과 함께 정리해보려고 합니다.

 

 

 

나쁜 코드가 쌓일수록 생산성은 떨어진다. 그러다가 마침내 0에 근접한다.

 

프로그래밍을 할때 자주 쓰는 말이 있습니다.

 

"이게 왜 되지?" 그리고 "이게 왜 안되지?"

 

간단히 생각하면 전자는 원하는 목표에 도착했다는 것이고 후자는 목적을 달성하는데 실패했다는 얘기입니다.

하지만 실제로 저런 상황을 맞이했을 때, 후자의 경우가 디버깅을 통해 문제를 찾기가 더 쉽습니다.

처음부터 접근을 잘못한게 아니라면 버그가 발생한 코드를 찾아 고칠 수 있습니다.

반면 전자는 당장은 코드가 돌아갈지 몰라도 예외 케이스에 걸리거나 이후 다른 문제가 발생했을 때 난감한 상태가 되는 일이 많았습니다.

 

블로그에 포스팅을 작성하면서 예전에 제가 썼던 코드를 보고 수정하는 일이 많은데 제가 쓴 코드이다보니 어지간하면 이해가 되지만 가끔 무슨 생각으로 짠 거지? 싶은 코드들이 있습니다. 

코드를 짠 장본인도 이해하지 못하는 코드를 동료, 상사, 고객들이 이해하길 바라는건 욕심이겠죠.

 

 

 

잘못은 전적으로 프로그래머에게 있다. 우리가 전문가 답지 못했다.

 

책의 부연설명을 조금 덧붙이면, 요구사항이나 기획이 아름답지 못할때 그것을 지적하고 고치는 것도 프로그래머의 일이라는 얘기였습니다.

저도 프로젝트를 진행할 때 기획이 여러번 엎어지거나 FE와 BE간에 명세서나 API 문서를 작성하면서 충돌했던 경험이 있습니다. 왜 그렇게 기능을 개발할 수 없는지, 왜 이런 방식으로 코드를 짜는지 설득하려면 내 코드가 그만큼 깔끔하고 정확해야 하겠죠.

 

 

논리가 간단해야 버그가 숨어들지 못한다.

 

PS를 할 때 많이 체감되는 문구입니다.

문제를 보고 떠오른 풀이방법대로 코드를 작성하는 경우가 억지로 예외사항과 조건을 좁혀가며 코드를 작성하는 경우보다 더 정확한 일이 많았습니다.

당연히 버그가 생겼을때 수정하기도 더욱 쉬웠습니다.

 

 

중복을 피하라. 한 기능을 수행하라. 제대로 표현해라. 작게 추상화해라.

 

 

 

클린 한 코드가 왜 필요한지, 왜 써야 하는지 동기를 부여하는 1장이었습니다.

다음 2장은 코드에서 "이름"을 잘 사용하는 방법에 대한 내용이 진행됩니다.

 

 

728x90

+ Recent posts