오랜만에 글 쓰니까 어색하네..;;

독자 정보

• 5 ~ 10년 차 개발자

독서 일자

• 2022. 02

내용

• 데이터 모델링의 전반적인 개요/배경 설명
• 데이터 모델링의 주체/대상/행위 등과 어카운트 개념을 설명 
• ER 서브타입, 식별/비식별자 기준 설명
• 확장성 있는 모델링 설명(이 모델링 별로야...)

별점

• 4.0/5.0(개발자 입장에서 몰랐던 모델링 개념과 스킬을 소개, 짜임새와 스토리가 있음, 추천+)

대상 독자

• 주니어 개발자
• DB 모델링 경험을 최소 한 번 이상 한 개발자

선행 도서

• DB 모델링 관련 서적 또는 관련 경험을 한번씩 해보는 것을 추천

관련 도서

• -

느낀 점

개발자 입장에서 간접적으로 모델링을 경험할 수 있었다. "현재 사용하고 있는 제품의 DB 모델링은 충분한가?", "과거에 했던 모델링의 필요 개선점?", "개선 했을 때 어떤 점을 더 고려하면 좋을까"와 같은 고민으로 해당 서적을 읽었다. 추상적으로만 인지하고 있던 다음의 사항을 명시적으로 이해할 수 있는 기회가 있었다.

• 주체/대상/행위: 사전에 모델링할 때 인터뷰를 하거나 분석하는 행위들을 객관적으로 얘기를 못 했습니다.  필자가 하는 행위는 모델링할 때 업무 시스템의 "주체/대상/행위"를 추출하는 행위였다.
• ER 서브타입: 보통의 ER 서브타입을 객체 지향의 Sub/Super로 대강 이해했지만 통합, 분리, 혼합이라는 것을 알게 되었다. 이 부분은 더 공부가 필요하다.
• 어카운트 개념: 마스터 데이터, 행위 데이터를 동일한 성격으로 묶는 행위이다. 모델링에 어카운트가 있으면 모델링의 유연성을 제공할 수 있고 업무에서는 유연한 엔티티로 한층 더 유연하게 문제를 해결할 수 있다. 우리가 데이터 모델링할 때 공통적인 것은 묶고 엔티티 간의 연관관계를 맺는다. 연관관계를 연결할 때 징검다리가 필요할 때가 있다. 이때 어카운트가 징검다리 역할을 해준다.

개발자는 한번쯤 읽어보면 정말 좋은 책이라고 생각한다.

독자 정보

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

독서 일자

• 2021. 07

내용

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

별점

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

대상 독자

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

선행 도서

• 없음

관련 도서

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

느낀 점

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

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

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

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

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

독자 정보

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

독서 일자

• 2021. 06

내용

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

별점

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

대상 독자

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

선행 도서

• 없음

관련 도서

• 개발자의 글쓰기

느낀 점

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

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

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

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