📌 해당 책을 선택한 이유?

해당 책을 선택하기 전
내가 직면하고 있던 문제는 다음과 같았다.

자소서의 중요성 ✍️

1. 협업 경험을 쌓기위해
2. 함께 성장해나갈 동료들을 찾기 위해
3. 더 좋은 개발자로 성장하는 발판을 얻기 위해

위와 같은 다양한 목표를 위해 개발자들은 연합 동아리 또는 부트캠프에 지원을 하게되면
자신을 어필해야 하는 자소서를 써야한다.

그렇기 때문에 다양한 기회를 쟁취하려면,
좋은 글쓰기 실력의 필요성을 절실히 느끼게 된다.

나 역시 많은 동아리나 교육 과정에 참여하기 위해 다양한 주제로 자소서를 썼는데,
지원의 시작 단계인 자소서에서 떨어지는 경우가 빈번했다.

시작하기도 전에 떨어진 기분이라
어떻게하면 개발과 동시에 글쓰기 보완 할수 있을까에
대한 질문을 스스로에게 던졌다.

그래서 결론은?

고민 끝내 내린 결론 === 테크 블로그를 시작하자 📚

테크 블로그를 보여주기 식이 아닌,
꾸준하고 신중하게 글을 쓰면서 개발과 글쓰기 실력을 동시에 늘리고 싶다는 생각을 했다.

많은 테크 블로그를 보면 자신의 생각을 세련되게 녹여낸 개발자들을 자주 볼 수 있고,
나도 그들을 닮고 싶다는 갈망이 있었다.

너무 의욕만 앞선것일까?
블로그를 시작하면서 나 나름대로 신중하고,
쉽게 글을 쓰려 노력하지만
독자들이 내가 생각한 방법을 그대로 이해할 수 있는지에 대한 의문이 생겼었다.

글쓰기 실력을 늘리고 싶다는 갈망을 하던 중,
개발자에게 적합한 글쓰기 지침서를 제공한다는
"개발자의 글쓰기"라는 책이 눈에 들어왔다.

이 책에서는 내가 궁금했던 좋은 글을 쓰는 방법의 비밀이
모두 담겨있을것만 같은 느낌이 들어
해당 책을 읽게 되었다.

📌 인상 깊었던 내용

해당 책을 읽으며 인상 깊었다고 생각한 4가지 내용에 대해 느낀점을 설명해보겠다.

좋은 이름의 기준, SMART ✏️

easy to Search
easy to Mix
easy to Agree
easy to Remember
easy to Type

각 글자의 맨 앞글자를 따서 만든 좋은 이름을 짓는 방법을 축약하여 SMART라고
해당 책에선 표현했다.

해당 내용을 간략하게 설명하면
말 그대로 가독성이 좋은 네이밍의 중요성을 강조하고 있다.

빠른 이해를 위해 특정 api콜을 기다리는 용도로 loading이라는 변수를 선언했다고 생각해보자

다른 개발자가 보거나, 많은 시간이 지난 후 내가 다시 해당 코드를 봤을 때,
1. loading이 true일 때 로딩 중인 것인지,
2. loading이 false일 때 로딩 중인 것인지가 헷갈리게 된다.

이를 개선하여 해당 경우에서 loading이 아닌
isLoading이라는 변수를 선언했다고 생각해보자.

해당 변수는 누가 설명을 해주지 않아도
true일 때 로딩 중이고,
false일 때 로딩이 완료됐다는 사실을 알아차릴수 있다.

이와 같이 가독성이 좋은 네이밍은 큰 프로젝트나 현업에서 일을 할때
큰 영향력을 펼칠 것이라고 생각한다.

나 역시 개인 프로젝트를 제작하면서
좋은 네이밍이 빠른 개발 속도로 이어진다는 경험을 하여
항상 좋은 네이밍을 짓기 위해서 고민 또 고민을 한다.

UI / UX를 생각한 구조 및 디자인 😍

프론트엔드 개발자라면 당연히
사용자가 쓰기 편한 구조와 화면 (UI),
좋은 사용자 경험 (UX)의 제공을 1순위로 둬야한다.

어떻게 하면 같은 데이터라도 사람들에게 좋은 사용자 경험을 제공할까에 대한 생각을 할수 있었던 내용이였다.

한눈에 이해 가능한 좋은 사용자 경험의 예시를 들어보겠다.

