독자 정보

• 5 ~ 10년 차 개발자(블로그 3년 차)

독서 일자

• 2021. 07

내용

• 작문 원칙 제공
• 작문을 위한 상세 시나리오 제공
• 개발자의 언어를 비개발자(고객/동료)의 언어로 치환하는 과정을 제공 
• 왜 변수 네이밍 컨벤션을 본문에 실었는지...?(내용은 괜찮으나 책의 주제와 연관관계가 강해보이지 않음)

별점

• 4.3/5.0(체계 있는 본문의 구성, 심도가 있음, 추천+)

대상 독자

• 작문의 질 향상을 원하는 인원(Best)
• 블로그를 시작하는 주니어 개발자

선행 도서

• 없음

관련 도서

• 개발자를 위한 글쓰기 가이드

느낀 점

해당 서적은 오류 문구 정의, 가이드 문서 작성, 장애 보고서 작성 등의 중요 문서 작성 후 검토할 때 많이 참고할 것 같다. 그만큼 본문의 구성은 깊이가 있다. 좋은 문서를 작성할 수 있도록 안내해주는 종합 지침서의 느낌을 받았다. 필자의 표현이 너무 추상적이다. 어떻게 종합 지침을 하였는지 서술하겠다. 해당 서적의 파트 중 하나인 "릴리스 노트 작성법"을 축약하였다. 대강 저자는 아래와 같이 최종 문서를 어떻게 구성하는지 상세하게 설명한다. 

• 프로젝트의 개선/릴리스 내역 정리
• 내역의 중요도 분류
• 내역의 주제별 분류
• 사용자 관점, 문구 수정
• 문구 요약 
• 문서 틀에 맞게 적재적소 문구 삽입

끝으로 개발자와 글쓰기의 연관관계를 정리한다. 전적으로 필자의 생각이다. 좋은 개발자의 요소 중 하나는 테크니컬 라이팅 능력이다. 주요 골자는 소통이다. "페이퍼를 이용한 소통". 개발자는 명세서, 설계서, 분석서 등의 문서들을 활용하여 기술과 프로젝트 정보를 효율적으로 전달해야 한다. 소통이 왜 필요해요? 소통은 문제 해결을 위한 선행 행위다. 그래서 개발자에게 있어, 문서 작성 능력은 선택 사항이 아닌 필수 사항이다. 필자가 중요하게 생각하는 문서 작성 능력은 다음과 같다.

• 사용자 관점에 맞는 문서 구조화 능력

쉽게 얘기하면 문서는 객체 지향 개발 방법론의 "객체" 처럼 구조적이었으면 좋겠다. 객체처럼 역할, 책임, 상태, 행위가 있고 이를 통해 상호 협력(소통)을 할 수 있으면 비로소 그것은 좋은 문서가 아닐까 생각한다.

독자 정보

• 5 ~ 10년 차 개발자(블로그 3년 차)

독서 일자

• 2021. 06

내용

• 작문을 위한 시나리오 제공
• 작문할 때 흔히 하는 실수를 간결하게 기재
• 본문 중 메일/회의록 작성 방법은 왜 있는지...?
• 책이 좀 심플함..? 

별점

• 3.5/5.0(가볍게 보기 좋으나 추천은 안한다.)

대상 독자

• 블로그를 시작하는 주니어 개발자(Best)
• 작문의 질 향상을 원하는 인원

선행 도서

• 없음

관련 도서

• 개발자의 글쓰기

느낀 점

필자는 항상 개발과 글쓰기를 동반하였다. 동향 조사, 설계 문서, 가이드 문서 등의 작성을 필수라고 생각하였으며 작성하는 것은 부담이 없었다. 시간이 지나, 필자가 글을 잘 쓰는지? 검증의 작업이 필요했다. 검증은 위와 같이 책으로 진행하였다. 결과는 참패. 필자는 글을 못 쓴다. 필자의 나쁜 버릇은 다음과 같다. 

• ~통해, ~대해, ~이용하여
• 피동태
• 복잡한 번역체 느낌
• 간결하지 않은 문장
• 적은 시간의 검토와 재작성

또한 필자는 2년 전에 블로그에 작성한 글을 보고 놀랐다. 손이 발이 되는 작문력이다. 끔찍하다.

글 쓰는 것은 추가 연구가 필요하다. 기술 문서 또는 책을 볼 때 "문장 구성"을 같이 봐야겠다. 좋은 "문장 구성"은 스크랩하여 레퍼런스로 활용해야겠다.