[서평] 심플 소프트웨어

길벗 리뷰어로 선정되어 심플 소프트웨어 책을 받아보았다. 책 소개대로, 코드는 단 한줄도 등장하지 않는다. 저자의 경험에서 나오는 많은 생각들과 경험이 녹아있는 책이다. 나의 과거와 현재, 그리고 나의 미래를 상상하며 노트북 없이 밑줄을 그어가며 읽은 책이다. 좋았던 부분이 너무 많아 어떻게 서평을 써내려갈지 정말 많이 고민했다. 결국 각 Part별로 좋았던 부분을 적고 내 감상평을 추가하기로 했다.

Chapter 2 올바른 자세

‘올바른 방법’은 보통 ‘발생할 수 있는 모든 상황에 대응하는 방법’을 의미한다. 올바른 방법을 모른다 조금 더 공부하면 해결할 수 있을지도 모른다, 하지만 한계를 단정짓고 적당히 ‘이정도면 괜찮지’의 기준으로 코드를 작성해선 안된다. 나의 타협은 동료에게는 이해할 수 없는 context이고 이는 협업을 타협하는 방향이다.

너무 힘들다 그럴 수도 있다. 나도 실제로 그런 마음이 들때도 있었다. 하지만 중요한 점은, 그래서 타협해도 되는 코드를 남겨도 된다는 것이 아니라, 일정이 부족하면 확보해야하며 올바르게 진행해야 한다. 나는 슈퍼개발자가 아니므로 올바른 방향에 힘이 드는것은 당연하다. 그래도 타협은 안된다.

Chapter 4. 두 문장으로 요약한 소프트웨어 설계

• 구현에 드는 수고보다 유지보수에 드는 수고를 줄이는 게 중요하다.
• 유지보수에 드는 수고는 시스템의 복잡성에 비례한다.

Chapter 8. 복잡성은 감옥이다.

실제로 그렇다. 나는 1인개발자가 아니기때문에 당연히 휴가에서는 자유롭고 싶다. 내 옆에 나와 함께하는 팀원이 있고 나도 다른 사람에게는 팀원이다. 내 코드는 내 소유가 아니다. 그러므로 누구든 쉽게 파악하고 수정할 수 있도록 작성되어야 한다. 이 단순한 원칙을 종종 잊는다.

Chapter 12. 둘은 너무 많다

설계 작업을 진행할 때 따르는 규칙이 있는데, 이를 둘은 너무 많다. 라고 부른다.

어느 수준까지 포괄해야하는지 부터 알아야 한다. 
특정 목적에 부합하는 포괄적 솔루션을 설계한다.

여러종류 포맷을 커버하기 위해 비슷한 로직을 처리해야하는 경우, 그 즉시 아무것도 복사하지 않고 상위 클래스나 유틸리티 라이브러리를 만들어야 한다는 것이다.

이 규칙이 매우 와닿았는데, 결국 웹프론트에서 일어나는 일련의 작업들은 데이터를 view에 맞게 가공해서 보여주는 작업이 많기 때문에 조금씩 겹치는 로직들이 많기 때문이다. 이럴 경우 공통적으로 처리할 수 있는 util함수를 만드는데에 있어, 이 함수는 어디서든, 범용적으로 설계될 수 있도록 가능한 많이 생각해야 한다고 생각한다.

리팩토링

하나로 통합해야 하는 구현체가 많을 때는 한번에 통합하는 구현체를 두개로 제한하는 것부터 시작한다. 

리팩토링의 시작은 거창하지 않아야 한다는데에 동의한다. 리팩토링을 할때, ‘어디서부터 해야하는지, 현상파악 후 고치는데’까지 너무 막막했던 경험이 있다. 작은 단위의 함수부터 ‘작더라도 주기적’으로 진행해보자라는 마음을 갖는것이 지속가능한 리팩토링이라는 관점에 매우 동의한다.

Chapter 15. 버그의 원인

무슨 용도인지 적혀있지 않은 버튼이 수백만 개 붙어있는 상자는 바르게 사용할 방법이 없다.

버그의 원인이 ‘복잡성’에서 온다고 말하고 있다. 사실 이 맥락에는 어느정도 동의하는 부분인데(버그에는 단순 휴먼에러부터, 예측할 수 없는 다른원인까지.. 원인은 많다고 생각한다.) 최소한 복잡성이 낮을수록 디버깅이 쉬울것은 자명하다고 생각한다.

나에게 단순한 것은 어쩌면 내가 짜서일 가능성도 높고, 동료가 읽는 상황을 염두해둬야 좋은 코드가 된다고 생각한다.

개인적인 경험으로는 최근 ‘깔끔해보이는 코드 vs 읽기 쉽지만 조금 중복이 있는코드’에서 고민한적이 있는데, 물론 우선은 내가 코딩실력이 부족해서이겠지만.. 의식적으로 ‘읽기쉽지만 조금 중복이 있는 코드’를 선택해야한다고 생각했다. 나는 생각보다 ‘깔끔해보이는 코드’에 잘 매료된다.

