최범균 저자님의 책을 처음 접한 것은 예전 스프링5 프로그래밍 입문하기 책이었습니다. 그때의 기억을 생각하면 어렵지 않게 중요한 개념을 쉽게 풀어쓴 책이라 생각됩니다.

육각형 개발자는 종종 개발 블로그 분들이 포스팅을 해주신 것을 봐서 책의 존재는 알고 있었지만 읽을 기회가 없었는데 마침 회사에 비치돼 있어 읽어봤습니다.

공감된 내용 및 정리

책을 읽고 공감된 내용의 일부를 발췌해 봤어요. 몇몇 글은

  • HTTP 프로토콜, 네트워크 프로그래밍 기초, 동시성 처리, 프로그래밍 언어 등 유행에 상관없는 기술은 공부하는 것이 좋다.
  • 기술을 적용할 때는 유연함이 필요하다. 마이크로서비스 아키텍처도 기능이 적고 사용자가 많지 않은데 기능을 잘게 나눠 별도 서비스로 분리하면 서비스를 분리했을 때 얻는 이점이 반감된다. 오히려 시스템만 복잡해지고 운영이 힘들어질 수 있다.
  • 흥미로운 주제가 있다면 관련 자료를 찾아보거나 기술 트렌드에 민감하게 반응하는 인물의 SNS를 찾아보는 것도 괜찮다.
  • 버그를 수정하는 시간보다 버그 원인을 찾는 데 시간이 더 오래 걸리는 경우가 많다.
  • 메서드 추출을 잘 활용하면 코드 가독성을 높이면서 응집도도 함께 높일 수 있다.
  • 변수를 사용할 때는 최초 사용하기 전에 선언하는 게 좋다. 그렇지 않으면 쓸모없는 코드를 읽어야 할 수 있다.
  • 오래된 주석을 삭제하고 싶다면 먼저 확인한 날짜를 코드에 기입한 후에 조금 더 지켜본 뒤(3~6개월)에 삭제하는 것이 좋다.
  • 메서드를 분리할 때는 다음 순서대로 진행한다.
    • 두 기능 중 한 기능을 위한 메서드를 추가한다. 이 메서드는 내부에서 기존 메서드를 호출한다.
    • 기존 메서드를 호출하는 코드가 새 메서드를 호출하도록 변경한다.
    • 기존 메서드의 코드를 새 메서드로 이동한다.
    • 이름을 변경하고, 코드를 정리한다.
  • 루프를 1번 돌아서 여러 로직을 처리하는 것보다 2번 돌려서 하나의 로직씩 처리하는 게 더 이점이 크다. 복잡한 코드보다 이해하기 좋은 코드가 주는 이점이 훨씬 크다.
  • 새로 만들 때의 단점보다 이점이 더 클 때 개선의 방법으로 마이크로서비스를 선택해야 한다.
  • 아키텍처를 설계할 때는 모든 면에서 최고인 아키텍처를 추구하면 안 된다. 모든 게 완벽한 아키텍처가 아닌 가장 나쁘지 않은 아키텍처를 선택해야 한다.
  • 아키텍처가 중요한 이유는 시스템의 골격 역할을 하고, 품질 속성에 영향을 미치기 때문이다.
  • 마이크로서비스 아키텍처를 선택하면 탄력성, 배포 가능성이 커지지만 데이터 무결성을 위한 구조는 더 복잡해진다.
  • 설득을 위한 자료를 작성한다면 SCQA 프레임워크 활용한다.
    • 상황(Situation): 현재 상태와 문맥을 제공한다.
    • 문제점(Complication): 현 상황에서 무엇이 문제 되는지 기술한다.
    • 의문점(Question): 문제점에서 도출되는 의문 사항이다.
    • 해결(Answer): 의문점에 대한 해결책을 제시한다.
  • 5가지 글쓰기 팁
    • 문장 짧게 쓰기
    • 글머리 기호 목록 번호 목록 사용하기
    • 표나 그래프 사용하기
    • 그림 사용하기
    • 시각적 효과 사용하기
  • 복잡한 시스템을 알맞은 단위로 분해하고 진행 계획을 세우는 역량 역시 시니어 개발자가 가져야 할 중요 역량이다. 동료가 제시한 구현 기술 후보 중에서 현재 상황에 맞는 기술을 선택할 수 있는 기준을 갖추는 것도 중요하다.
  • 관리자와 관계 유지 방법(스태프 엔지니어 책 발췌)
    • 관리자를 놀라게 하지 말자. 관리자를 놀라게 하면 신뢰가 사라질 수 있다.
    • 관리자에게 놀라지 말자. 관리자가 모든 세세한 사항을 챙길 것이라고 기대하지 말자. 대신 관리자와 적극적으로 소통해서 정보 피드백을 얻자
    • 관리자에게 관련 정보를 제공하자. 유용하다고 생각하는 정보가 있다면 관리자에게 전달한다.
  • 사회적 기술(구글 엔지니어 책 발췌)
    • 겸손: 우주의 중심은 내가 아니다. 나는 다 알지 못하며 완벽하지도 않다. 그리고 스스로 발전하는 데 열려 있다.
    • 존중: 진심으로 상대를 배려한다. 동료에게 친절히 대하고 동료의 능력과 성취를 인정한다.
    • 신뢰: 동료가 능숙하게 올바른 일을 하리라 믿는다.

