philosophy of software design 후기
Philosophy of Software Design 후기
배경
다른 개발자 분들의 코드를 보면 감탄을 하는 순간과, 경악을 하는 순간이 있습니다. 어려운 기능임에도 높은 수준의 추상화와 책임의 분리, 깔끔하고 의도가 담긴 테스트 코드로 짜여진 코드를 보는 경우도 있고, 간단한 기능임에도 정말 지저분하게 그저 돌아만 가도록 작성한 코드를 보는 경우도 있습니다. 심지어 그런 코드가 중첩되다보니 5개의 쿼리로 풀 수 있는 기능을 몇 백개의 쿼리로 푸는 경우도 봤습니다.
이런 다양한 코드를 보다보니, 저도 항상 제 코드가 괜찮은지에 대해 걱정을 하고는 합니다. 제 괜찮다의 기준은, 비즈니스 요건의 변화로 다른 사람들이 제 코드에 기능을 추가하거나, 변경을 가하는 경우에 이해가 쉽고, 변경 포인트가 명확하게 식별가능하다는 것입니다. 다른 말로 한다면 유연해야 한다고 할 수도 있겠습니다.
그럼에도 종종 동료 개발자 분들과 코드 리뷰를 하면서 좋은 디자인과 구조에 대해서 토의를 하다보면 스스로가 부끄러워지는 상황이 있고, 제 구조에 대해서 논리적 설득력이 떨어진다는 느낌을 받기도 합니다. 따라서 저만의 소프트웨어 디자인 철학을 좀 더 보강해야 한다고 생각했습니다.
책을 선택한 이유
이 책을 선택한 이유는 모 개발 커뮤니티에서 우연히 접한 한 댓글 때문입니다.
나는 신입에게 반드시 읽게 시키는 책 중 하나로 a philosophy of software design 이 있다.
마침 좋은 디자인에 대한 호기심이 있던 저로서는 그냥 넘길 수가 없는 제목이었습니다. 해당 책을 좀 더 찾아본 결과 영미권에서는 리뷰가 꽤 있었습니다. 그리고 페이지도 150 페이지 정도라서 가볍게 읽어볼만하다고 생각이 들었습니다.
기억에 남는 부분
1. 복잡성의 관점에서 소프트웨어를 보라
소프트웨어의 복잡성을 줄이기 위해서는 2가지를 할 수 있습니다.
- 코드를 명확하게 작성함으로서 복잡성을 제거하기
- 모듈식 설계를 도입해서 복잡성을 캡슐화하기
복잡성을 시스템을 이해하고 수정하기 어렵게 만들고, 다른 개발자들의 편익에 악영향을 줍니다. 복잡성으로 인해서 발생하는 3가지 문제가 있습니다.
- 변경 증폭 : 겉보기에는 변경이 간단하더라도, 다른 여러 코드를 수정해야 함
- 인지 부하 : 알아야 할 정보의 양을 높임
- 알려지지 않은 미지수 : 작업을 수행하기 위해 어떤 정보가 필요한지 명확하지 않음
복잡성은 점진적으로 증가하기 마련입니다. 개발자는 전술 프로그래밍을 하는 사람과 전략 프로그래밍을 하는 사람으로 나눌 수 있습니다. 전자는 작동하는 코드를 목적으로 하며, 빠르게 개발하는 것처럼 보이지만 결국 시스템의 복잡도를 올리고, 일관성을 파괴합니다. 후자는 좋은 디자인을 목적으로 하면서 현재에 시간을 더 쓰더라도 이를 투자적 관점으로 여깁니다. 그리고 그 투자의 성과는 이른 시일내에 드러납니다. 좋은 개발조직은 모든 엔지니어가 좋은 설계에 지속적으로 투자하는 전략적 프로그래밍 조직입니다.
2. 주석은 필수다
저는 로직의 복잡도가 올라가면, 코드를 작성하기 전에 스탭에 따른 주석을 먼저 작성한 후에 로직을 작성합니다. 알고리즘 문제를 풀다보니 생긴 습관인데요, 이 책에서는 이러한 선주석 작성을 권장하고 있습니다. 주석을 작성함으로서, 메서드에 대한 추상화 수준이 더 올라간다고 여깁니다. 해당 메서드를 사용하는 사용자 관점에서 모든 구현을 이해하고 해당 메서드를 사용할 필요는 없을 것입니다.
그러나 주석이 존재하는 코드를 설명한다고 좋은 주석은 아닙니다. 주석은 코드에서는 존재하지 않는 것을 설명해야 합니다. 이를 테면, 해당 설계에 구조를 설명하는 주석을 남기는 것입니다. 주석을 잘 작성하면 새로운 개발자가 설계자의 의도를 이해하는 것에 도움이 됩니다.
그 밖에 내용들..
- 이름 선택은 어렵지만, 일관되게 잘 지어야 하며, 좋은 이름을 짓는 것 만으로도 좋은 추상화를 할 수 있다.
- 시스템의 복잡성을 줄이기 위해서 코드의 일관성이 중요하다. 공백, 줄 등 이런 경우에 체커를 도입하는 것도 좋다. 특히 기존 관습을 ‘변경’, ‘개선’ 하기 전에는 깊은 고민을 먼저 해야 한다.
- 단위 테스트는 리팩토링을 용이하게 한다. 개발자 스스로 단위 테스트를 잘 작성해야 한다. TDD 는 코드의 목적이 테스트 케이스인 것처럼 맞춰질 수 있으니 경계가 필요하다. (매우 동의!)
후기
영어로 되어 있음에도 어려운 단어가 사용되지 않아서, 읽기에 어려움이 없었습니다. 전부 읽는데 약 1주일 정도 걸린 것 같습니다. 150 페이지 뿐이니 부담이 없어서 동료 개발자들에게도 추천을 했습니다. 만약에 영어가 부담이라면 구글 번역기를 적극적으로 활용해봐도 좋겠습니다. 복잡성의 관점에서 코드를 바라볼 수 있는 새로운 관점을 익힐 수 있었고, 작가의 주장에 따른 근거와 예시 코드로 인해서 설득력이 있었습니다.
추천 정도 : ⭐️⭐️
기준표
상황에 따라서 읽어야 한다: ⭐
읽어두면 좋다: ⭐️⭐️
개발자 필독서 수준: ⭐️⭐️⭐️