[실용주의 프로그래머] 9장. 실용주의 프로젝트
3 주차
화 | Assignment #15
9장. 실용주의 프로젝트
📘 책에서 기억하고 싶은 내용
- 개요
- 실용주의 기법들을 개인이 아닌 팀에 확장하여 적용시키면 이점이 몇 배로 많아진다.
- 실용주의 팀 (p.378)
- 실용주의 팀은 작다.
- 구성원이 대략 10~12명 이하
- 구성원이 추가되거나 빠지는 일은 거의 없음
- 모두가 서로 잘 알고, 신뢰하며, 의존해야 함
- 팀 전체가 깨진 창문을 용납하지 않아야 한다.
- 품질은 팀원 모두가 제각기 기여할 때만 보장된다. (품질은 애초에 제품에 포함된 것)
- 모든 사람이 적극적으로 환경 변화를 감시하도록 권장해야 한다.
- 우리 팀이 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다.
→ "시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다"는 것
- 팀의 지식 포트폴리오 계획
- 구형 시스템 유지 보수 : 미루지 말고 처리하라
- 프로세스 회고와 개선 : 무엇이 잘되고 잘되지 않았는지 지속적인 확인을 통한 계획 수립 및 변경 필요
- 새로운 기술 탐험 : 유행한다는 이유로 도입하지 말고 프로토타이핑을 통하여 신중한 조사 필요
- 학습 및 기술 갈고 닦기 : 많은 기술을 팀원들에게 전도할 계획을 세워라(스몰토크, 스터디 등)
DRY 원칙
을 지키기 위해서는 팀원 서로에게 관심을 유지하라. (동료의 업무 등)
- 예광탄을 내가 맡은 업무가 아닌 전체 업무 영역에서 활용해보자. (UX, F/E, B/E, Server, DB, QA 등)
- 팀은 개인들로 이루어진다. 각 팀원
- 코코넛만으로는 부족하다 (p.387)
- 유행하는 것(정책, 프로세스 등)이 아니라 성공 사례와 동일한 제약 조건을 가지고 있는지 확인하여 실제로 잘 맞는 것을 새용해야 한다.
- "잘 맞는 것" 을 어떻게 알까?
→ 실용주의 기법을 적용하여 실험하며 좋은 부분만 유지
- 소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이므로, 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다.
- 특정 방법론에 과도하게 투자하면 다른 대안을 보지 못하게 될 수도 있다.
- 실용주의 시작 도구 (p.392)
- "테스팅은 버그의 존재만 보여줄 수 있지 버그의 부재까지는 보여줄 수 없다." - 데이크스트
버전 관리
, 가차 없는 테스트
, 전체 자동화
는 프로젝트에 필수적인 견고한 기반이다.
- 빌드/릴리즈/테스트/문서 등 프로젝트에서 거듭 발생하는 작업은 모두 자동화가 필요하다.
- 많은 개발자들이 무의식적으로 코드가 어디에서 깨지는지 파악하고서는 약한 지점을 피해 다니면서 살살 테스트하려 한다.
- 일찍 테스트하고, 자주 테스트하라. 테스트를 자동화하라.
- 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.
- 빌드 과정에는 테스트 주요 유형이 포함되어야 한다. (단위 테스트, 통합 테스트, 성능 테스트 등)
- 어떤 버그를 감지해 내는 테스트를 작성한 후에, 그 버그가 의도적으로 생기도록 한 다음 테스트가 경보를 울리는지 확인하라.
코드 커버리지
보다 중요한 것은 프로그램이 갖는 상태
이다.
- 사용자를 기쁘게 하라 (p.402)
- 모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다.
- 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각해보아야 한다.
- 이런 기대를 염두에 두고 사용자의 요구 사항을 비판적으로 분석하라.
- 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.
- 실용주의 프로그래머의 본질은 "문제 해결사"고, 문제를 해결한다.
- 오만과 편견 (p.404)
- 자신의 작품에 서명하는 것을 자랑스러워할 수 있어야 한다.
- 자신의 코드만 좋게 보고 동료들의 코드는 깎아내리는 편견을 갖지 마라.
- 경계심 때문에 나의 코드를 참견하는 사람으로부터 방어하려고 해서는 안 된다.
🤔 소감 및 생각
- 드디어 마지막 챕터를 다 읽었다. 책을 다 읽고 나니 앞으로 내가 어떻게 해야 할지 한참을 고민하게 되었다. 책에서 말하는 실용주의 기법은 완전히 새로운 것이 아닌, 대부분 모두가 알고 있지만 지키기 어려운 원칙이었던 것 같다.
- 읽으면서 '아 이런 부분은 실무에서 이러한 사유때문에 적용하기 어려울텐데' 이런 생각을 자주 하였는데, 이런 방어적인 생각때문에 나와 팀이 더 발전할 기회를 놓쳤을 수도 있다는 생각이 들었다. 사소한 부분이라도 반복되는 업무는 자동화를 하며 업무 시간을 코드 작성에 많이 할애할 수 있도록 노력해야겠다.
🔍 새롭게 또는 다시 알게 된 내용