이 Chapter의 마지막은 쉬워보이지만 잘 간과하는 두 문장이었다.

1. 코드가 단순할수록 버그가 줄어들 것이다.
2. 프로그램의 모든 것이 단순해지도록 늘 노력하라.

Chapter 18~19. 생산성

생산성에 관한 이야기였다. 사실, ‘개발자의 생산성 측정’은 누구나 궁금해할법한 화제라고 생각해서 더 눈길이 갔다.

책을 읽으면서 팀내에 새로운 기술이나 구조를 도입하는 과정이 그려졌는데, 팀원들을 설득해나가는 과정이 사실적이면서 구체적이어서 좋았다.

나의 편이 되어줄 아군 팀원을 모아야 하고, 
그 기반에는 신뢰가 있어야 하며 변화에 '완벽'을 기하지 말것. 

모두 좋은 동료만 있는 조직일지라도, 계속 흘러가는 조직에서 변화는 점진적이어야 받아들이는데 지치지 않으며 그 방향이 지속가능하다고 생각한다.

‘아군’ 이라는 어감이 다소 세게보일 수 있지만, 내 뜻에 동의하는 동료와 의견을 공고히 해나가는 과정이라고 받아들여졌다.

그리고, 또 이 Chapter에서 흥미로웠던 문장은 리팩토링 작업을 통해 개발자 생산성이 어떻게 개선되었는지 보여주는 그래프를 만들겠다고 함부로 약속하지말라. 였다. 어려운 부분에 대한 ‘공표’보다는 ‘지속적 제안’으로 팀 문화가 리팩토링에 젖어들도록 해야한다.

책에서는 ‘이 기능을 좀더 쉽게 작성하려면 리팩토링을 해야해요.’ 라는 제안ㅇ르 시작으로 가능할때마다 리팩토링을 제안하는것을 권고하고 있다.

이후 ‘생산성을 어떻게 측정할까?’대목은 사실 와닿지 않았다. 조직에 대한 개선이나 방향은 좋았지만 생산성 측정의 HowTo를 얻을 수는 없었다. 어려운 분야이기도 하고, 조직마다, 그리고 각 조직의 서비스마다 다를테니 이는 어쩔 수 없는 부분인것 같기도 하다.

Chapter 20. 소프트웨어 회사에서 코드 복잡성을 다루는 방법

코드에서 감정적으로(이 대목을 많이 강조했다.) 짜증나거나 두려운 부분을 찾고, 그 문제들을 나열한 다음 우선순위에 맞게 헤쳐나가는 것을 말하고 있다.

얼마 전 구조변경에 대한 발표를 한적이 있어, 더욱 재밌었던것 같다.

Chapter 35. ‘아니요’의 힘

협업에서 가장 중요한 점은 협업이라고 생각했고, 그 관점에서 ‘soft하게 말하기’에 정말 많은 노력을 기울였던 적이 있다. 지금 생각해보면 과한 수사어구는 맥락을 흐리게 되고, 상대방이 생각했을 때의 ‘애매한 부정’은 가치판단에 어려움을 줄 수 있다. ‘협업’이 중요하기 때문에, 나는 부정적 의견일지라도 확실하게 전달할 필요가 있다는데에 매우 공감한다.

하지만, 이 책에도 나오듯 위의 말이 곧 ‘무례하세요’라는 말은 절대 아니다. 당연히 나의 동료들은 틀린제안만 하지 않으며 거절해야하는 제안일지라도 좋은부분과 그렇지 않은 부분을 구별해서 피드백을 주어야 한다. 설령 전부 나쁠지라도, 그 문제에 대해 고민을 했을 동료의 시간을 생각하며 그에 대한 감사를 표하는것은 협업에서 당연히 지켜야 할 예의이다.

Chapter 36. 프로그래머가 개떡 같은 이유

꽤 자극적인 제목이지만 ‘공부를 꾸준히 합시다’에 관한 글이라고 보면 될것 같다. 그 세부적인 내용은 아직 내가 느끼지 못한 다소 교과서적인 이야기처럼 들렸으나, 여기서 기억해두고 싶은 부분은 이 대목이다.

누구나에게 항상 더 배울게 있다는 생각,
지식과 실습이 기술을 익히는 열쇠라는 생각, 
무언가 모른다는걸 알고 그것을 익히기 위해 지식과 실습을 기울여야 한다는 생각

총평

곰곰히 생각해보며 가볍게 읽기 좋은 책이다. 다만 모든 근본적인 것에 관한 책이 그렇듯, 의식적인 학습이 필요하다. 그냥 지나치기에는 아쉬운 내용들(생산성, 복잡성, ‘아니요’의 힘 등..)이 많다. 전반적으로 좋은 내용이었지만, 중간에 등장했던 보안 등의 이야기는 ‘왜 여기에 나왔지..’ 싶은 부분이었다.