실용주의 프로그래머

http://www.yes24.com/Product/Goods/107077663

실용주의 프로그래머 - YES24

제가 하고 있는 업무는 애플리케이션을 개발하는 업무는 아니라서 프로그래밍과 관련된 책을 읽는 경우가 많지 않습니다. 보통은 리눅스, 쿠버네티스, 보안과 같은 인프라적인 책을 읽거나 개인 프로젝트 개발에 사용하는 고 언어와 관련된 책들을 읽는 경우가 많습니다. 그래서 이 책도 나온 지 20년이나 되었다고 하지만 한 번도 읽어본 적이 없는 책이었습니다. 그리고 우연히 기회가 닿아서 이 책을 읽게 되었는데요, 프로그래머뿐 아니라 IT에 종사하고 있는 분들이라면 한 번쯤은 읽어볼 만한 책이라는 생각이 들었습니다.

 

목차를 알 수 있겠지만 이 책은 기술을 다루는 책은 아닙니다. 언어를 공부하거나 구현하기 위한 기술을 공부하기 위한 책은 아니고 프로그래머로서 프로그래밍을 하기 위해 필요한 철학, 관점 등을 이야기 하고 있는 책입니다. 그래서 읽기 어렵지 않았고, 꼭 프로그래밍을 할 때가 아니라 기본적인 업무를 할 때에도 도움이 될만한 좋은 내용들이 담겨 있습니다.

 

저자들은 이 책을 통해서 53가지의 철학 이자 관점을 제시하는데요, 저는 개인적으로 「항목 3. 소프트웨어 엔트로피」 와 항목 「9. DRY: 중복의 해악」, 「항목 18. 파워 에디팅」, 「항목 24. 죽은 프로그램은 거짓말을 하지 않는다.」, 그리고 「항목 40. 리팩터링」 이렇게 다섯 개의 내용이 가장 와닿았습니다.

 

「항목 3. 소프트웨어 엔트로피」 는 고치지 않고 내버려 두는 작은 결함, 즉 깨진 창문이 시간이 갈수록 소프트웨어 전체 품질에 미치는 영향력을 설명합니다.

나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라.
- 9 페이지

고쳐야 할 순간을 놓치게 되면 소프트웨어가 어떻게 망가지는지를 알려 주고 있습니다. 이런 건 비단 개발자에게만 해당되는 건 아닙니다. 인프라를 관리하고 운영해야 하는 엔지니어의 입장에서도 다음에 해야지 하고 미뤄 뒀던 수정 사항은 언젠가 큰 부메랑이 되어 장애를 일으키거나 인프라 전반적인 일관성을 해치게 하는 등 결국 엔트로피를 높이고 맙니다. 그래서 깨진 창문을 발견한다면 (물론 쉽진 않겠지만) 바로 고쳐야 합니다.

 

「9. DRY: 중복의 해악」 에서는 중복된 코드가 미치는 영향에 대해 설명합니다. 특히 항목 9에서는 직접 코드를 이용해서 중복된 코드가 어떤 영향을 미치는지 보여 줍니다. 하나를 바꾸기 위해서 너무 많은 곳을 수정해야 하고, 그 수정 사항 마저도 다 챙기지 못한다면 전체 소프트웨어의 품질이 떨어지게 되는 그런 사례를 보여 줍니다. 이런 중복의 해악 항목에서는 테라폼 코드가 많이 떠올랐습니다. 미처 모듈화를 하지 못한 부분에서 수정이 발생하게 되면 grep 같은 명령을 이용해서 해당 항목이 참조되는 것들을 일일히 찾아서 수정해야 했던 제 모습이 주마등 처럼 스쳐 지나갔습니다. 이건 역시 항목 3에서 이야기한 깨진 창문을 그대로 두어서 발생한 문제일 수도 있습니다.

 

「항목 18. 파워 에디팅」 에서는 자신이 사용하고 있는 도구를 잘 사용하는 것이 얼마나 효율성을 높일 수 있는지에 대해 설명 합니다. 다들 많이 사용하는 IntelliJ 나 GoLand 도 책에서 이야기 하는 것처럼 다양한 플러그인 도구를 제공하고 있는데요, 저도 이 도구들에 다양한 플러그인을 설치해서 사용하고 있습니다.

 

「항목 24. 죽은 프로그램은 거짓말을 하지 않는다.」 에서는 에러 처리와 관련된 내용을 다루고 있습니다. 저도 책에서 이야기하는 것처럼 망치지 말고 멈춰라 에 동의하는 편인데요, 오작동을 하는 것보다는 아예 에러를 정확하게 출력하고 멈춰 버리는 게 문제를 파악하기에도 훨씬 쉽고 소프트웨어의 품질에도 도움이 된다고 생각하기 때문입니다.

일반적으로 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다.
- 161 페이지

 

「항목 40. 리팩터링」 은 우리가 알고 있는 코드 리팩터링에 대한 이야기를 하고 있습니다. 리팩터링 부분에서 제가 가장 인상 깊었던 건 바로 아래 구문입니다.

리팩터링은 언제 하는가?
리팩터링은 여러분이 무언가를 알게 되었을 때 한다. 여러분이 작년이나 어제, 심지어 10분 전과 비교해서 더 많이 알게 되었다면, 리팩터링을 한다.
- 302 페이지

저도 제가 만들어 놓은 고 언어 기반의 람다 함수들을 리팩터링 해야 하는데 (코드가 너무 지저분해서.. 역시 이것도 엔트로피겠죠.) 언제 해야 하나 이런 생각을 가지고 있었습니다. 하지만 이 책에서 말하는 것처럼 리팩터링을 해야 하는 시기라는 건 따로 있지 않았습니다. 바로 무언가를 알게 되었을 때, 그리고 이게 바로 깨진 유리를 고쳐야 할 때를 의미하는 거겠죠. 

 

이렇게 그 외에도 도움이 되는 많은 이야기들이 담겨 있는 책입니다. IT에 종사하고 계신 분들이라면 소설책 읽듯이 가벼운 마음으로 (그렇다고 내용이 가볍다는 이야기는 아닙니다. ^^) 읽어 보시면 좋을 것 같습니다.