[책 리뷰] 개발자의 글쓰기

블로그 글을 조금씩 포스팅하면서 느낀 점은 글이 너무 진지한 것 같고 하고 싶은 말은 많은데 정리는 못 해서 어지러운 글이 되는 것 같다.
서점에서 매우 신뢰가 가는 대머리 수염 아저씨가 그려진 표지가 마음에 들기도 하고 악습을 고쳐보고자 이번엔 '개발자의 글쓰기'라는 책을 읽었다.

책 표지

책 내용

정말 개발자가 써야 할 대부분의 글쓰기에 대한 내용이 나와 있다.
처음에 이 책에서 얻고자 하는 것은 개발 블로그 쓰기 기술 말곤 딱히 없었다.
하지만 정작 그런 내용은 책 마지막에 나오고 변수명 짓기, 주석 쓰기, 에러 메시지 쓰기 등 정말 다양한 종류의 글쓰기를 알려준다.

 

가장 좋았던 부분은 '변수 이름 잘 짓는 법'이다.
최근 들어 새로운 컴포넌트를 추가하려고 이름을 지으려는데 기존에 있는 컴포넌트의 이름과 겹치는 경우가 생기다 보니 이름 짓는 게 힘들었다.

특히 긴 이름과 약어를 사용하는 데 있어 고민을 많이 했는데 이 책에서 명확하게 정해주고 납득할 수 있게 설명해준다.

 

개인적으로 이 책은 시니어보단 주니어 개발자들에게 더 좋은 책이라고 생각한다.
시니어들은 나름대로 본인만의 변수명을 정하는 방법이 있을 것이다.
하지만 주니어 개발자, 혹은 학생 같은 경우 명확한 컨벤션 없이 이름을 짓는 경우가 많을 텐데 이 책에선 어떤 변수명이 좋은 변수명인지에 대해 잘 알려준다.

 

그리고 예상외로 좋았던 부분은 '비즈니스를 이해하는 장애 보고서 쓰기'이다.
올해 회고록(링크 넣어라)에서 정했듯이 2021년엔 '비즈니스를 이해하는 개발자'가 되는 것이 목표이다.
이 챕터에서는 서비스에 장애가 생겼을 때 비즈니스적으로 어떻게 전달해야 하는지 개발자 입장에서, 회사 또는 대표 입장에서 설명해준다.
앱에 장애가 생겼을 때 대답하기 가장 힘든 말은 '그래서 이 버그 다시 발생 안 하나요?'이다.

하지만 개발을 하는 사람이라면 모두 알듯이 이건 네, 아니요로 대답할 수 있는 질문이 아니고 매우 난감해진다.
책에선 이러한 상황에 어떤 기준을 가지고 어떻게 대답해야 하는지 설명해준다.
또한 서비스 장애가 생겼을 때 비즈니스 입장에서 얼마나 손해가 생겼는지 측정하는 방법이 나와 있는데 정말 자세한 예시로 설명해주는데 익혀두고 실무에서 사용하면 좋을 것 같다.

 

기술 블로그를 운영하는 기업은 이 책을 한 번쯤 꼭 읽으면 좋을 것 같다. 개발자뿐만 아니라 여러 직군이 어떤 교육을 해야하고 서포트를 해야 하는지 나와 있다.
안 그래도 요즘 회사 개발 블로그 쓰기를 하고 싶지만 고민이 많이 되었는데 책 후반부에 개발 블로그를 위해 기업이 어떤 교육을 해야 하는지 커리큘럼까지 있어 사내에서 공유해볼 예정이다.

마무리

생각보다 많은 정보를 알려주고 있어서 정말 도움이 많이 된 책이다. 한 번 읽고 묵혀두기보단 필요할 때마다 꺼내서 보는 책이 될 것 같다.
2021년엔 개인 블로그도 운영하면서 사내 기술 블로그도 해보고 싶다. 만약 기술 블로그를 하게 된다면 사내에 모든 멤버가 이 책을 읽어야 하지 않을까 싶다.