1. 100000000
2. 100,000,000

둘 중 어느 숫자가 한눈에 읽기 편한지 선택을 하게 하면
모두가 2번을 선택할 것이다.

두 숫자는 같은 1억이라는 숫자를 의미하지만
쉼표의 존재로 인해 같은 데이터가 다른 사용자 경험을 제공한다.

사소한 차이지만,
사용자 경험은 극과 극으로 갈릴 수 있다.

이처럼 사용자 입장에서 어떤 것이 편할지 항상 고민하는 것은
프론트엔드 개발자의 필수 덕목이라고 생각한다.

체인지 로그 쓰는 법 🛠

개발자라면 자신이 한 일이나 수정한 일들을 정리하는 체인지 로그를 쓰곤 한다.

하지만, 좋지 않은 체인지 로그는
자신이 쓸데없는 일을 하거나 비생산적인 일을 하고 있다고
오해받을 수 있다.

그렇기 때문에 체인지 로그를 잘 정리해서 적는 것 또한
개발자에게 중요한 스킬이다.

예를 들면 자신이 작업한 일에 대해 체인지 로그를 쓰려는데
어떤 내용을 우선순위로 써야할까에 대해 고민을 해보자.

1. 고객이 관심있는 내용
2. 개발자가 노력을 많이 들인것

정답은 당연히 전자인 고객이 관심있는 내용을 중점적으로 적어야 한다.

체인지로그를 작성하는 내용에 대한 우선순위를 매기자면

1. 고객이 관심있는 내용 & 개발자가 노력을 많이 들인것
2. 고객이 관심있는 내용 & 개발자가 노력을 별로 안들인것
3. 고객이 관심없는 내용 & 개발자가 노력을 많이 들인것

해당 순위로 체인지로그를 써야하며
고객이 관심없는 내용과 개발자가 노력을 별로 안들인 것은
과감하게 체인지 로그에서 빼버려야 한다.

너무 쉽게 풀어쓰지 않아도 된다 🤔

테크 블로그에 글을 쓸 때
많은 사람들은 어떻게 하면 더 쉽게 설명할 수 있을까에 대해
끊임없이 고민하곤 한다.

나 역시 내 생각이 글에 잘 담길 수 있도록 고민하고 또 고민하곤 한다.

"어떻게 하면 해당 내용을 더 재미있고 쉽게 설명할 수 있을까?"
"어떤 예시가 해당 내용에 가장 적절한 예시일까?"

해당 문제를 해결하기 위해
글을 적을 때 그림과 함께 설명을 하면
독자가 더 쉽게 이해할 수 있다.

예시를 들 때,
주관적인 예시가 아닌 객관적인 예시를 들면
독자들이 더 쉽게 이해할 수 있다.

사실 객관적으로 보면
테크 블로그를 읽는 독자 역시 개발자일 가능성이 매우 높기 때문에
너무 풀어서 설명하는 것 보다 어느정도만 설명 한 후,
스스로 공부하게 하는 편이 좋다.

모든 용어를 쉽게 풀어쓰지 말고
차라리 해당 내용에 대한 링크를 달아두는 것이
더 효과적일 것이다.

📌 마무리

재밌었던 내용 😹

급하게 회사에서 예산을 마련해
해결해야 하는 문제에 대해 제시한 보고서의 예를 보자.

냉방기 미교체 시 화재 발생 염려

이런 식으로 윗사람에게 보고를 하면
아무도 조치를 취하지 않을 것이다.

하지만 이런식으로 보고를 했으면 어떻게 될까?

냉방기 폭발 시 서비스 전면 중단
냉방기 폭발 시 대표이사 구속 100%

이런 내용의 보고를 받으면 어떻게든 해당 문제를 해결하기 위해 예산을 마련할 것이다.

이렇게 극단적으로 쓰라는 말이 아니라
중요한 내용이라면 어느정도 강조를 하며 보고를 해야
조치를 취할 가능성이 조금이나마 높아진다는 점이다.

느낀점 👍

글을 쓰면서 의문이 있었던 내용에 대해
어느정도 해결책을 제안해준 책이라고 생각한다.

해당 책에 더 많은 내용이 있지만
모든 내용을 글에 담지 못한 점이 아쉽다고 생각한다.

내용에 관심이 생겼다면
책을 구매해 직접 읽어보는 것도 추천하는 바다.