[독서 리뷰] 개발자 원칙

개발자 원칙

 

한 줄 평

[★★★☆☆] 현업에 종사하는 개발자를 위한 자기계발서

읽게 된 계기

개발과 관련된 책을 읽으려는 시도는 계속 있어왔다. 어떤 책을 읽을까 하다가 학원가는 지하철에서 읽기 좋은 책을 읽기로 했다. 그러려면 두께가 두껍지 않은 책이어야 했다. (가방에 맥북을 담고 다녀서 무겁고, 현재 가방의 수납 공간이 작다!) 그러다 발견한 책이 개발자 원칙이었다.

느낀 점

우선 가장 크게 느낀점은 아직 현업에 종사하지 않는 나에게는 읽기 적절하지 않은 책이라는 점이다. 아무래도 현업에 종사하는 개발자들이 더 나은 개발자가 되기 위한 여러 자기계발 방법들을 소개하는 책이다 보니까, 워너비 개발자인 내가 읽기에는 조금 어려운 부분들이 있었다. 그래도 전혀 도움이 되지 않은 것은 아니다.

 

첫 챕터의 저자 같은 경우에는 나와 같은 토목공학과 출신이어서 조금은 더 친숙한 마음으로 볼 수 있었다. 저자가 어떻게 개발자라는 직업을 대하는 지에 대해서 알 수 있었다.

 

두번째 챕터는 저자가 오류를 마주하는 자세에 대해서 쓴 내용이다. 그 중 첫번째 원칙인 ‘오류가 발생하면 소스 코드 레벨에서 이해하자’는 단순히 오류가 발생하면 문제만 해결하려고 하고 이해는 나중으로 미뤄둔 나에게 큰 인사이트를 준 원칙이었다.

 

세번째 챕터는 ‘소프트웨어 디자인 원칙’이라는 제목을 가진 챕터인데, 아직 내가 내용을 받아들이기에는 어려운 내용들이었다. 우선 소프트웨어 설계의 방식에는 다양한 것들이 있구나 하고만 이해하고 넘어갔다.

 

네번째 챕터에서 가장 기억에 남았던 내용은 ‘개구리를 해부하지 말고 직접 만들어라’이다. 코드를 하나하나 분석하면서 이해하는 것보다 소프트웨어를 직접 만들어보는 것이(그게 낮은 레벨의 소프트웨어일지라도) 더 제대로 이해하는데 도움을 준다는 것이다. 또 다양한 방식으로 학습하는 것에 대한 중요성을 이야기하기도 했는데, 그건 언제나 준비되어 있기에 공감하면서 읽었다.

 

다섯번째 챕터는 저자가 이직에 관해 쓴 내용이다. 조직 규모별 개발 문화 및 특성에 대한 차이를 간접적으로나마 알 수 있었고, 관리자로서의 역할에 대한 내용도 담겨있었다.

 

여섯번째 챕터는 내가 가장 자기계발서 같은 내용이라고 느낀 챕터이다. 시중에 널리 알려진 자기계발 이론을 어떻게 개발자에게 적용시키는지 예시를 들어서 설명한 챕터이다.

 

일곱번째 챕터는 프로덕트에 관한 책이다. 개발자를 넘어서 훗날 비즈니스에 대한 욕심이 있는 나에게 흥미로웠던 챕터이지만, 역시나 현업에 종사하지 않으면 아직은 어려운 부분들도 많이 있었다. 중요한 것은 코드보다 프로덕트가 우선시 되어야 한다는 점이다.

 

여덟번째 챕터는 제어할 수 없는 것을 의존하지 말라고 얘기하는 챕터이다. 이 내용은 내가 삶에서도 중요한 원칙으로 삼고 있는 내용이다. 그 점을 개발자가 개발하는데 어떻게 적용시킬 수 있는지 설명한 챕터이다. 많이 들어본 유니콘 기업이라는 용어 외에 낙타 기업이라는 용어를 이 챕터에서 처음 알게 되었다. 이 챕터에서 인용된 ‘88연승의 비밀’ 이라는 책도 읽어보고 싶다.

 

아홉번째 챕터는 더 좋은 코드를 작성하기 위한 내용을 담고 있다. 기술 부채에 대해서 알 수 있었고, 코드를 작성할 때 우선순위에 대한 내용도 알 수 있었다. 우선 코드가 기능적으로 잘 동작해야 한다는 것, 그리고 동작만 잘 해서는 나중에 기술 부채로 크게 다가올 수도 있다는 점을 알게 되었다.

 

 

전체적으로 이미 시니어 및 관리자가 된 개발자분들이 쓰신 책이다 보니까, 조직관리에 대한 내용도 많이 녹아져 있는 것 같다. 나중에 신입 개발자가 된다고 하더라도 이런 부분은 반드시 알아야 한다고 생각하지만, 역시 아직은 개발 역량을 향상시키는 것에 집중해야 하는 시기이기도 하다. 나중에 개발 역량이 어느 정도 올라오면 다시 읽어보고 싶은 책이기도 하다. 책의 난이도는 현업에 대한 내용만 제외하고는 크게 읽기 어렵지는 않았다.