나와 동료들에게 쉽게 이해하는 글을 쓰기 위한 전략, "개발자의 글쓰기"를 읽은 후기

이 책의 가장 먼저 나오는 내용 중 개발자는 글을 못쓴다? 라는 내용에 긁혀서 끝까지 읽게 되었다. 

먼저, 결론을 말하자면 성격이 다르다고 생각한다. 

최소한 나는 최소의 코드라인을 사용하여, 가독성 있게 작성하는 것을 우선으로 생각하며, 그런 코드가 가치가 있다고 생각한다. (괜히 길어봤자, 읽기만 싫어질 뿐이다)

결국 개발자가 쓴글은 비전공자나, 개발자가 아닌 사람들이 읽기에 재미도 없고, 이해도 안되고 그러니까 글을 못쓴다라고 하는게 아닐까 하는 생각도 있다.

 

이 책에서 챕터하나하나 마다 상황에 따라 글을쓰는 여러가지 방식을 알려준다.

책 제목이 아무래도 "개발자의 글쓰기" 이기 때문에, 프로그램 변수 네이밍부터, 결과값 반환에서 Return Enum Value 등을 명시적으로 이해되도록 쓰는 방법등을 알려준다. 

더 나아가선 장애 보고서, 체인지 로그 작성법, 동료를 위한 주석쓰기 등을 알려주는데 이는 업무를 하면서 충분히 도움될 내용들이라고 생각한다.

 

좋은 많은 내용들이 있었지만, 일을하면서 적용하면 좋을만한 내용을 3가지 정도 작성해보자면 아래와 같다.

 

1. 다른 개발자를 배려하기 위한 주석을 작성하자.

이 글을 읽거나, 도서를 읽은 모두가 잘 알다싶이, 주석이 없어도 이해할만한 코드를 작성하는 것이 가장 좋다.

그러나, 복잡하거나, 설명을 해야하는 내용들은 작성해주는 것이 좋다. 단, 메서드에 대한 코드는 의미를, 주석은 의도를 기반으로 작성하자. 

가끔 메서드의 의미도 잘 이해가 안가는데, 주석도 없는 경우가 있다. 이럴때는 이해도 힘들고 수정도 힘들고, 작성자이외의 다른 사람이 대신 버그를 처리해주기도 힘들다. 
경험상 코드의 의미를 잘 작성한 사람의 코드는 주석이 없어도 비교적으로 이해가 잘 가는 경우가 많았다.

 

2. 체인지 로그의 작성은 분류, 종합, 만족도에 따라 작성한다.

나는 이 글을 읽기 전에, 내가 일하고 있음을 어필하기 위한 수단 중 하나가 개발단계에서 커밋 메시지, 라이브 단계에서는 업데이트 노트 등에 내가 알고 있는 모든 로그를 작성하는 것이라고 생각했다.

그러나, 책에서, 당신 프로그램 버그 많은거 자랑하나? 라고 작성되어 있는 것을 보고 다시한번 생각하게 되었다.

모든 개발자에게 있어서 버그는 애증의 관계다. 버그가 있어도 불안하고, 버그가 없으면 도대체 왜 되는건데!! 하는 상황이 심심찮게 나온다. 물론, 나도 자주 그런다. 음.. 이건 백퍼야 버그날리가 없지 하는곳에서 버그가 나고, 반대의 경우에선 왜 되는것이지? 하는 경우가 있다. 
이 내용은 철저히 개발자라면 많이 작성해서 나 일 많이했어요! 를 어필하고 싶겠지만, 또 너 프로그램 버그많음 ㅇㅇ 하는 내용에 마음이 걸리기 때문에, 작성할만한 기준을 잡는다.

회사, 개발자, 독자가 작성하고 싶은 내용인지에 따라 구분하고, 회사의 의견은 독자,개발자 의견보단 조금더 가산한다.

회사, 개발자, 독자 등이 모두 알리고 싶은 내용이라면 자세히쓰고, 2개 이상의 범주가 올리고 싶을때는 비교적 간단하게, 1개의 범주만 알고싶으면 삭제하는 것으로 분류한다. (단, 회사가 알리고 싶은 내용은 추가한다.)
대략 회사,개발자, 독자가 알리거나 알고싶은내용은 게임쪽에서는 캐릭터 직군 추가, 캐릭터 각성, 레이드와 같은 주요 컨텐츠 업데이트 정도 일 것 같다.

회사만 알리고 싶은 내용은 약관 정책, 면책 조항과 같은 법규와 관련된 내용이다.

그래서 체인지 로그의 작성은 무턱대고 많은 내용을 작성하는 것은 지양하는것이 좋다고 생각하며, 중요도, 만족도 등에 따라 분류하여 공유하는 것이 좋다.

 

3. 에러메시지 대신 예방메시지를 쓰도록 하자.

만약, 내가 당장 내일 비행기를 타고 외국에 가고싶다. 
그런데, 비행기 티켓을 끊는것도 그렇고 숙소를 예약하는 것도 그렇고 날짜를 다 정해놓으니까 그제서야 어떠한 이유로 불가능하다고 뜬다. 물론, 날짜가 틀렸거나, 다 팔렸거나 등등의 이유는 설명해주겠지만, 한두번이야 그렇구나 하면서 유저는 다른것을 선택할 것이나, 이게 대여섯번해서 오류가 뜨면 유저 이탈로 이루어진다. ( 나같아도 화나서 다른 대체제 이용한다.) 그런 문제를 예방하기 위해 불가능을 표시하도록 그레이 처리를하거나, 클릭 비활성화 등으로 선처리하여 시각화를 해놓으면 유저가 불가능 한 것을 미리 선택전에 알 수 있기때문에, 감정 소모 없이 유저는 에러메시지보다 더 나은 유저 경험을 할 수 있으며 이렇게 처리하는 것이 유저 이탈을 최소화하며, 서로 윈윈할 수 있는 탁월한 효과를 기대할 수 있을 것이라 생각되어 최대한 예방메시지로 처리하는 것이 옳다고 생각한다.

 

이 책을 읽으며 내가 기존에 갖고있던 생각을 다시해볼 수 있는 시간을 가질 수 있어 읽으면서도 지루하지 않았다.

글을 못쓰거나, 변수 네이밍을 잘 못하겠거나, 주석을 무턱대고 쓴다거나, 특히나 SI프로젝트를 하시는 개발자분들께서는 다른 업계 개발자보다 조금 더 도움이 될 것이라고 생각한다. 

만약 본인이 주니어 개발자거나, 팀 프로젝트를 하거나 하는 분이라면 읽어보는 것을 추천한다.

 

책을 읽기 전, 고민하고 있던 나에게 책을 추천해주고 주문해 읽을 수 있는 기회를 준 여자친구에게 감사의 말을 남깁니다.