[책 후기] 개발자의 글쓰기: 글을 잘쓰는 개발자가 되자

흔히 생각하는 개발자의 이미지는 아래 그림과 같이 검은 화면에 알 수 없는 코드들을 치고 있는 장면들을 대부분 생각한다. 물론 제일 중요한 부분이라고 꼽는 다면 코드를 잘 구성하는 것이고, 제일 많은 시간이 아래 그림과 같은 작업을 하는 것일 것이다.

하지만 그에 못지않게 필요한 개발자의 능력이 글쓰기이다.

개발자의 글쓰기

변수 네이밍

특히 내가 처음 개발을 시작했을 때 제일 먼저 겪으면서 제일 어려워 했던 것이 변수의 이름 짓는 것이다.
이펙티브 타입스크립트 후기에서도 언급하였는데, 잘 짜여진 코드란, 제3자가 코드를 보았을 때, 어떤 변수가 어떤 역할을 하고, 무엇을 담고 있는지도 변수만 읽어도 알 수 있고 그래서 술술 읽히는 코드를 말한다.
이처럼 코드를 잘짜기 위한 1번이 코드 네이밍이다.

변수 네이밍 컨벤션에는 파스칼 표기법, 카멜 표기법, 상수의 대문자표기, 패키지와 모듈의 소문자표기, CSS에서의 BEM 표기법등등이 있다. 이 중 내가 제일 기억에 남고, 생각 외였던 부분이 하나가 있다.

변수를 네이밍 할때 너무 줄이다 보면 변수를 보고 의미를 모르는 경우가 많다. 따라서, 변수의 길이가 길더라도, 의미를 알 수 있도록 너무 줄이지 않는 것이 좋다.

이전에는 개발자의 관점에서, 변수의 길이가 너무 길게되니, 입력하기도 힘들고 눈에 들어오지도 않아, 줄이려고 하는 경우가 많았는데, 코드를 읽는 사람의 입장에서는 규칙을 가지고 줄이지 않으면 읽을 수 없겠다는 생각이 들었다. 그리고 이제는 줄이는 것보다 의미를 다 표현하는 변수를 네이밍 하려고 노력하고 있다.

S(easy to Search)
M(easy to Mix)
A(easy to Agree)
R(easy to Remember)

T(easy to Type)

SMART한 이름을 짓는 것이 개발자의 첫번째 숙명이다.

릴리즈문서

아직 취업 준비생으로 현업을 겪어보지 못했기 때문에, 현업에서도 릴리즈 문서를 쓰는 지는 모르겠다.

하지만 위와 같이 github 에 commitlog를 남길 때, PullRequest를 올릴 때도, 다른 사람이 내가 어떤일을 어떻게 했는지를 알 수 있도록 글로 표현을 해야한다.
commit log를 남길때는 개발자와 개발자 사이에 보는 것이기 때문에 내가 어떤 코드를 왜 수정했고, 어떻게 수정했다를 남겨도 상관이 없다. 서로 미리 정해놓은 컨벤션에 맞추어서 표현하면 되기 때문에 비교적 쉽다고 할 수 있다.

하지만 위 네이버 웹툰과 같은 릴리즈 문서에서는 작품의 제목과 이미지를 한눈에 확인할 수 있는 "포스터 썸네일"이 적용되었습니다. 가 commit log나 PR에 쓰여져 있지는 않았을 것이다. 이 책이 나와있듯이, 개발자는 어떻게 표현해야, 사용자가 더 잘이해할 수 있고, 사용자가 개발자들이 어떻게 UI, UX적으로 생각하고 있는지를 알 수 있을지 고민하고 적은 릴리즈 문서일 것이다.

이 두가지만 보아도, 개발자는 영어로된 코드만 작성하는 것이아니라, 이름을 짓고, 문서를 작성하는 데도 능해야 한다는 의견에 이의를 쉽게 제기할 수는 없을 것이다.

에러 메시지

회원가입을 하거나, 로그인할 때에도, 비밀번호가 틀렸다. 확인하는 비밀번호가 다르다. 특수문자가 포함되지 않았다. 등 여러 에러를 확인해서 사용자가 알 수 있는 언어로 표현해야한다.

특히 회원가입 뿐만아니라, 홈페이지가 나오지 않을 때에도 에러메시지를 위와같이 불친절하게, 에러가 발생했다고만 줄 것인가, 혹은 서버 문제로 화면이 표시되지 않는 다는 등의 자세한 에러메시지를 주는 가도 정할 수 있다.

또한 이런 에러가 발생하지 않도록, 유도하는 것도 개발자의 몫이다. 개발자가 웹, 앱 상에서 사용자의 이정표 역할을 해야하는 것이다. 이정표라면 당연히 넓은 스펙트럼의 다양한 사용자들이 잘 알아들을 수 있도록, 정확하게 설명하는 능력이 필요할 것이다.

개발 블로그

이번 2022 인프콘에서 한 발표에서 개발자의 level을 3가지로 나눈다면

1. 강의나 책을 보고 지식을 습득하는 수준

2. 자신이 습득한 지식을 토이프로젝트에 적용해볼 수 있는 수준

3. 자신의 지식과 경험을 정리하여, 다른 사람에게 설명하고 가르칠 수 있는 수준

으로 나눌 수 있다고 한다. 3번째의 자신의 지식과 경험을 다른사람에게 설명하는 가장 처음 기초로 개발자들이 많이 선택하고 있는 부분이 블로그이다.
특히 블로그는 자신의 경험과, 능력, 지식을 마음껏 뽐낼 수 있는 장이다. 개발 분야의 블로그가 더 발전할 수 있는 큰 요소가, 개발하는 사람들은 모르는 지식들을 웹 검색을 통해 많이 알아가기 때문이라고 생각한다. 검색량이 많으니 그 소요를 충족시켜줄 공급을 개발자들이 만들어 내고 있는 것이다.

하지만 주니어 개발자가 지식도 부족한 상태에서 글을 써나아가기란 너무나도 막막한 일일 것이다. 이 책에서는 원래 글쓰기와 개발 블로그를 쓰는 결을 다르게 생각하라고 말 한다.
크게는

첫째, 주제의식을 버리고 소재 의식으로 쓰자! 둘째, 독자 수준이 아니라 자기 수준으로 쓰자! 셋째, 재미있게 글을 쓰자!

블로그의 수준은 내가 정하는 것이고, 그 수준, 그 주제에 맞는 정도의 사람들이 와서 글을 읽게 될 것이다. 그래서 개발 블로그는 자기 수준으로 작성하는 것이 중요하고 너무 쉽게 풀어쓰려고 하지 말라고 한다.

셋째가 나는 제일 어렵다고 생각하는데.... 벨로그에 트렌드에서 사람들에게 많이 읽히는 글은 여러 재밌는 짤들과, 엄청난 필력으로 자연스럽게 글을 읽게 만든다.
뭐 이정도가 되려면 타고나는 것도 있어야 하겠지만, 개발 블로그가 아니더라도 다른 곳에서도 글을 많이 쓰던 사람들이 글을 재밌게 잘 쓰는 것 같다.

나도 그래서 네이버 블로그로, 일상 글들을 많이 올리려고 하면서 노력은 하고 있지만.... 노력이 배신하지를 않기 바랄뿐이다!