프런트 엔드, 백엔드, 프레임워크, 다양한 언어들, IDE 등등이 프로그래밍에서, 좁은 범위로는 프로젝트에서 서로 조화를 이루어 진행되어야 하지만, 그 방대함으로 결코 쉽지 않기에 프로그래밍이 종합예술이라고 생각하며 버거움을 토로하던 차에 <읽기 쉬운 코드>라는 책을 읽게 되었다.
신기하게도 다소 도발적인(?) 『예술인가? 과학인가?』라는 제목으로 첫 번째 장을 시작하며 소프트웨어, 엔지니어, 공학, 프로그래머 등을 대상으로 근본적인 차이점에 대한 인식과 이해라는 기점에서 시작할 것을 저자는 주문하며 글을 시작한다. 최소 몇 년간의 전문적인 개발을 경험하고 코드 개선의 의지가 다분한 백엔드 개발자들이 대상 독자인지 모든 내용을 책 한번 읽고서는 이해하기가 쉽지 않다. 그리고 C#로 작성된 예제 코드들은 그나마 조금은 익숙한 Java 코드와 비슷해서 따라갈 수 있지만 이것 마저도 만만하지는 않다.
그래도
- 인간의 단기 기억의 한계와 불명확한 형태로 작성되는 복잡한 코드들의 대비관계
- 단순한 소프트웨어 공학 아키텍처 기반의 읽기 쉽고 이해하기 쉬운 코드 작성
- 실력을 향상시키지도 않고도 결과를 개선할 수 있다는 관점에서의 체크리스트
- 짝 프로그래밍, 몹 프로그래밍, 코드의 공동 소유
- 짧은 주기의 깃 커밋
- 깃 커밋 메시지 작성 규칙
- 테스트의 중요성, 자동 빌드 테스트
- 생산성 저하로 이어지는 장시간 작업 피하기와 휴식
등등,
알고는 있지만 하지 못하는 것들과
관점이 다른 저자의 해석 등,
얻을 수 있는 저자의 통찰력이 많이 있다.
포기하지만 말고 저자의 조언을 곱씹어보자.
그리고 부록 “프랙티스 목록”에서 저자가 기술한 방법들을 쉽게 찾아 화두로 삼을 수 있고,
“참고 문헌” 부록에 기재된 자료들을 찾아서 참조하며 기록을 하자.
읽으면서 가장 마음에 와닿아,
다시 거울 속의 나에게 자문하게 되는 구절은 아래와 같다.
왜 제대로 동작하지 않는지 이해하지 못한다면, 일단 그 이유를 이해하는 데 주력해야 합니다. 저는 ‘우연에 맡기는 프로그래밍이 진행되는 것을 상당히 많이 보았습니다. 마치 엄청나게 많은 코드를 벽에 던져 어떤 코드가 벽에 붙는지 보자는 거죠. 코드가 동작하는 것처럼 보이면 개발자는 다음 작업으로 넘어가 버립니다. 이러면 코드가 왜 동작하는지 이해하지 못하거나, 실제로는 제대로 동작하지 않는다는 것을 진짜로 이해하지 못할 수도 있습니다. 처음부터 코드를 이해한다면 문제를 더욱 쉽게 해결할 확률이 높습니다.
시스템을 설계하는 조직은 필연적으로 해당 조직의 커뮤니케이션 구조를 복제한 설계 구조를 만들어낼 수밖에 없다
읽어주셔서 감사합니다.
"출판사에서 책을 제공받아 작성한 리뷰입니다."
