[실용주의 프로그래머] 8장. 실용주의 프로젝트

[실용주의 프로그래머] 8장. 실용주의 프로젝트

드디어 마지막 장입니다!! 마지막 장에서는 프로젝트 전체를 관통하는 문제들에 대해 다룹니다. 프로젝트의 성패를 좌우하는 핵심적인 부분에 대해서 알아봅시다.

41. 실용주의 팀

이때까지 이 책에서 알려준 팁들은 모두 개인이 더 나은 개발자가 되게끔 도와주는 기법들이었습니다. 이러한 방법들이 팀에도 적용이 된답니다. 팀 전체에 실용주의 기법들이 어떻게 적용될 수 있는지 알아봅시다.

깨진 창문 없애기

소프트웨어의 품질은 팀의 이슈입니다. 팀 전체가 깨진 창문을 그대로 놔두는 것을 용납하지 말아야 합니다. 팀 전체가 퀄리티에 대한 책임을 져야 하죵.

삶은 개구리

개인보다는 팀이 삶은 개구리가 되기 쉽습니다. 내가 아닌 다른 누군가가 문제를 해결했겠거니 생각하거나, 쉽게 팀 리더가 이미 오케이했겠거니 여기죠. 제아무리 잘 통제되는 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에 대해 둔감할 수 있습니다. 이렇게 천천히 삶아져가는 것을 방지하기 위해서는 모든 사람이 적극적으로 환경 변화를 감시해야 합니다.

소통하기

한 팀에 속한 개발자들이 서로 대화를 많이 해야 하는 것은 당연합니다. 하지만 지키기가 어렵죠 ㅜㅜ.

반복하지 않기

중복을 없애는 데는 훌륭한 의사소통이 많은 도움이 됩니다. 또 다른 좋은 방법이 있는데요, 팀원 한 명이 프로젝트 사서 역할을 하는 것입니다. 문서와 코드 저장소를 한 명이 관리하도록 한다면, 자료들을 다루면서 중복을 찾아내어 제거할 수 있을 겁니다. 만약 프로젝트 하나가 너무 크다면 기능별로 나누어서 임명하는 것도 좋은 방법입니다.

직교성

전통적인 팀 조직은 폭포수 모델을 근간으로 합니다. 비즈니스 분석가, 아키텍트, 디자이너, 프로그래머 등등 각자 자식의 직무에 따라 역할을 부여 받져. 여기에는 암묵적인 위계가 존재하는데요, 이렇게 나누는 것보다 팀을 기능적으로 분리하는 것이 좋습니다. 기능 중심으로 팀을 조직하면 각각 변화가 생기더라도 전체가 영향받는 일이 사라지게 됩니다.

자동화

일관성과 정확성을 보장하는 가장 좋은 방법은, 팀이 하는 모든일을 자동화하는 것입니다. 단순히 코드 정렬부터 빌드같은 것까지 말이죵. 자동화는 굉장히 중요합니다. 엄청난 효율을 갖고 올 수 있기 때문입니다. 고로 다음 장에서 자세히 알아봅시다~

42. 유비쿼터스 자동화

빌드, 릴리즈나 코드 리뷰 서류 작업과 같은 프로젝트에서 반복되어 발생하는 어떤 종류의 작업이든 자동화되어야 합니다. 수작업은 일관성을 운에 맡기는 행위입니다. 따라서 반복가능성을 보장받지 못하죠. 그렇기 때문에 수작업 절차를 최소화하는 것이 좋습니다.

유명한 자동화 도구에는 cron이 있습니다. 신입 기술교육때 써봤던 것 같은데.. 기억이 잘... 그리고 makefile로 많은 일을 쳐낼 수 있습니다. 프로젝트 컴파일부터 코드 생성, 회귀 테스트, 빌드 자동화 등등까지요.

저희 팀에서는 배치 잡이 정말 많습니다. 일대사부터 마일리지 대사 등등.. 그래서 스프링 배치도 공부해야 하는데..... 정말 공부할거 천지네요. 와~~

43. 가차 없는 테스트

44. 결국은 모두 글쓰기

45. 위대한 유산

46. 오만과 편견

from http://yoon1fe.tistory.com/254 by ccl(A) rewrite - 2021-12-22 22:27:11