개발자의 글쓰기

제목부터 타겟팅이 너무 정확해서 피할 수 없었습니다.

---

정확성, 간결성 그리고 가독성

정확성을 높이면 간결성과 가독성이 낮아진다. 간결성을 높이면 정확성과 가독성이 낮아진다. 가독성을 높이면 간결성과 정확성이 낮아진다.

처음 읽었을 때는 무척 좋았는데... 곱씹을수록 이상합니다. 코드를 작성하고 다시 고쳐나가면서 우리는 '이 코드는 정확성이 부족하니 정확성을 좀 더 올려야지'하고 수정하지 않습니다. 의도적으로 '가독성'을 축소해서 해석한 것으로 보입니다. 하지만 빠른 태세 전환...

... 조금만 공부하고 연습하면 개발자 누구나 정확하고 간결하고 가독성이 높은 글을 쓸 수 있다.

---

글쓰기 기본

프롤로그에서 저자는 일반적으로 이야기되는 글쓰기와 코딩을 모두 '글쓰기'로 보고 설명했는데, 여기서는 일반적으로 이야기되는 글쓰기에 관한 내용이 이어집니다. 서술식/개조식/도식에 관한 이야기가 나오는데, 어디까지가 일반적인 구분이고 어느 부분이 저자의 구분인지 궁금해졌습니다. 검색 결과를 볼 때, 서술식/개조식은 원래 많이 비교되는 서술 방식이고, 도식은 저자가 표현 방식을 좀 더 확장해서 포함시킨 것으로 보입니다.

 

외래어 표기법에 대한 내용이 나오는데, 뭘 작성할 때면 늘 고민되는 부분입니다. 영어로 쓸지 한글로 쓸지, 대문자로 시작해야할지. 다 영어로 쓰다보면... 때론 잘 읽히지 않을 수 있고, 어쩌면 그저 재수없어 보일 수도 있고. '블로그' 이런 건 한글로 써도 자연스러운 것 같지만... 커밋 로그 작성 시에 특정 클래스를 가리킨다면 또 영어로 써야만하는 딜레마 등등 고민에 끝이 없습니다.

---

이름 짓기와 주석 쓰기

이번에는 코드 이야기입니다. 후회없는 네이밍을 위해 정말 고민에 고민을 거듭하는 개발자들이 많습니다. '상수는 모두 대문자로 쓴다' 너무 좋은데 Swift 스타일은 또 아닌 것 같아서 미묘하네요. 복수형을 's'로 표현하면 가독성이 떨어질 수 있으니 Array나 ListOf 같은 표현을 제안하기도 합니다. Array나 List는 구현체를 암시하고 있어서 조금 꺼려지는데, 여튼 결론은 어떤 게 더 좋다에는 개인차가 있으니, 프로젝트 안에서 규칙 통일이 가장 중요하다 입니다.

---

후기

책을 읽으면서 두 권의 다른 책이 계속 생각났습니다.

내 문장이 그렇게 이상한가요?

읽기 좋은 코드가 좋은 코드다

둘 다 아주 좋게 읽었던 책들인데, 그 때문인지 이 책은 저 둘 사이의 어딘가에 위치한 혼종처럼 느껴졌는데요. 특히 5장 이후부터는 거의 사족에 가깝습니다. 조금 더 정확하게 표현하고 싶은데 정제가 잘 안되네요.

 

글쓰기는 대부분의 개발자들에게 영원한 숙제입니다. 고민을 안 할 수 없기 때문에 경험이 점점 쌓이다보면 누구나 나름의 주관을 갖게 된다고 생각합니다. 뒤로 갈수록 책이 점점 어려워지고 있다는 생각을 많이 했습니다. 내용이 어려워진다기보다는... '이럴 때는 이렇게 하면 돼'라는 사례들이 나열되는 걸 보면서... 이것들을 외우지 못하면 나는 이 책을 다 읽고도 나아지지 않는 건가하는 불안감을 느꼈습니다. '내 문장이 그렇게 이상한가요?'를 읽으면서도 비슷한 압박을 느꼈던 것 같은데, 문제 상황을 보고 해결책을 찾아 나가는 방법을 배우기보다는 정답을 외워야할 것 같은 부담인거죠.

 

개발자의 글쓰기