육각형 개발자 책 리뷰

출/퇴근, 잠 자기 전 시간을 활용해서 완독을 했다

최범균님이 저자였는데, 최범균님은 Java/백엔드에서 유명한 분이라서 눈이 더 갔다

 

저자소개

최범균 님

최범균님의 책 목록을 살펴보면 1999년에 Java2, 2003년에 JSP 책을 쓰실 정도로 저자로써 오랜 이력을 가진 개발자이자 책 저자시다

중학생때 JSP를 공부하면서 JSP책을 학교 도서관에서 잠시나마 본 적도 있다!!

그리고 DDD Start!, 도메인 주도 개발 시작하기, Spring x.x 책 처럼 인기있는 책을 집필하시기도 하셨다

 

독서 히스토리

출/퇴근을 시간을 주로 활용했다

또한 쿠팡에서 주문한 북커버로 가방에 넣은 책이 훼손되지 않게해서 다녔다!

구겨지지 않는 가죽 북클립으로 북마커도 잘 활용했다

 

목차

1장 들어가며

실패
3년 차
개발이란
개발에 필요한 것

2장 구현 기술과 학습

구현 기술
학습 대상
기술 파기
학습 전략
유행에 상관없는 구현 기술
구현 기술 적용
주의할 점

3장 소프트웨어 가치와 비용

소프트웨어 가치
개발 비용
유지보수 비용을 낮추려면

4장 코드 이해

코드 변경
코드 이해 도구
이해하기 좋은 코드

5장 응집도와 결합도

응집도
결합도

6장 리팩터링

수정 공포와 변경 비용
리팩터링
리팩터링 vs 새로 만들기

7장 테스트

테스트 코드
테스트 가능성
리팩터링을 위한 테스트 작성하기

8장 아키텍처·패턴

아키텍처 고민하기
패턴 익히기

9장 업무 관리

처음부터 끝까지
업무 나누기
완료의 의미
위험 관리
요구 사항은 바뀐다
일정
점진적·반복적 개발
안 된다고 말하기, 대안 제시하기
수작업 줄이기
이유와 목적 생각하기

10장 정리하고 공유하기

글로 정리해서 공유하기
마인드맵 사용
발표하기
외래어 남용하지 않기
글쓰기와 발표가 주는 효과

11장 리더와 팔로워

리더 연습하기
팔로워
겸손·존중·신뢰

맺음말

 

독후감

YES 24의 출판사 리뷰의 첫 두줄을 보자

좋은 시니어 개발자로 성장하기 위한 주니어 개발자 시야 넓히기

이 책은 좋은 시니어 개발자가 되길 원하는 주니어 또는 중니어 개발자를 대상으로 한다.

사실 이 2줄로 전체 요약이 되긴 한다

 

전반적으로 최범균님이 회사에서/개인적으로 경험한 내용을 토대로 주의해야 될 내용 또는 나아가야 할 방향 등에 대해서 알려준다

앞부분(1~7장)은 주니어~중니어

뒷부분(8~11장)은 중니어~시니어

에서 보면 좋을 것 같았다. 하지만 자신의 위치에 상관없이 전체적으로 다 좋은 내용이다!

 

앞부분(1~7장)은 코드레벨에서 좋은 코드를 작성하는 법, 좋은 구조를 가진 코드(응집도/결합도), 기존의 코드를 올바르게 수정하는 법(리팩토링), 작성한 코드를 테스트 하는 방법 등에 대해서 다룬다

내생각 첨부) - 작가님의 생각에 무한 동의

