클린 코드 (Clean Code) - 애자일 소프트웨어 장인 정신
지은이 : 로버트 C. 마틴
옮긴이 : 박재호, 이해영
출판사 : 인사이트(insight)
❓ 이 책을 읽게 된 이유
클린 코드는 컴공 학생 혹은 개발자라면 누구나 한 번쯤 들어봤을 책이다. 나 또한 학부 3학년 때 언젠가 꼭 이 책을 읽어봐야겠다고 생각했던 책으로, 1년이 지난 이제서야 접하게 되었다. 무지성으로 막 써내려간 코드가 아닌, 더 클린하고 효율적으로 짜여진 코드를 만드는 데에 많은 도움이 될 것이라 판단해서 꼭 한 번 읽어보고 싶었다. 클린 코드에 대한 비판도 여럿 있었지만 난 그 개발자 간의 규칙을 더 자세히 알고 싶었다.
📖 책 소개
애자일 소프트웨어의 혁명적인 패러다임을 제시하는 책이다.
저자 로버트 마틴은 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제하여『Clean Code 클린 코드』에 담았다.
아주 많은 코드를 읽고 그 코드의 무엇이 옳은지, 그른지 생각하며 전문가로서 자신이 지니는 가치를 돌아보기 위해 꾸준히 노력한다면, 이 책을 통해 여러분의 프로그래밍 실력은 한층 더 높아질 것이다. - insight
✍🏻 목차
1장 깨끗한 코드 / 2장 의미 있는 이름 / 3장 함수 / 4장 주석 / 5장 형식 맞추기 / 6장 객체와 자료 구조 / 7장 오류 처리 / 8장 경계 / 9장 단위 테스트 / 10장 클래스 / 11장 시스템 / 12장 창발성(創發性) / 13장 동시성 / 14장 점진적인 개선 / 15장 JUnit 들여다보기 / 16장 SerialDate 리팩터링 / 17장 냄새와 휴리스틱
⭐ 인상깊었던 ..
이 책의 중반부는 사례 연구 위주, 후반부는 휴리스틱 열거라서 그런지책에서 인상 깊었던 부분들이 사실 초반부에 치우쳐져 있다. 이제 이 책을 읽으며 인상 깊었던 글귀들을 적어 보겠다.
르블랑의 법칙
우리 모두는 자신이 짠 쓰레기코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.
소프트웨어 개발에서 흔히 사용되는 르블랑의 법칙을 소개한 부분이다. 이 구절을 읽으며 굉장히 찔렸다. 프로젝트든 뭐든 항상 코드를 짤 때마다 '일단은 되게만 해놓고 나중에 고쳐야지!!' 라고 쉽게 생각한 적이 많았기에 아차 싶었다. (이제 이러한 법칙을 알게 되었으니.. 한 번에 제대로 하는 걸로..)
고치기 쉬운 코드
큰 형님 데이브도 그래디와 마찬가지로 '가독성'을 강조하지만 한 가지 중요한 반전을 더 한다. 데이브는 깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다. 당연하게 들리지만 아무리 강조해도 지나치지 않은 교훈이다. 실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다!
너무 공감되는 구절이였다. 가장 중요한 것은 무엇보다도 제 3자가 읽기 쉽고 고치기 쉬운 코드라고 생각한다. 코드라는게 어느 한 곳에 전시되는 것이 아니라 다른 사람이 그것을 이어 받아서 유지 보수하는 경우가 대부분이기 때문에 그렇게 생각한다. 다른 사람이 고치기 쉬운 코드라.. 굉장히 많은 고민들을 떠올리게 했다.
좋은 이름
의도가 분명한 이름이 정말로 중요하다는 사실을 거듭 강조한다. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
제대로 된 이름은 코드를 이해하고 유지보수하는 데 큰 영향을 미친다. 좋은 이름은 처음에 시간이 걸리더라도 나중에 문제 해결 및 기능 추가를 위한 시간을 아낄 수 있기 때문이다,, 실제로 나도 어떤 프로젝트에 새로 참여했을 때, 변수나 함수 이름 때문에 개발 시에 헷갈렸던 부분이 많아서 힘들었다.
하나의 함수는 하나의 기능만
함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
이 말은 코드를 작성할 때 집중과 명확함의 중요성을 강조하는 것 같다. 또한 추상화 수준을 의미하는 것 같았다. (아직 추상화에 대한 제대로 된 감이 없지만?)
나쁜 주석
부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다.
개발자에게 주석은 꼭 필요하다. 주석 없이 바로 보자마자 어떤 기능을 하는 함수인지 파악할 수 있게 코드를 작성하는 것은 매우 어렵다. 그렇기에 무조건 주석을 다는 습관을 들여야 한다. 동시에 가능한 적고 코드로는 얻을 수 없는 필요한 정보를 제공하는 그런 주석..
객체와 자료 구조
어떤 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다. 우수한 소프트웨어 개발자는 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.
처음 클래스와 객체를 배우고 부터 지금까지 클래스나 객체를 만들 때에 그냥 직관에만 의존했었다. 이 내용을 읽으면서 객체 지향적인 접근과 절차적인 접근의 장단점을 명확하게 알 수 있었다. 이러한 다양한 관점을 이해하며 문제에 맞는 최적의 선택을 하는 능력을 기르는 것은 개발자 자신의 몫인 것 같다.
오류 처리의 필요성
오류 처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.
나 또한 오류 처리를 위한 스킬이 능숙치 않아서 더욱 심도 있게 읽었던 챕터였던 것 같다. 처음 오류 처리를 배울 때는 '이게 왜 필요해? 없어도 잘 돌아가는 것 같은데 안 할래~' 라고 생각한 적이 꽤 있었다. 그러나 이후에 계속 프로그래밍과 관련한 지식을 쌓으며 오류 처리는 프로그램에 중요한 역할을 한다는 것을 깨달았다. 그럼에도 불구하고, 나를 포함한 많은 주니어 개발자들이 이 부분에 대한 고민이 많을 것이라 생각한다.
경계 분리
경계에 위치하는 코드는 깔끔하게 분리한다.
라이브러리나 API 등으로 인해서 외부의 코드를 사용해야 하는 경우에는, Wrapper 클래스로 라이브러리를 감싸서 비즈니스 로직과 라이브러리 로직이 최대한 접촉하지 않도록 하라는 의미인 것 같다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다.
테스트 코드를 깨끗하게 유지하지 않으면 결국은 잃어버린다. 그리고 테스트 케이스가 없으면 실제 코드를 유연하게 만드는 버팀목도 사라진다.
이 부분을 통해 테스트 코드의 중요성과 그 영향력을 강조한다는 것을 느꼈다. 테스트 코드는 코드 품질을 유지하고 기능을 안정적으로 보장하는 중요한 도구이다. 또한 테스트 케이스의 부재는 코드의 유연성을 제한하고 변화에 취약한 상황을 만들 수 있다. 개발자로서 우리는 테스트 코드를 작성하는 데에 충분한 시간과 노력을 투자하여 코드의 견고함과 유연성을 함께 확보해야 겠다는 생각이 들었다.
클래스와 서랍
도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 담고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?
컴포넌트를 효율적으로 관리하는 방법을 나타낸다. 기능과 이름이 명확한 컴포넌트를 나눠 담는 작은 서랍을 사용한 접근 방식은, 코드의 모듈성과 유지보수성을 강조하는 것으로 보인다. 이로써 필요한 도구를 빠르게 찾고 사용할 수 있을것이다. 반면 큰 서랍을 사용한 접근 방식은 빠르게 도구를 찾지 않고 빠르게 작업을 진행할 수 있다는 점에서 유용하지만, 시간이 지날수록 도구를 찾는 것이 어려워지거나 코드 베이스가 복잡해질수록 유지보수가 어려워질 가능성이 있다. 종합적으로 보았을 때, 개발 프로세스의 능률과 코드 품질을 함께 관리하는 방식을 잘 선택해서 사용해야한다는 생각이 들었다.
🤓 총평
클리 코드는 명실상부 개발자 필독서이다. 솔직히 말하면 재미로 읽기엔 어려운 책이라 생각한다. 그렇지만 이 책을 읽으면서 공감 가는 문장과 더불어 다짐하게 되는 것들이 많아서 만족스러웠다.
물론 실제로 코딩을 하다가 보면 모든 원칙을 지키기엔 아주 어렵다는 것을 알고 있지만, 그럼에도 불구하고 클린 코드는 유지보수와 확장성을 위해 필수적이다. 가독성이 좋고 명확한 의미를 전달하는 클린 코드는 자신의 업무 능력 향상 뿐만 아니라 다른 사람과의 협업에 있어서도 아주 큰 역할을 한다.
그렇지만 이 책을 한 번만 읽기엔 클린 코드 원칙들을 모두 이해하고 적용하는 것이 어려울 것 같다. 아직 동시성, 리팩토링, TDD, 테스트 같은 부분들은 잘 접해보지 않아서 모두 제대로 이해할 수 없었기에, 먼 나중에 코딩에 더 익숙해졌을 때 다시 읽어보고 싶은 책이다! 👍🏻🤭
