안녕하세요. dawonny 입니다.
오늘 리뷰할 도서는 [읽기 쉬운 코드(마크 시먼 지음)] 입니다.
1.
코드를 작성해서 프로그램이 동작하게 하는 것. 이렇게 단순히 프로그램이 ‘실행’이 되게 하는 것도 개발자로서 중요한 임무이고 가장 기본이 되는 것이지만, 더 나아가서 고려해볼 것이 있다면 무엇 일까요? 개발에 대해 잘 모르는 분야에 있는 사람있는 사람이라면 서비스 자체가 잘 실행되는 것이 더 중요할 수 있겠지 만요. 코드를 깔끔하게 짜는 것, 다양한 패턴을 적용하고 구조를 잘 설계하는 것… 등등 모두 답이 될 수 있을 것 같습니다.
하지만 저는 이 책을 읽고 이 모든 것이 결국에는 이 목표를 향해야 하겠구나-라는 생각이 들었어요. 바로 사람이 읽기 쉬운 코드를 짜야한다는 것입니다.
2.
개인 프로젝트가 아닌이상 개발자들은 팀으로써 팀원과 협업 하며 개발을 하게 될 텐데요. 아무리 AI 가 간단한 코드는 생성해주며 생산성을 높일 수 있다지만, 이 코드를 유지보수하고 새로운 기능을 추가할 때 기존의 코드를 머리로 이해해야하는 사람은 ‘사람’이기 때문이에요. 만약에 새로운 팀원이 들어와 기존의 프로젝트 코드를 이해하는 데에만 굉장히 긴 시간이 걸리는 상황이라면, 새로운 기능을 추가하기도 전에 많은 시간이 흐르게 될 거예요.
이 책에서는 책 제목 처럼 읽기 쉬운 코드를 쓰기 위해서 어떤 팀 내에서 룰을 지키는 게 좋을지, 무엇을 신경쓰면 좋을지와 같은 내용을 다루고 있어요. 저는 그 예시로 버전 관리, 주석보다 더 효과적일 수 있게 작명을 잘하기, 코드 리뷰, 사람의 두뇌가 이해할 수 있는 만큼의 구조로 코드를 작성하기 등의 내용을 인상깊게 읽었어요.
특히 이 책에서는 책의 설명과 개념이 어떻게 코드에 적용될 수 있는지 레스토랑 예약 시스템을 구현하는 예제를 통해서 보여주는데요. C# 예제라 모든 실습 코드를 완벽하긴 어려웠지만 다른 프로그래밍 언어를 아는 독자라면 맥락을 파악하며 읽기에는 좋을 것 같아요.
3.
내용 자체는 포괄적으로 다루고 있다고 느꼈어요. 왜냐하면 성능, 보안, 아키텍처, 테스트 등 결국 소프트웨어 공학이라는 것을 설명하고 있기 때문이에요. 그리고 책 초반 내용에서 저자는 개발에 있어서 체크리스트를 작성하는 것이 기억보조수단으로 유용하게 사용될 수 있다-에 관한 이야기를 하는데, 이 책을 읽으면서 그 체크리스트를 만들어나갈 수 있겠다는 생각이 들었습니다. 어려운 내용도 비유와 경험담을 섞어가며 재미있게 이야기해주는 부분이 쉽게 읽히기 좋았던 것 같아요.
4.
저는 ‘지속 가능하고 유지/보수하기 쉬운 좋은 코드를 짜는 아이디어’가 궁금한 개발자들에게 추천합니다! 따라서 실무에서 팀으로 개발을 하고 있는 분들이 읽어보면 좋은 인사이트가 될 것 같아요. 하지만 저와 같은 예비 개발자에게도 추천해보고싶어요. 저는 이 책을 읽으면서 직접 경험해본 적이 없어 와 닿지 않는 내용도 있을 수 있었지만, 나중에 경험해볼 일이라고 생각하면서 읽으니 ‘읽기 쉬운 코드’를 쓰는 개발자가 되어야겠다는 다짐을 하기엔 충분했기 때문이에요. 이 책의 후기를 다른 분들과도 한 번 나눠보고 싶네요! ☺️
아래의 내용은 인상깊었던 내용의 일부입니다
p.70
이해하기 어려운 코드는 작업 속도를 느리게 만듭니다. 반면 코드를 이해하기 쉽게 만드는 데 투자한 시간은 나중에 10배 이상으로 보상받습니다.
p.75
뇌는 컴퓨터가 가진 한계와는 완전히 다른 인지적 한계를 가지고 있습니다. 컴퓨터는 RAM 안에 있는 수많은 것들을 추적 해나갈 수 있지만, 우리의 뇌는 7개 정도만 추적할 수 있습니다.
컴퓨터는 프로그래머가 참조하도록 만든 정보만 사용해서 결정을 내리지만, 우리의 뇌는 성급하게 결론을 내리는 경향이 있습니다. 눈에 보이는 것이 전부입니다.
소프트웨어가 원하는 대로 동작하게 만들려면 당연히 코드를 작성해야 합니다. 하지만 이 부분은 더이상 소프트웨어 공학에서 다루는 주요 문제가 아닙니다. 문제는 우리 뇌에 맞게 코드를 구조화하는 것입니다. 코드를 반드시 인간 친화적 이어야 합니다.
p.254
왜 제대로 동작하지 않는지 이해하지 못한다면, 일단 그 이유를 이해하는 데 주력해야 합니다. 저는 ‘우연에 맡기는 프로그래밍’이 진행되는 것을 상당히 많이 보았습니다. 마치 엄청나게 많은 코드를 벽에 던져 어떤 코드가 벽에 붙는지 보자는 거죠. 코드가 동작하는 것처럼 보이면 개발자는 다음 작업으로 넘어가버립니다. 이러면 코드가 왜 동작하는지 이해하지 못하거나, 실제로는 제대로 동작하지 않는다는 것을 진짜로 이해하지 못할 수도 있습니다.
처음부터 코드를 이해한다면 문제를 더욱 쉽게 해결할 확률이 높습니다.
p.257
문제를 설명하는 것만으로도 새로운 통찰력을 얻을 수 있습니다.
동료가 없다면 그림12-1의 고무 오리에게 문제를 설명해보는 것도 좋습니다. 꼭 고무 오리여야 할 필요는 없지만, 한 프로그래머가 고무 오리를 사용했기 때문에 이 기법은 고무 오리 디버깅이란 이름으로 알려져 있습니다.
저는 고무 오리 대신 스택 오버플로 Q&A 사이트에 질문을 작성해보곤 합니다. 질문을 다 작성하기도 전에 문제가 무엇인지 깨닫는 경우가 많습니다.
p.259
결함의 수를 줄일 수는 있지만, 결함을 없앨 수는 없습니다. 자신에게 도움이 되는 방향으로 작업을 해야합니다. 즉, 결함이 쌓이게 둬서는 안됩니다.
가장 이상적인 결함의 수는 0개입니다.
버그가 없다는 건 생각만큼 비현실적이지 않습니다. 린 소프트웨어 개발에서는 품질의 내재화라고합니다. 결점을 ‘나중에 처리’하겠다며 미뤄두지 마십시오. 소프트웨어 개발에서 ‘나중’은 ‘절대 안 한다’ 와 같습니다.
버그가 나타나면, 이 버그를 해결하는 것을 우선순위로 삼아야합니다. 하던 일을 멈추고(깃에서는 현재 하던 작업을 스태시(stash)로 간단하게 저장할 수 있습니다. 멋지죠?) 결합을 우선적으로 수정하세요.
====================
본 리뷰는 길벗출판사에서 도서를 제공받아 솔직하게 작성했습니다.
