책을 읽기 전 내가 생각했던 클린코드란?
내 코드 그리고 다른 사람의 코드를 읽으면서
'이 코드는 잘 읽히고 잘 이해가 된다.'
'이 코드는 너무 복잡하다. 이해하기 힘들다.'
이런 생각을 무의식적으로 하다보니 대충 이런 게 좋은 코드, 클린코드인 것 같다는 생각을 했지
구체적으로 "이것이 클린코드다"라고 정의하지는 못했던 것 같다.
앞으로 더 나은 개발자, 성장하는 개발자가 되기 위해, 그리고 나를 위해서도 같이 일하는 동료를 위해서도 내 코드를 볼 제 3자를 위해서도 클린 코드로 코드를 짜는 것은 중요한 과제이기에 이 책을 읽게 되었다.
1장
나쁜 코드로 치르는 대가가 생각보다 굉장하다는 것을 알게 되었다. 하지만 이 점에 대해 생각을 해보지 못했을 뿐이지 어쩌면 당연한 것이다.
상상을 해보자.
나 혼자 1인 프로젝트를 하는데 내가 작성한 코드가 다 나쁜 코드라면..
내가 쓴 코드이지만 복잡하고.. 이해 안되고.. 어디서부터 어떻게 고쳐야할지 몰라서 굉장히 막막할 것이고 시간도 굉장히 많이 소모될 것이다.
이 상황이 팀프로젝트에 적용된다면? 상상만해도 정말 그 코드를 건드릴 용기가 나지 않는다.
이 부분을 보고 클린 코드로 작성해야겠다는 결심이 들었다.
그리고 생각보다 여러 명의 사람들이 클린 코드에 대한 정의를 내렸다는 것을 알게 되었다.
그들의 말을 종합해보면 "읽기 쉬운 코드, 이해가 잘 되는 코드, 간단한 코드, 고치기 쉬운 코드"가 되지 않을까싶다.
마지막으로 작성한 코드는 시간이 지날수록 퇴보하기 때문에 꾸준한 유지보수가 반드시 필요하다는 것을 알게 되었다.
2장
이 장을 요약하자면 이름을 지을 때는 의도가 명확하게 보이도록, 다른 사람이 봐도 무슨 역할인지 쉽게 알 수 있도록, 헷갈리지 않도록 하는 것이 중요하다는 것이다.
그동안 한 자리의 변수명을 종종 썼는데 자제해야겠다는 생각이 들었다.
3장
이 장은 함수에 관한 장이었는데
"함수는 작게(하나의 함수 안에 코드가 적게 들어가도록) 작성하는 것이 좋다.
그리고 하나의 함수는 하나의 기능만 하는 것이 좋다.
함수는 변수와 다르게 서술적인 이름을 사용하는 것이 좋다.
오류 코드보다 예외를 사용하는 것이 좋다.
반복하지 마라"가 핵심 내용이었던 것 같다.
이 내용을 Spring 공부하면서 들었던 내용이 상기되기도 했다.