추천책

책을 읽다보면 책 안에서 또 다른 책을 추천하는 경우가 많이 있습니다. 아래는 책을 읽으면서 저도 읽어보고 싶어 정리한 책입니다.

  • 개발 관련
    • 레거시 코드 활용 전략(에이콘출판사)
    • 도메인 주도 개발 시작하기(한빛미디어) - 테스트 관련
  • 글쓰기 관련
    • 유시민의 글쓰기 특상(생각의 길)
    • 엔지니어를 위한 문장의 기술(로드북)
    • 마케터의 문장(인풀루엔셜)
    • 내 문장이 그렇게 이상한가요?(유유)
  • 직업 관계 기술
    • 테크니컬 리더(인사이트)
    • 스태프 엔지니어(길벗) - 관리자와 관계를 유지하는 방법 제시
    • 구본형의 THE BOSS 쿨한 동행(살림Biz)
    • 구글 엔지니어는 이렇게 일한다(한빛미디어)
  • 켄트 벡의 구현 패턴(에이콘출판사)

후기 및 감상평

제가 느끼기엔 점점 더 개발자의 역량이 높아지는 것 같습니다. 알아야 할 지식의 범위도 늘어나고 있으며 backend 개발자의 경우로 보면 devops의 역량과 기본적인 front 지식도 필요하다 생각됩니다.

책의 내용을 읽어봤을 때 들었던 느낀 점은 리팩토링 책과 클린코드, 오브젝트, 클린 아키텍쳐 등의 책에서 중요하게 강조한 핵심 내용을 전반적으로 넓고 얇게 다루고 있어서 편하게 읽을 수 있었습니다. 또한, 개발 역량뿐 아니라 커뮤니케이션 기술 및 최신 기술트랜드를 따라가는 방법 등이 있습니다.

책에서 소개한 개념에 대한 예제도 이해하기 쉽게 표현한 것 같으며, 코드도 Java를 조금이라도 해본 적이 있다면 큰 문제 없이 이해할 수 있을 거라 생각됩니다.

종종 책 저자분의 경험담이 나오는데 몇몇 경험담은 조금은 공감도 됐던 것 같아요.

제 생각에 이 책은 0~2년 차 개발자가 읽으면 좋을 것 같습니다. 조금 연차가 있는 개발자분이 보시면 그냥 맞는 얘기를 하는 것 같아 쉽게 쉽게 넘어갈 수 있다 생각됩니다.