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

1

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

2

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

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

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

3

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

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

2. 코드를 완벽하게 제거하라. 언제든 소스 관리 시스템을 통해서 복원할 수 있다.

3. […] 더 많은 줄의 코드가 더 좋은 소프트웨어를 의미하지는 않는다. 따라서 필요하지 않다면 코딩하지 말자. 적게 쓰고 그 대신 더 재미난 것을 찾으라.

4. […] 미래에 필요핳 것 같은 기능을 지금 작성하기로 했다(힌트: 그것은 YAGNI가 아니다. 당장 필요하지 않다면 지금 작성하지 말라.)

5. 코드를 파악하는 가장 좋은 방법은 이미 코드를 파악하고 있는 사람의 도움을 얻는 것이다. 도움을 요청하길 주저하지 말라!

6. (앓는 소리를 해서는 안 된다는 걸 필자도 알고 있다. 하지만 때로는 스레드처럼 위험한 무기를 다루기 위한 자격증이 존재했으면 싶고,그게 없다면 thread라는 글자 자체를 쓰지 못하도록 해야 한다며 저주를 퍼붓는다.)

7. 디버깅이 소프트웨어 버그를 없애는 과정이라면, 프로그래밍은 분명 버그를 만드는 과정이다. - 에르허르 데이크스트라Edsger Dijkstra, 컴퓨터 과학자

8. 버그를 피할 수 있는 가장 좋은 충고는 믿기 힘들 정도로 ‘영리한(종종 복잡한 것과 동일시되는)’ 코드를 만들지 말라는 것이다.

9. 결국 가장 이상적인 방법은 최대한 많은 개발자 테스트를 자동화하는 것이다. 더 열심히 일하려 하기보다 더 영리하게 일하라.

10. 견본(Dummies) : […] 보통 빈 껍데기다. […] 인자 목록을 채우기 위해 필요하다., 짝(Stubs) : 인터페이스의 단순화된 구현체로서, 미리 정의된 응답을 반환하고 자신에 대한 호출과 관련된 정보를 저장하곤 한다., 모조(Mocks) : 테스트 대역 중 최고로 여러 객체 지원 라이브러리의 기능을 한다.

11. 간결함은 가장 위대한 덕목이지만, 이를 달성하려면 고된 작업이 필요하며 또한 이해하려면 별도의 교육이 필요하다. 상황을 더 어렵게 만드는 것은 ‘복잡하면 더 잘 팔린다’는 사시이다. - 에르허르 데이크스트라Edsger Dijkstra, 컴퓨터 과학자

12. 발생할 수 있는 가장 나쁜 상황 중 하나는 아직 모르는 것을 설계하는 경우다. […] / 처음 만드는 시점부터 소프트웨어 설계에 필요할 것으로 예상되는 모든 요소를 추가하는 것은 위험한 일이다.

13. […] 좋은 코드를 작성하기 위한 세개의 강력한 규칙이란 다음과 같다. “간결하게 하라”, “머리를 쓰라”, “변하지 않는 것은 없다”

14. 종종 다음에 ‘사용하리라’는 예측은 절대로 실현되지 않고, 다음 사용자는 전혀 예상하지 못한 다른 요구사항을 요구한다.

15. […] 한 번의 간단한 체크아웃만으로도 빌드 가능한 형태로 전체 파일들을 받을 수 있어야 한다.

16. 개발자는 적절한 태도를 갖추고 코드를 빌드해야 한다. QA에게 무언가를 전달할 때 초라한 코드를 낡아빠진 머신에서 빌드하여 담장 너머로 던져주는 식이 되어서는 안 된다.

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