이펙티브 엔지니어 리뷰 :: 마이구미

이 책은 "이펙티브 엔지니어" 라는 책을 리뷰한다.
본인은 평범한 개발자이다. 개인적인 생각과 해석이 들어가 있을 수 있다.
책 링크 - http://www.yes24.com/Product/Goods/110243880

 

어떻게 하면 더 효율적인 개발자가 될 수 있을까? 라는 질문에 어떻게 생각하는가?

사실 본인은 이런 질문을 좋아하지는 않는다.

질문의 답은 개발 분야 뿐만 아니라, 모든 분야에서 비슷한 답이 나오지 않을까... 생각한다.

 

 

그럼에도 이 책을 읽게 된 이유는 무엇인가?

회고 느낌으로 스스로를 리뷰를 하려는 목적으로 읽게 되었다.

우선 이 책에 대한 리뷰를 간단하게 표현하면 다음과 같다.

 

대부분의 내용은 이미 우리가 알고 있는 내용이다.
이 책을 통해 스스로 대화하면서 공감하고 반성하는 시간이 될 것이다.
그리고 많은 상황에서 좋은 지침서가 되어줄 것이다.
또한, 우리가 항상 고민하는 것들을 좀 더 명확하고 논리적으로 다른 사람에게 설명하고 설득할 수 있게 도와줄 것이다.

 

---

 

개인적으로 기억에 남는 내용들

불가능해 보이는 문제를 굳이 풀려고 노력하기 보다 가정 자체에 의문을 제기해서 간단히 우회할 방법을 찾아낼 때가 많았다.

=>

개발자는 일단 해결하려는 습성이 있는데 때로는 차분해질 필요가 있다고 본다.
이 문제를 어떻게 해결할까? 이전에 왜 이걸 우리가 해결해야 하지? 를 생각하는 게 더 생산적일 수 있다.

 

회사가 근무 시간에 도전적이지 않은 편한 업무를 9시부터 5시까지 시키고 지급한 급여는 훨씬 낮은 지적 성장률을 수용한 대가로 주는 돈입니다.
지식이 복리 계산된다고 보면 장기적으로 놓치는 복리 비용은 어마어마합니다.

=>

업무 시간은 하루의 비중을 많이 차지한다.
이 시간을 효율적으로 써야하는건 너무 당연하다.
그저 복리로 비유하는 표현이 신선했다.

 

목표를 측정하기 어렵다는 것이 측정할 가치가 없다는 뜻은 아니다. 

=>

기술 부채의 측면에서 비교적 간단한 작업이라할지라도 충분한 가치가 있다.
다만, 정량화하기 힘들뿐이다.
지금까지 기술 부채를 리스트업하고 해결해나가는 것 이외에는 크게 신경쓰지 않았다.
하지만 정량화를 시도 해보는 것도 좋은 방법일 것 같다.

• 현재 내가 하는 일의 진행 상황을 측정할 방법이 있을까?
• 만약 내가 하는 일이 핵심 지표에 영향을 미치지 못한다면 할 가치가 있을까? 또는 내가 놓치고 있는 핵심 지표가 있을까?

 

프로젝트를 효과적으로 실행한다는 것은 기한을 늦출 만한 위험을 최소화하고 예상치 못한 문제를 최대한 초반에 알아낸다는 뜻이다.

=>

본인은 위험한 부분이나 까다로운 부분은 어떻게든 해결할 수는 있겠다는 자신감으로 조금 미루는 경향이 있다.
하지만 초기에 세웠던 공수나 일정을 초과하는 경우가 자주 발생했다.
이러한 부분에 대한 비용을 구체화하지 않았기 때문이다.

 

무언가를 처음부터 재작성하려고 하는 거죠. 그건 저질러서는 안 되는 가장 큰 죄예요.
...
두번째 시스템은 인간이 설계한 가장 위험한 시스템이다.

=>

우리는 첫번째 시스템을 두번째 시스템으로 다시 만드는 작업을 과소평가하는 경향이 있다.
기술 부채를 줄일 수 있게 코드를 리팩토링하거나 성능이 더 뛰어난 알고리즘 또는 구조를 재설계하게 된다.
이건 오히려 복잡성을 증가시키는 상황으로 갈 확률이 높다.

 

어떤 프로젝트를 책임지는 유일한 개발자가 되면 자신의 가치가 올라간다는 잘못된 통념이 존재한다.

=>

코드 소유권을 공유하여 일부를 덜어줄 팀원이 있으면 다른 활동에 집중할 자유가 생긴다.
이것이 훨씬 더 이득일 것이라고 본다.
하지만 이건 업무 상황과 개발자 성향 등과 관계가 있다고 생각한다.
예를 들어, 각자 맡은 도메인이 있거나, 본인 업무가 아닌 것들은 원하지 않을 수도 있다.
그렇기에, 그저 높은 가독성의 코드, 문서, 주석, 기술 공유 등이 스스로 할 수 있는 최선이지 않을까?
모두가 좋은 방법이 있는지는 아직 잘 모르겠다.