『클린코드』
애자일 소프트웨어 장인정신
로버트 C.마틴 지음 | 박재호·이해영 옮김 | 인사이트
들어가며
이 글은 『클린코드』를 정리와 서평 합니다. 클린코드를 읽으실 분들은 책의 주요 내용을 엿볼 수 있으며, 이미 읽으셨던 분들은 책의 주요 맥락을 상기하는 데 도움이 될 것 입니다.
클린코드는 개발자 온보딩 기간 동안 권장 도서로 읽힐 정도로, 업계에서는 일종의 필독서로 유명합니다. 저 또한 깨끗한 코드가 무엇인지 알고 싶었고, 좋은 코드를 짜는 개발자가 되고 싶었기에 『클린코드』를 읽게 되었습니다.
클린한 코드를 짜기 위해
소프트웨어 엔지니어라면 그저 동작만 하는 코드를 넘어 보다 좋은 코드를 작성해야 합니다.
이 책은 그저 동작만 하는 코드가 아닌 좋은코드를 작성하는 방법을 알려 줍니다. 책의 전반적인 내용은 전문성 있는 저자의 주관적인 의견과, 그를 뒷 받침하는 검증된 사례로 구성되어 있습니다.
읽기 좋은 코드
우리는 저자이다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다.
"읽기 좋은 코드를 작성하자" 라는 문장은 이 책의 핵심주제입니다.
프로그래밍은 글짓기와 비슷합니다. 마치 책을 쓰고, 신문을 만드는 것과 같습니다. 독자가 글을 접했을 때 읽기에 어려움을 느낀다면 이글은 좋은 글이라 할 수 있을까요? 마찬가지로 함께 일하는 동료나 미래의 내가 코드를 접할때 읽기 난해하다는 느낌을 받는다면 이는 좋은 코드라 할 수 없을 것입니다.
의미 있는 이름
클래스와 함수의 이름만 대충 훑어 봐도 이해할 수 있는 코드 작성을 목표로 해야 합니다. 변수나 함수 그리고 클래스의 이름은 의도와 맥락이 분명하게 드러내야 합니다.
의미 없는 이름
UserData,User(Data는 불용어로 취급될 수 있다. User와 UserData의 차이를 알 수 없다.)int d,int num(d와 num과 같은 변수는 의미가 드러나지 않는다.)
함수는 되도록 작게 하나의 목적만
- 함수를 만드는 첫째 규칙은 '작게!'. 함수를 만드는 둘째 구칙은 '더 작게!'다.
- 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다.
한 가지를 하는 함수는 크기가 클 필요가 없습니다. 함수가 확실히 '한 가지' 작업만 하려면 함수 내 추상화 수준을 동일하게 유지 해야 합니다. 한 함수에 여러 추상화 수준이 섞이면 읽는 사람이 헷갈릴 수 있습니다.
나쁜 주석 달지 않기
사실 가장 좋은 코드는 주석 자체가 없는 것이라고 합니다.
그 자체가 클린한 코드는 굳이 주석을 달 필요가 없기 때문입니다. 작성한 코드에 효용성이 없는 '나쁜주석'이 너무 많지는 않은지 고민해봐야 합니다.
코드형식 협의하기
팀원들과 논의를 통해 각 팀의 환경에 맞는 코드스타일과 컨벤션을 협의하고 적용해야 합니다. 이를 통해 팀원 모두가 독자로서 이해하기 쉬운 코드베이스가 완성될 것 입니다.
외부라이브러리 경계 관리하기
경계를 잘 관리하는 것은 코드 유지보수에서 상당히 중요한 개념입니다.
대부분의 개발자는 다수의 외부 라이브러리를 사용합니다. 경계가 제대로 관리되지 않은채 사용되는 라이브러리는 업데이트나 이슈 발생 시 적절한 대응을 하기 어렵고 유지보수 비용을 증가시킵니다. 어댑터 패턴 등 디자인패턴을 통해 라이브러리의 경계를 잘 관리함으로써 이러한 불상사를 방지할 수 있습니다.
클래스 쪼개기
클래스의 구조를 잡는 방법은 다음과 같습니다. 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 나누는 것 입니다. 응집도가 높아지도록 변수와 메서드를 적절히 분리하며 새로운 클래스 두 세 개로 쪼깨야 합니다.
소프트웨어 설계의 품질을 높이는 방법
켄트 백은 단순한 설계 규칙 4가지가 소프트웨어 설계 품질을 크게 높여준다고 말합니다.
그리고 다음과 같은 규칙을 따르면 설계는 '단순하다'고 말합니다.
단순한 설계 규칙 4가지
- 모든 테스트를 실행한다.
- 중복을 없앤다.
- 프로그래머의 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
개발자가 코드를 명백하게 짤수록 다른 사람이 코드를 이해하기 쉬워집니다. 표현을 높이는 가장 중요한 방법은 노력입니다. 이러한 노력은 코드의 결함을 줄이고 유지보수 비용을 줄이기도 합니다. 나중에 코드를 읽는 사람이 바로 자신일 가능성이 높다는 사실을 명심해야 합니다.
일단은 나쁜 코드를 작성하자
깨끗한 코드를 짜기 위해서 가장 중요하게 해야 할 일은 무엇일까요? 바로 더러운 코드 짜기입니다. 깨끗한 코드는 한순간에 완성되는 것이 아닙니다. 우선 지저분한 코드가 작성되어야 비로소 코드를 깨끗하게 정리할 수 있습니다.
14장 점진적인 개선 에서는 일단은 코드를 작성할 것을 이야기합니다. 다소 지저분하더라도 말이죠. 그리고 그 코드를 내버려두는 것이 아니라, 점진적으로 개선할 것을 이야기합니다.
총평
클린코드를 스터디하다
이 책의 분량은 500페이지가 넘습니다.
혼자서라면 전부 읽기 쉽지 않은 분량입니다. 따라서 혼자보다는 친구나 동료와 함께 읽을 것을 추천합니다. 저는 사내 북클럽을 통해서 이 책을 읽었습니다. 내용이 많지만 어렵지는 않기 때문에, 정해진 기간 동안 특정 분량을 읽고 모이는 방식이 좋았습니다. 또한, 동료와 함께 읽는다면 팀 자체의 코드 품질에 대한 건실한 논의가 가능할것 같습니다.
실제로 적용해보니
프로젝트를 병행하며 클린코드를 읽었기 때문에 여러 사례를 실제 코드에 적용해 볼 수 있었습니다.
이전에는 큰 고민 없이 관행적으로 코드를 작성했었다면, 이후에는 클린코드에서 익힌 내용을 고민하고 적용하며 코드를 작성하고 있습니다. 즉 의식적으로 읽기 좋고 지속가능한 코드를 작성하고자 노력하고 있습니다.
그리고 이러한 변화는 팀 차원에서도 생겨났습니다. 팀원 모두가 다 함께 클린코드를 읽고 고민한 결과 팀에서 작성한 코드의 구조와 가독성 전반적이 개선되었습니다. 이는 코드리뷰에도 긍정적인 영향을 주었습니다.
전부 읽을 필요는 없어요
목차를 보며 필요한 챕터만 골라 읽는 방법도 좋을 것 같습니다. 순서대로 읽더라도 14장 정도까지만 읽어도 충분하다고 생각합니다. 이후에는 코드 예시가 대부분이고 Java와 특정 라이브러리에 매우 종속적인 내용입니다.
맹신하지는 말 것
물론 이 책의 모든 내용이 정답이 아니며, 신봉할 필요는 없습니다. 실제로 특정 내용은 수긍하기 어렵고 논쟁의 대상이 되기도 하였습니다.
그러나 이 책이 코드를 작성하는데 있어 하나의 유용한 기준이 될 수 있음은 분명하다고 생각합니다. 이는 아무런 고민과 노력 없이 그저 동작만 하는 코드를 작성하는 것과는 분명한 차이가 있다고 생각합니다. 특히 실무와 협업으로 작성되는 코드에서는 더욱이 그렇습니다. 따라서 자신과 팀의 상황에 맞도록 고민하고 적용하는 것은 분명히 유용할 것 같습니다.
일단은 추천해요
실무에서 작성된 코드는 대부분 일회적이지 않습니다. 나를 포함한 누군가는 해당 코드를 계속 읽을 것이며, 누군가는 개선과 유지 보수를 이어갈 것입니다. 따라서 우리는 독자를 위해 노력을 들여 코드를 작성해야 합니다. 이는 결과적으로 전체적인 비용을 줄이는 방법 입니다.
책을 읽으며 공감되고 도움되는 내용이 많았습니다. 평소에 나쁜 코드를 작성하고 있었다는 반증인 것 같습니다. 이전의 저와 같이 큰 고민과 노력 없이 코드를 작성하고 있는 개발자분들은 이 책을 읽어 보셨으면 좋겠습니다.
3줄 요약
- 총평 요약 : 코드의 품질과 가독성을 개선하는 데 도움이 되는 책
- 추천 대상 : 실무와 협업을 수행하는 개발자, 좋은 코드를 작성하고 싶은 개발자
- 별점 : ⭐⭐⭐⭐⭐
