- Today
- Total
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
- Kotlin
- 젠킨스
- network
- SpringBoot
- 브랜치전략
- Java
- 후기
- 만들면서 배우는 클린 아키텍처
- Project
- JPA
- 캐싱전략
- 책
- docker
- Spring Security
- jenkins
- container
- JWT
- SPRING JWT
- 스프링
- 리뷰
- 팀네이버 공채
- chrome80
- redis
- spring
- websocket
- EntityTransaction
- infra
- LazyInitialization
- 프로젝트
- 팀네이버
PPAK
[책 리뷰] 클린 코드 본문
지난 포스팅에서도 언급했듯 2023년도에는 현실적으로 운영 가능한 시스템을 구축하는 능력을 키우는데 초점을 맞췄다. 그 중 하반기는 탄탄한 시스템을 구축하기 위한 협업 방식을 습득하는데 집중했고, 이를 위해 프로그래밍 스킬 외에도 다양한 소프트 스킬을 키우기 위해서 노력했다.
특히, '내가 새로운 팀에 합류하게 되면 어떻게 잘 적응할 수 있을까' 라는 생각을 중심으로 고민했고 결과적으로 협업에 도움될 수 있는 보편적이고 포괄적인(기본이 되는) 능력을 키우고자 했다.
클린 코드는 이러한 포괄적인 능력을 키우는데 굉장히 적합한 책이라고 생각한다. 책의 앞부분에서는 클린한 코드를 작성하기 위한 여러 가지 패턴(단순히 코드를 작성할 때 주의할 점부터 클래스 작성법, 테스트, 예외 처리 방법까지)을 소개하고, 뒤에서 이러한 패턴을 실제 코드에 적용하는 방식을 소개한다.
'오브젝트'와 같이 소위 '냄새가 나는' 코드를 저자가 지향하는 방향으로 개선하는 방법을 나열한 챕터가 있는데, 실제 운영 환경에 사용되는 코드를 가져와 리팩토링 한다는 점에서 오브젝트와는 다소 차이가 있긴 하다. (개인적으로는 코드를 이해하는데 시간이 많이 소요됐다.)
마지막 챕터(냄새와 휴리스틱)에서는 저자(로버트 C. 마틴)가 사례(코드 냄새)를 소개하는데, 이펙티브 자바에서 아이템을 설명하는 방식과 유사하게 느껴졌고 책의 전체적인 내용을 복습하는 느낌이 들어서 읽기 편했던 것 같다.
짧은 정리
의미 전달
책에서 이야기하는 것에서 중요한 키워드가 뭘까 생각했을 때 바로 떠오른 것이 의미 전달이다.
우선 책에서 좋은 주석 작성법, 명명법, 코드 경계 나누기, 코드 결합도를 낮추는 방법 등등 미래의 리팩토링을 고려한 코드 작성 방법을 소개한다. 그 중 공통적인 내용이 (나를 포함한) 시간이 지난 후에 코드를 다시 읽는 사람이 이해 가능한 이름, 구조를 만드는 것인데, 이를 위해 작성한 코드가 내 의도에 맞게 '의미 전달' 이 되는가? 를 한번 더 생각해보는 것이 중요하지 않을까 생각이 든다.
null 은 주지도 받지도 말자
자바 코드를 작성하다 보면 필연적으로 생기는 고민이 있다.
1. 인스턴스 없이 null이 넘어온다면? -> 검사 해야 하나? -> null이면 어떤 예외를?
2. 유효하지 않은 요청이면 null을 넘기나? -> null이 아니면 예외를 던지나? default 객체를 넘기나?
두 가지 모두 null을 다루기 때문에 생기는 고민인데, 책에서는 null 은 전달하지도 반환하지도 말라고 한다.
null을 반환하지 않는 것은 쉽다. 기존 null을 반환하는 케이스를 모두 예외 혹은 default 객체를 만들어 넘기면 된다.
반면 null을 넘기는 경우는 어떻게 할까? 이 때는 적절한 코드 작성 정책이 필요하다고 책에서는 이야기 한다.
null을 반환하기 보다는 적절한 예외를 던져주는 것이 장애의 전파를 막을 수 있고, null을 전달하지 않기로 팀원과 약속하면 코드작성할 때 부담이 훨씬 더 줄어들 수 있다.
경계 분리, 그리고 단일 책임 원칙
코드를 작성할 때는 통제 불가능한 외부 패키지에 의존하는 형태가 아닌 내부 코드를 의존하게 코드를 짜도록 하고 외부 패키지를 호출하는 코드를 최소화 하되 이러한 경계(외부 코드 호출부)를 감싸서 관리한다.
책에서는 역시나(?) 단일 책임 원칙에 맞추어 클래스(혹은 메소드)를 분리하는 것에 대해 이야기 하는데, 경계 분리 역시 이러한 단일 책임 원칙 관점과 일치하는 것이지 않을까 생각을 했다.
이 외에도 테스팅, 동시성 처리에 대한 내용을 다루는데 여러 가지 패턴을 학습하는데 도움이 된 것 같다.
사실 [책 리뷰] 객체지향의 사실과 오해, 오브젝트 와 내용적인 측면에서 비슷하게 서술된 내용이 많기도 해서 이번 글에서는 따로 정리하진 않았다.
[책 리뷰] 객체지향의 사실과 오해, 오브젝트
객체지향의 사실과 오해는 약 2달, 오브젝트는 부록을 포함해 약 600페이지 가량의 오브젝트 책을 5달에 걸쳐 다 읽었다. 중간에 다른 일들이 바빠져 2달 정도는 쉬었지만 아무튼 정말 많은 내용
ppaksang.tistory.com
마무리
이 책을 읽으면서 클린한 코드(유지 보수 가능한 코드)를 작성하는 법을 담은 책들이 어느정도 공통된 이야기를 하고 있다는 생각이 들었다.
그 중 인상깊었던 내용 중 하나가 '이 책을 읽어서 기분 좋은 책으로 남기지 말라' 라는 문구였는데, 패턴 몇가지를 읽고만 넘어가지 말고 패턴을 적용한 사례를 분석하고 실제로 적용해 효용이 있는지 느껴보는 것이 중요하다는 것을 강조하는 것을 의미한다. (= 경험이 중요하다)
그래서 다음으로 아키텍처 구현과 관련된 내용이나 예제 시스템을 구현하는 내용을 담은 책을 읽으면 어떨까? 하는 생각이다.(+ 토이 프로젝트도 진행해보면 좋을 것 같다)
'후기' 카테고리의 다른 글
| 2024년 톺아보기 (4) | 2024.12.29 |
|---|---|
| 2023년 톺아보기 (6) | 2023.12.25 |
| [책 리뷰] 도메인 주도 개발 시작하기 (1) | 2023.09.30 |
| [책 리뷰] 객체지향의 사실과 오해, 오브젝트 (3) | 2023.09.10 |
| [책 리뷰] 만들면서 배우는 클린 아키텍처 (4) | 2023.08.16 |