뉴비블로거의 "개발자의 글쓰기" 리뷰

최근에 읽은 책인 개발자의 글쓰기다

 

개발자의 글쓰기

 

개발 톡방에서 추천 받은 책이다.

책 제목만 듣고 단순히

블로그 작성법인가?

개발자가 글쓰는 건 무엇이 있을까?

개발자로 일하면서 작성해본 글쓰기는

업무 보고서나 배포내역 같은 비즈니스 보고서만 기억이 났다

회사에 들어가서도 글쓰기 관련해서 알려주는건

"이런 방식으로 이메일 보내세요."

"이런 양식에 맞춰서 작성보내세요" 밖에 없었다

과연 책에서 말하는 글쓰기는 무엇일까 궁금해서 구입했다

 

처음 읽을 땐 비즈니스 방식의 글쓰기와

개발 방식의 다양한 글쓰기 예제에 공감하기도 하고 새로운 걸 알게 되었다

나쁜 예시가 나오는데 레거시 환경에서 사용하던 방식이라 속으로 뜨끔! 거리기도 했는데

지금이라도 나쁜 방식을 고칠 수 있으니 다행이라 생각한다

 

읽고나서 책을 간단히 소개하자면 글로 소통하기다

 

개발자가 글로 소통을 한다는건 무엇일까? 누구랑 소통하지?

소통하는 주체를 간단히 나열하면 개발자, 사용자, 고객이 있다

 

개발자와 소통

우선 개발자와 소통을 말하겠다

개발자는 코드로 이야기한다는 말을 들어봤을거다

좋은 코드는 주석없어도 누구나 이해할 수 있다는 말이다

좋은 코드는 무엇일까?  좋은 코드의 조건으로 네이밍과 주석을 예시로 들었다.

단순히 네이밍과 주석을 잘하자!가 아닌

어떻게 해야 불필요하고 나쁜 네이밍을 피하면서 좋은 네이밍으로 작성하는지

주석도 최소한의 작성법을 알려주면서 개발에 불필요한 시간낭비를 안하게 가이드 해준다

그 외에도 기본적인 띄어쓰기 등을 알려준다

 

나는 책에서 알려주는 좋은 예시와 나쁜 예시중

대부분 나쁜 예시 위주로 사용했던 걸 깨달았다

레거시 환경에서 결과 위주의 개발을 하다보니

책에서 제시한 좋은 코드는 단순한 업무에 많이 존재했고

복잡한 업무에는 대부분 스파게티 코드로 나쁜 예시에 포함되었었다

주석도 불필요하게 많이 사용한 흔적도 생각이 난다

주석으로 개인생각을 쓰기도 했었다.

 // 임시로 처리해둠 어떻게 바꿔야할까??
 String orderPrice = ...

위의 형식처럼 남겨놓고 삭제를 안해서 다른 개발자에게 혼선을 준 경험이 있다

 

비즈니스 관련 작성법은 회사마다 양식이 있으면 대충 맞춰서 작성해도 넘어갔지만

개발관련해서 제대로 가이드해준 사람은 없었다 물어보면

"그냥 파악해보면 되니깐 대충 하세요"

"이런 결과가 나오게 하세요" 식의 이야기가 많았다

나중엔 시간 들여서 하나씩 수정하긴 했지만, 그래도 책에서 말하는 나쁜 예시에 포함되는 경우가 있다

앞으론 좋은 예시에 맞게 노력해야겠다

 

참고로 코드 부분은 세심하게 설명하지 않고 포괄적으로 설명하고 넘어간다

자세하게 알아보려면 "클린 코드" 같은 전문 서적을 봐야할거같다.

 

 

 

사용자와 소통

개발자로 일하면 사용자와 소통하는 건 무엇이 있을까?

나는 기획자와 사용자가 원하는 요구사항과 결과물 위주로 이야기 했고

매주 배포 후 공지사항도 사용자의 요구사항을 처리한 내역 위주로 작성해서 띄웠다

배포 후 사용자에게 개선할 점 있는지 에러가 있는지 방식의 개발적인 위주로 소통했다

 

하지만 책에서는 내가 몰랐던 소통 방식이 다양했다

에러문구부터 시작해서 배포내역, 공지사항, 설명가이드 등

사용자가 접하는 문구 하나하나 모두 소통으로 인식하고

개발자는 개발자의 관점이 아닌 사용자의 관점에서 접근해야하는 지 알려준다

여기서 개발자의 관점은 개발 중심적인 글쓰기를 말한다

