본문 바로가기
LIFE/Book

"개발자의 글쓰기" 후기 - 저도 잘 쓰고 싶어요

by 코뮤(commu) 2022. 11. 9.
728x90
반응형

점심시간, 출퇴근 시간에 책을 잡고 읽기 시작했다.

오늘은 약 일주일간 내 출퇴근 시간을 책임졌던 "개발자의 글쓰기"에 대한 내 생각, 중요한 것들을 정리해보려고 한다.

 

http://www.yes24.com/Product/Goods/79378905?pid=123487&cosemkid=go15700131051712730&gclid=CjwKCAjwtp2bBhAGEiwAOZZTuBwSw0KSlvSlbWnW04wA_S8D6vRQ6Xu3FmKtCGert4btoog0XKMqFhoCbCcQAvD_BwE 

 

개발자의 글쓰기 - YES24

오직 개발자를 위한 글쓰기의 모든 것을 담았다!이 책은 개발자의 글쓰기 능력을 종합적으로 향상하기 위한 책이다. 코드 안에서는 함수와 변수 이름을 짓는 것부터 주석 쓰는 법, 에러 메시지

www.yes24.com

 

 

이 책을 도서관에서 집게된 것은 책의 제목보다는 소제목 격인 '변수 네이밍부터' 라는 문구에 이끌렸기 때문이다.

당시(사실 아직도) 나는 내 이름 짓기 실력에 자신이 없었다.

물론 코드만 잘 돌아간다면야 뭐가 문제가 되겠느냐 하는 사람들도 있겠지만, 난 아름다운 코드를 작성하고 싶었다.

코드 한 줄을 짜더라도 최대한 간결하지만서도 추후 이 코드를 볼 누군가도 납득이 가게끔 짜고 싶었다.

 

하지만 아직 내가 많은 코드를 작성해보지 않아서 그랬는지, 이름 짓기에 생각보다 시간을 많이 할애하고 있었다.

여전히 새로운 변수를 생성할 때, 새로운 함수, 클래스, 파일이 생길 때 고민했다.

 

아직도 내 브라우저 책갈피 순서 첫번째는 변수명을 지어주는 사이트다.

이 자리를 빌어 감사합니다...(https://www.curioustore.com/#!/)

 

 

내 변수명 짓기 방법은 규칙이 없었다. 없었기에 중구난방했다.

이 책을 읽고 난 후 난 내 나름의 가이드를 세울 수 있었던 것 같다.

책을 읽으며 내가 납득이가고 보편적으로 동의할만한 내용들을 머릿속에 차곡차곡 심었다.

 

내 나름대로 정의내린 것중 기억에 남는 것은 아래와 같다.

 

 

중요한 것은 표기 자체가 아닌 그렇게 쓰는 이유

 

코드의 네이밍 컨벤션은 영어 표기법을 상속받음

유명한 파스칼 표기법과 카멜 표기법은 영어의 대문자 표기원칙을 상속받은 것이다.

 

영어의 대문자 표기 원칙은

중요하거나 크거나 특정한 것을 가리키거나 제목에 해당하는 명사는 첫 글자를 대문자로 작성하고,

그런 명사들이 이어질 때는 첫 글자를 모두 대문자로 쓰고,

명사나 관사가 아닌 동사, 형용사는 모두 소문자를 쓴다.

 

따라서 인터페이스나 클래스같은 객체의 틀은 첫 글자를 대문자로 쓰는 파스칼 표기법을 이용하고,

함수, 변수는 카멜 표기법으로 작성해야겠다고 규칙을 정했다.

 

물론 여태껏 클래스는 파스칼, 함수와 변수는 카멜 표기법을 고집하면서 코드를 썼었지만,

남들이 으레 그러하듯이 나도 별 생각 없이 쓴 것 같은데, 책에서 영어 표기법과 함께 말해줘 더 와닿았던 것 같다.

 

 

검색하기 쉬운 이름으로 짓자

 

내가 이 책의 목차 중에서 가장 공감했던 부분이 이 부분이었다.

코드에서 주석은 중요하지만, 만약 주석없이 이름만으로도 그 동작을 예측할 수 있다면 더할나위 없이 좋을 것이다.

나는 현재 IDE 에서 제공하는 바로가기 기능을 이용해 여러 변수들이 어디에서부터 왔고, 어떤 동작을 하는지 파악하고 있지만

그것은 그 변수의 존재를 알 때나 가능한 일이다.

 

만약 특정 기능을 하는 함수를 내가 어딘가에 구현해 놨는데, 도저히 어디에 있는지 잘 모르겠다면?

답은 검색 뿐이다.

 

그런데 내가 그 기능을 하는 함수를 a 라고 정말 성의없이 정의해놨다면, 난 아마 꼼짝없이 그 기능을 처음부터 다시 구현해야할 것이다.

뭐 물론 극단적인 예시지만,

변수명을 정할 때 보편적인 시각에서 '이런 기능은 이렇게 검색할 것이다' 라는 생각을 하고 짓는 것과

그렇지 않을 때의 변수명은 크게 달라지지 않을까 생각한다.

 

 

 

책의 후반부는 개발 블로그에 대한 내용이 이어진다.

나도 현재 블로그를 운영하는 입장에서, 집중하지 않을 수가 없었다.

 

그 중 집중하며 봤던 부분은 기술 블로그의 4중류, 저, 술, 편, 집 이라는 파트이다.

 

해당 파트를 읽고 포스팅하는 글의 구분이 명확해졌다.

 

구분 내용 종류
직접 경험하고 실험한 과정이나 결과 개발기, 도입기, 적용기
어떤 것을 분석하여 의미를 풀이하고 해석한 것 기술 소개, 용어 분석, 에러 해결 방법 등
산만하고 복잡한 자료를 편집해 질서를 부여한 것 프로그램 설치/설정 방법, 튜토리얼, 세미나 후기, 책 리뷰
여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것 명령어 모음, 팁, 규칙

 

 

사실 이 블로그는 2019년부터(내가 학생일 때부터) 학교 수업의 복습용도로, 에러 해결 키노트로, 여러 학습 용도로 마구잡이로 써왔다.

글도 정제되어 있지 않고, 아마 틀린 내용도 많을 것이다.

 

여태까지 난 블로깅을 하면서 어차피 내가 볼건데 뭐 라는 생각을 주로 했던 것 같다.

퀄리티가 좋은 글들, 실제 독자들에게 도움이 될만한 글은 아니었다고 생각한다.

 

그래서 이 블로그는 원래의 목적(?) 처럼 잡다하게 정제되어있지 않은 지식을 담는 용도로 쓰고,

새롭게 기술블로그라고 칭할 수 있을 만한 퀄리티의 포스팅을 뿜어내는 블로그를 파볼까 한다.

(저, 술, 편, 집이 명확한 블로깅)

 

아직 정확하게 일정은 잡히지 않았다만, 블로그를 새로 시작한다면 공지를 드리도록 하겠습니다 'ㅅ'

 

 

 

728x90
반응형