약 5개월동안 진행했던 리팩토링 스터디가 마무리되었습니다.
이번 스터디에서는 크리스 짐머만이 쓴 <프로그래밍의 규칙>(박상현 옮김, 한빛미디어)을 읽으며, 좋은 코드 작성법과 유지보수성을 높이는 방법에 대해 고민하는 시간을 가졌습니다.
해당 글에서는 책에서 다룬 21가지 핵심 규칙에 대해서 요약하고, 배운 점 등을 정리해보았습니다.
✨ 좋은 코드를 위해 알아야 하는 규칙들 총 정리!
간단 책 소개
프로그래밍의 규칙은 코드를 더 나은 방향으로 발전시키는 방법을 고민하는 개발자들을 위한 책입니다.
좋은 코드 작성을 위한 21가지 핵심 규칙을 소개하며, 실무에서 어떻게 적용할 수 있는지 인사이트를 제공하는 책 입니다.
이런 분들에게 추천해요!
- 코드 품질을 높이고 싶은 초·중급 개발자
- 유지보수성과 가독성을 고민하는 개발자
- 리팩토링과 코드 개선에 관심 있는 개발자
📖 프로그래밍의 규칙 : 21가지 원칙 정리
책에서 제시하는 21가지 원칙에 대해서 인상 깊었던 부분들을 정리해보았습니다.
1. 최대한 단순하게, 그러나 너무 단순하지 않게
- 최고의 코드는 가장 단순한 코드
- 코드가 책을 읽듯이 위에서 아래로 자연스럽게 흐르는지 체크할 것
- 코드를 쉽게 작성했는지, 동료가 코드를 쉽게 이해하는지 체크할 것
2. 버그는 전염된다
- 버그가 있으면 그 버그에 의존하는 코드가 추가될 가능성이 높음
- 내 코드를 사용하는 동료를 믿지 말 것 (호출하는 코드에 있는 버그 때문)
- 테스트 하기 좋은 코드가 장기적으로 건강하게 유지됨
3. 좋은 이름은 최고의 문서다
- 이름은 우리가 갖는 최초의 문서이자 가장 중요한 문서
- 좋은 이름은 프로그래머의 인지 부하를 많이 덜어줌
- 지나치게 짧거나 일관성이 없는 네이밍은 금지
4. 일반화에는 세 가지 사례가 필요하다
- 필요하지 않으면 구현하지 말 것
- 알고 있는 사용 사례를 기반으로 일반화할 것
5. 첫 번째 최적화 교훈: 최적화하지 말라
- 코드의 단순성 유지가 우선
- 단순한 코드를 빠르게 개선하는 것은 쉬움
- 불필요한 작업을 제거하는 것이 가장 효과적인 최적화
6. 코드 리뷰의 세 가지 장점
- 코드 리뷰는 지식 공유의 기회
- 버그 발견, 코드 이해도 향상, 다른 사람과 공유할 수 있는 코드가 작성될 수 있음
7. 실패 케이스를 제거하라
- 잘못된 사용을 그냥 회피할 수 있게 하는 것보다 아예 불가능하게 만드는 것이 더 좋음
- 실수를 발견하는 것도 좋지만, 실수를 방지하는 것이 더 좋음
- 실수를 방지하는 모든 노력이 시스템을 더욱 견고하게 만듦
8. 실행되지 않는 코드는 작동하지 않는다
- 사용 되지 않는 코드는 삭제할 것
- 언제든지 리포지토리에서 검색할 수 있다는 사실을 기억할 것
9. 요약 가능한 코드를 작성하라
- 코드는 여러 번 읽히므로 독자의 입장에서 작성할 것
- 코드가 간결하게 요약될 수 있는가?
- 그렇다면 추상화를 적용하고, 아니면 사용하지 말 것
- 여기에서 추상화는 복잡한 것들을 이해하는 방법으로 제시했음
10. 복잡성을 격리하라
- 복잡한 부분은 특정 코드 영역에만 존재하도록 관리할 것
- 새로운 기능 추가 시 여러 곳을 수정해야 한다면 구조를 재검토할 것
11. 두 배 좋은가
- 시스템을 변경할 때, 변경 후의 시스템이 현재보다 두 배 더 좋아진다는 확신이 있어야 함
- 새로운 시스템이 현재보다 두 배 좋다면, 재작업의 혼란과 새로운 문제를 감수할 가치가 있음
- 그렇지 않다면, 점진적인 개선이 더 나은 선택일 가능성이 높음
- 새로운 해결책이 기존보다 두 배 더 나은지를 판단하기 위해 측정하거나, 측정이 어려운 경우 추정할 것
- 단순히 약간 더 나아진 것으로 기존을 대체하지 말고, 확실히 더 좋은 것으로 바꾸기 위해 교체할 것
12. 큰 팀에는 강력한 컨벤션이 필요하다
- 여러 스타일을 섞는 것이 문제이기에 일관성 유지가 필수
- 컨벤션은 이해를 향한 지름길이며, 직접 코드를 읽어나가면서 세부 사항을 파악하는 것보다 훨씬 좋음
- 코딩 스타일이 문제인 건 아님 → 여러 스타일을 섞는 것이 문제
13. 산사태를 일으킬 조약돌을 찾으라
- 문제 해결 시, 원인을 정확히 찾을 것
- 시간 거슬러 올라가는 것을 쉽게 만들면 디버깅을 쉽게할 수 있음
- 상태를 제거할 수 있는 모든 곳에서 상태를 제거할 것 (가능한 한 행위를 순수 함수로 구축할 것)
14. 네 가지 맛의 코드
- 가장 복잡한 문제에 대해 가장 단순한 답을 찾아내는 프로그래머가 훌륭한 프로그래머임
- 단순성과 명확성이 가장 중요한 문제라는 사실을 잘 인지할 것
15. 잡초를 뽑으라
- 유지보수를 위해 불필요한 코드는 지속적으로 정리할 것
- 안전하게 제거할 수 있는 코드는 잡초이기에 정리해야 함
- 의도적으로 기능을 변경한다면 그것은 더 이상 잡초가 아님 (그러한 것은 버그이며, 다른 규칙이 적용됨)
16. 코드가 아닌 결과에서부터 작업하라
- 기존 코드 중심으로 문제를 접근하지 말고, 문제의 본질을 먼저 생각할 것
17. 더 쉽게 해결되는 큰 문제도 더러 있다
- 이해한 특정 문제를 푸는 것이 일반적인 문제를 푸는 것보다 나음
- 충분한 사례(보통 3개 이상)가 모이기 전까지 일반화하지 말 것
18. 코드가 스스로 이야기하게 하라
- 미래의 자신을 위해 읽기 쉬운 코드를 작성할 것
- 좋은 주석은 코드가 왜 그렇게 작성되었는지 설명하거나 함수 사용법을 제공하거나 추가 작업이 필요할 수 있는 로직이 무엇인지 알려줌
- 좋은 네이밍은 코드의 목적을 이해하는 데 가장 중요한 첫 번째 문서화 수단임
19. 평행 재작업
- 기능을 수정하기 전, 먼저 수정이 용이하도록 코드 구조를 개선한 후 쉬운 코드를 작성할 것
20. 계산하라
- 자동화는 수동 작업 대비 시간 절약이 가능한 경우에만 할 것
- 비용 대 혜택이 50 대 50이라면 자동화를 하지 말 것
21. 때로는 못질을 해야 한다
- 단기적인 비용 때문에 장기적인 해결책을 포기하지 말 것
- 올바른 문제 해결책을 알고 있지만 작업량 때문에 주저하고 있다면 용기를 내서 작업을 진행할 것
- 단기적인 고통에는 장기적인 혜택이 따른다.
한 줄 요약
👉 "좋은 코드는 명확하고, 단순하며, 유지보수하기 쉬운 코드다!"
📌 완독 후 느낀 점
👍 좋았던 점
이전에는 막연하게 좋은 코드를 추구해야 한다는 것을 인지만 하고 있었는데, 책을 통해 좋은 코드에 대한 구체적인 원칙을 배울 수 있었습니다.
또, 좋은 코드는 어떤 것들을 고려한 코드인지에 대해 감을 잡을 수 있게 되었습니다.
🤔 아쉬웠던 점
책에서 규칙과 함께 예시가 있었는데, 예시 코드가 C++로 되어 있어 이해하는데 어려움이 조금 있었습니다.
저자가 게임 개발자여서 게임 관련된 예시가 종종 있었는데, 이 부분에 대해서는 조금 공감하기 어려운 부분이 있었습니다.
🎯 스터디 회고
스터디는 함께 모여서 책을 읽고, 인상 깊었던 부분에 대해서 이야기를 나누는 방식으로 진행했습니다.
동료들과 다양한 시각을 나누면서 배울 점이 많았고, 기능 구현에 급급했던 제 모습을 반성하는 계기가 되기도 했습니다.
특히 “좋은 코드란 무엇인가?”에 대해 깊이 고민할 수 있었던 점이 가장 큰 수확이었습니다.
🔥 마치며
이번 스터디를 통해 좋은 코드 작성의 원칙과 습관이 얼마나 중요한지 다시금 깨닫게 되었습니다.
앞으로도 코드 품질 개선과 협업을 위해 열심히 노력해보려고 합니다 ㅎㅎ
스터디에서 배운 점들을 바탕으로 다짐을 작성하면서 글을 마무리하겠습니다.
앞으로의 다짐
- 코드 작성 시 명확성과 일관성을 더 신경 쓰기
- 불필요한 복잡성을 줄이고, 단순한 코드를 유지하기
- 테스트 가능성을 고려한 모듈화된 코드 작성 연습하기