// 개발자 관점
공지 사항
1. API 새로운 기능이 추가되었습니다. getUserInfo(String userId) 로 고객의 상세 정보를 불러 올 수 있습니다
2. 주문 조회 시 잘못 호출된 함수로 에러가 발생했던 걸 수정했습니다
3. 상품 상세 정보 조회가 오래걸려서 쿼리를 튜닝했습니다
4.  ??? 에러를 수정했습니다
5.  ??? 에러를 수정했습니다
6.  ??? 에러를 수정했습니다
7.  ??? 에러를 수정했습니다

 

이걸 보는 사용자는 개발 용어가 많고 에러 수정 내용이 많아서 보기가 힘들고 나중엔 공지사항 자체를 안보게 된다(경험해봤음...)

책에선 개발자의 관점을 계층별로 정리하고 수정해서

사용자의 관점으로 작성하게 가이드해준다

// 사용자의 관점
공지사항
1. 고객의 이름을 클릭하시면 상세정보를 볼 수 있습니다
2. 주문 조회 에러를 수정했습니다
3. 상세 상품 조회 속도를 개선했습니다
4. 그 외 에러사항을 수정했습니다

더 나아가 공지사항, 배포내역도 사용자 관심에 따라 중요도를 정하고 불필요한 부분을 최대한 하나로 합치는 방식으로

가독성을 좋게 글쓰는 법을 알려준다

추가적으로 장애보고서, 상사관점으로 보고서 작성하기, 정치적인 글쓰기 등 다양한 소통 방식을 책에선 설명해주는데

비슷한 경험이 없어서 만약에 한다면 이렇게 작성해야겠구나 하고 넘어갔다

 

 

고객과의 소통

첫회사 시절에는 고객과의 소통을 기획자,PM,PL을 통한 경험밖에 없다

고객에게 보여줄 에러문구부터 고객의 요구사항까지 대부분 기획자를 거친다. 

이후 플랫폼서비스를 하면서 직접 고객과 소통을 하긴 했다.

가끔 고객(구매자)가 사용자(MD)에게 요청해서 넘어오는 요구사항도 있다  

공지사항, 가이드 등 사용자 관점과 비슷하니 넘어가자

 

책에선 고객이 작성한 제안요청서를 기반으로

프로젝트를 수주해서 개발을 하는 이야기를 다룬다(반대로 프로젝트를 따기위한 제안서 작성법도 존재한다)

개발을 진행해보면 누구나 겪는 요구사항 변경을 주제로 이야기하겠다

 

고객이 제안요청서(요구사항)로 외주 용역을 맡긴 이유는 아래와 같다

고객은 자기가 원하는 제품이 정확히 모른다

그러니 고객이 작성한 제안요청서(요구사항)가 애매한 경우가 많다

해당 외주업체는 고객의 애매한 요구사항을 보고 

고객에게 역으로 요구사항을 제시해서

선택하게 만들고 개발을 진행해야한다고 한다

그래도 요구사항은 자주 변경되는 걸 염두해야한다

인천에서 서울까지 자동차로 출근한다고 생각해 보자.
출근 전에 내비게이션을 켜면 추천 경로와 예상 시간을 알려준다.
하지만 운전하기 시작하면 내비게이션을 끊임없이 경로를 재탐색한다.
도로 상황은 실시간으로 변하기 때문이다.

개발도 고객의 요구사항이 끊없이 변화한다

첫 요구사항은 변경될 확률이 높으니 참고하면서

요구사항 변경을 대비해야한다고 나와있다

제시한 방법으론 회원가입이면 회원가입, 로그인이면 로그인 별로

개발이 완료 될 때 마다 고객에게 검수를 받고 진행하는 방식(애자일)으로

변화에 빠르게 대처하자고 한다

 

 

 

그 외 블로그 작성법

책의 가장 마지막에는 기술 블로그 작성하는 3가지 방법이 나와있다

주제의식이 아닌 소재의식 관점으로

특정한 대상이나 상황에 글쓴이만의 방식으로 접근하고

글쓴이의 수준으로 글을 작성해야한다

독자수준은 천차만별이니 관련 전문용어는 간단한 링크로 걸고 넘어가라

재미있게 글을 써야한다

논문처럼 딱딱하게 작성하면 읽는 사람이 재미없어서 다시는 안 온다

기교를 부려야 재미가 있어 다음에도 찾는다

 

 

 

책의 전체를 이야기 못했지만 마무리 해야겠다

나는 블로그를 시작한지 얼마 안되고 글도 몇개없다

글 작성해도 매번 어렵고 시간이 오래걸린다

이게 문장의 흐름이 맞을까? 이렇게 해야 어울릴까?

쓰고 지우기를 몇번이나 반복한지 모르겠지만

꾸준히 글을 쓰고 책을 복습하다보면

나도 글쓰기로 소통을 하는 개발자가 되지 않을까 생각한다.