어떻게든 되고 싶은 그것!

훌륭한 프로그래머 되는 법 - 프로젝트와 팀을 성공으로 이끄는 선배 개발자의 노하우
피트 구들리프 지음, 최원재 외 옮김 / 한빛미디어 / 2015년 12월

“21.3 코드를 고치려면 팀을 개선하라.”

1. 이 책을 읽으면서 생각하는거지만, 훌륭한 프로그래머가 되는 법은 그렇게 어렵지 않아 보인다. 책을 읽으면서 깨닫게 되는거지만, 내가 해야 할 일을 충실히 하고, 책임감을 가지고 열심히 하는 것만으로 이미 훌륭한 개발자의 반열에 올라갈 수 있다.

2. 하지만 이런 책을 읽을 때 마다 약간의 거부감이 든다. 훌륭한 개발자 N명을 모으면 그 자체로 ‘훌륭한 개발팀’이 되는가? 왜 우린 개인에 대한 ‘훌륭함’에 대해서 이토록 많은 논의를 하면서 ‘팀’에 대해서 이토록 무관심 한가? 많은 개발서적이 ‘훌륭한 개발자’가 되는 방법에 대해서 말하지만 왜 ‘훌륭한 개발팀’에 대한 내용은 없을까?

정말로 커뮤니케이션만 잘 되면 ‘좋은 팀’이 되는가? 그리고 그 커뮤니케이션 방법이나 절차보다 개인의 ‘태도’가 그토록 중요하게 다뤄져야 하는 일인가? 아직은 혼란스럽고 막연하지만 분명한건 개인에게 가해지는 ‘훌륭함’이 하나의 팀에게 적용된다면 과연 우린 어떤 담론을 이야기 할 수 있을까?

‘직장인’의 위치를 점하게 되는 시점에서 개인에게 가해지는 조금은 무거운 ‘프레임’에 대한 약간의 아쉬움이 남는다.

3. 이 책의 읽고 저자의 주장과 논의에 대해서 커피 한 잔 하면서 조근 조근한 담소를 나눌 수 있는 기회가 되길 기원하며…

[…] 그러나 내 경험에 비추어보면 그 용어는 가끔 잘못 사용되기도 한다. 이 용어는 ‘결과의 변경 없이 기존 코드의 구조를 재조정하는 것’으로 설명한다. 여기서 종종 잊히는 대목이 ‘결과의 변경 없이’라는 부분이다. […] 프로그램 작동 방식을 바꾸는 것은 ‘개선’이지 리팩토링이 아니다. UI의 조정 또한 ‘정돈tidy-up’이지 리팩토링이 아니다. 리팩토링은 코드 가독성을 높이고, 내부 구조를 향상하며, 유지 보수를 원활히 하기 위한 것이다. 무엇보다도, 나중에 있을 기능 향상에 대비하려는 것이다.

다툼이 있는 곳에는 언제나 관계를 해치는 결과와 더 긴밀히 만드는 결과로 구분 짓는 하나의 요소가 존재한다. 그것은 바로 태도이다. - 윌리엄 제임스William James, 미국의 철학자이자 심리학자