내가 React를 하는 회사에 들어갔다고 해서 jQuery하는 사람들을 얕볼 권한은 없으며, 신규 프로젝트를 개발하는 SI회사에 갔다고 해서 유지보수만 하는 SM회사에 있는 사람들을 욕할 권한은 없다고 한다( 약간 내 비유가 포함되어 있다)
서비스를 운영하면서 맞이한 고객들의 요구사항을 여러 방면에서 받아보고 수정하는 것도 큰 경험이고, 실제 배포를 하고 서비스를 하면서 겪을 수 있는 이슈들도 각각 다르고, React를 단순히 할 줄만 알고, jQuery를 자유롭게 쓰는 개발자보다 못하면, 그건 그냥 최신기술에만 집착하는 개발자일 뿐이다
또한 코드는 더 이상 나의 것(private)이 아니다. Gitlab또는 Github에 가면 이제 남의 코드를 볼 수 있고, 회사의 Repo에 push하는 순간 사내의 모든 구성원들이 내 코드를 보게된다. 코드는 이제 AI가 만들어주는 시대까지 왔다. 여기에서 실력이란 것은 그 코드에 대한 이해를 얼마나 깊이 하고 있나, 이 결과물이 나오기 위해 얼마나 PoC를 했는가, 같은 답이 나오게 하는 다른 방법을 강구해봤는지, 이 과정에서 메모한 것들이 내 실력을 말해준다고 생각한다

 

뒷부분(8~11장)

설계(아키텍쳐/패턴), 업무 관리, 정리하고 공유하기, 리더와 팔로워

내생각 첨부2) - 작가님의 생각에 무한 동의

프론트엔드는 디자이너 또는 퍼블리셔가 완성한 작업물을 대표님 또는 기획팀이 확인을 하고 서로간의 의견일치가 선행되어야 개발 이 진행된다
백엔드는 시스템 아키텍처가 어떤 아키텍처 패턴/디자인 패턴을 구성하고 어떤 도구(프레임워크, 프로그래밍 언어)들을 택할것인지 회사의 CTO, 테크 리드의 의견일치가 선행되어야 개발이 진행된다
고 나는 개인적으로 생각한다
그러므로, 백엔드 개발자로써 계속 년차를 쌓아가다보면 어느 순간 나에게 설계능력을 요구하는 년차가 올 수도 있기 때문에 항상 대비를 하고 있어야 한다
책에서 나온것처럼, 무조건적인 정답의 아키텍처는 없다. 회사가 처한 모든 상황(인원, 자금, 시간, 등)에 맞는 아키텍처와 프레임워크를 선택해야 한다. 예시) MicroService병에만 걸려서 자신만 아는 방법으로만 이끄는 시니어
그리고 년차가 쌓일 수록 코딩만 할 수는 없다. 어느 순간 n명의 팀원들을 이끄는 리더가 되어 있을 수도 있다
그렇기 때문에 개발 외적인 실력(업무 관리, 정리/공유, 리더십)등을 키워야 한다
최근 봤던 몇몇 개발 유튜브에서는 이런것들을 봤다. "도메인 지식만 있는 시니어", "12년차인데 권고사직을 당하고 이직을 계속 실패하는 시니어".
물론 중니어 또는 시니어가 되더라도 구현능력은 필수이다. 나도 이전의 어떤 회사에서 팀장이라는 명함을 달고 Spring Security의 인가/인증도 모르는 사람도 만나봤었다. 그리고 JSP를 사용하기를 몇십년동안 고집하고, SPA로 개발을 해야되는 순간 어떠한 결과물도 내지 못하는 사람도 만나봤었다.
회사에서 어느정도 하는 주니어를 뽑는 것은 쉽고, 그 주니어가 퇴사를 한다고 해서 회사에 큰 영향을 쉽게 미치지는 않는다
하지만 어떤 시니어를 뽑느냐에 따라서 그 팀에 날개를 달아서 시리즈가 쭉쭉 올라가는 성장을 하게 할 수도 있고, 개발팀의 줄퇴사를 야기할 수도 있다고 생각한다
그리고 현재 주니어~중니어인 내 위치에서 나는 이런 물경력을 가진 시니어는 되지 말아야겠다고 다짐을 하며, 오늘도 계속 공부하고 공부한다!!
+ 아! 그리고 항상 겸손해야 한다.. 내가 아무리 남들보다 더 공부하고 조금은 더 뛰어나 보일 순 있어도, 각자 장단점을 가진 불완전한 사람이라고 생각하자!