실용주의 프로그래머 - 9장 실용주의 프로젝트

• 프로젝트의 성패를 좌우하는 핵심

Topic 49 실용주의 팀

L 그룹에서 스토펠은 여섯 명의 일류 프로그래머를 감독한다. 이는 말하자면 고양이 떼를 모는 일에 비할 만한 도전적인 관리 업무다.

• 프로그래머는 고양이 같은 면이 있다.
  호기심이 많고 제멋대로이며, 고집이 세고, 독립적인 데다, 가끔은 인터넷에서 숭배를 받기도 한다.
• 이제까지 우리는 개인이 더 나은 프로그래머가 되게끔 도와주는 실용주의 기법들을 살펴보았다.
  이런 방법이 팀에도 적용될까? 제멋대로이고 독립적인 사람들이 모인 팀에서도?
  답은 명쾌한 "그렇다!"이다.
• 실용주의 팀은 작다.
  • 구성원이 대략 10~12명 이하여야 하고,
  • 구성원이 추가되거나 빠지는 일은 드물어야 한다.
  • 모두가 서로 잘 알고, 신뢰하며, 의존해야 한다.

 

Tip 84 작고 안정적인 팀을 유지하라.

 

깨진 창문을 없애라

• 팀 전체가 깨진 창문을 용납하지 않아야 한다.
• 품질은 팀원 모두가 제각기 기여할 때만 보장된다.

삶은 개구리

• 팀은 개인보다 더 삶은 개구리가 되기 쉽다.
• 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라.
• 새 요구사항에 대한 수치를 관리하라.
  • 번다운 차트보다는 번업 차트가 더 낫다.

여러분의 지식 포트폴리오를 계획하라

• 구형 시스템 유지 보수
  • 신규 시스템에서 일하는 것을 좋아하겠지만, 구형 시스템에도 해야 할 유지 보수 업무가 있다. 수행하라.
• 프로세스 회고와 개선
  • 지속적인 개선이 일어나려면 무엇이 잘되고 무엇이 잘되지 않았는지 확인한 다음에 계획을 세우고, 고쳐라.
• 새로운 기술 탐험
  • 기술을 "다들 쓰니까"라는 이유로, 또는 콘퍼런스에서 본 것이나 인터넷에서 읽은 글을 바탕으로 도입하지 말라.
  • 후보 기술로 프로토타이을 만들어 보고 신중하게 조사하라. 시도해 보고 결과를 분석하라.
• 학습 및 기술 갈고 닦기
  • 기술을 팀 전체로 퍼트려라

 

Tip 85 실현하려면 계획하라.

 

팀의 존재를 소통하라

• 팀이라는 것 역시 더 큰 조직의 일부라는 사실을 잊어버리기 쉽다.
• 팀도 나머지 세상과 명확하게 의사소통해야 하는 존재다.
• 외부 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트팀이야말로 최악이다.

반복하지 말라

• 좋은 의사소통이 이런 문제를 피하는 핵심이다.
• "좋은"이란 즉각적이고 매끄러운 것을 말한다.
• 만약 질문을 하거나 상황을 공유하기 위해 일주일 남은 팀 회의시간까지 기다려야 한다면 엄청 껄끄러운 커뮤니케이션이다.
  • e.g. 일일 스크럼 스탠드업을 금요일에만 하는 팀

팀 예광탄

• 예광탄을 사용하여 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다.
• 작업에 필요한 기술을 팀 안에 모두 갖추어야 한다.

Tip 86 모든 기능을 갖춘 팀을 조직하라.

• 코드를 끝에서 끝까지 점진적이고 반복적으로 쌓아 올릴 수 있는 팀을 만들어라.

자동화

• 일관성과 정확성을 모두 보장하는 확실한 방법은 팀이 하는 모든 일을 자동화하는 것이다.
• 코드 스타일
• CI/ CD

멈춰야 할 때를 알라

• 팀은 개인들로 이루어진다는 사실을 명심하라.
• 각 팀원이 자신의 방식대로 빛나게 하라.
• 프로젝트가 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라.

Topic 50 코코넛만으로는 부족하다

• (책 예시) 코코넛 껍질로 만든 모조 공항은 진짜를 대체할 수 없다.
• (책 예시) 스크럼을 이름만 가져다 쓰는 있었다.

맥락의 중요성

• 특정한 개발 방법이나 프레임워크, 테스트 기법을 굳이 사용하는 이유가 무엇인가?
• 성공한 회사의 정책과 프로세스를 다들 앞다투어 도입하고 있다. 각자의 방식으로 소프트웨어를 개발하고 관리한다.
  하지만 맥락을 고려해야 한다.

 

Tip 87 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.

• "잘 맞는 것"을 어떻게 알 수 있을까?
  • 한번 해 보라.
• 시험해 보고 잘 맞는 것 같은 좋은 부분만 유지하고 나머지는 버리면 된다.

만병통치약은 아무 병도 못 고친다.

• 소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이다.
• 소프트웨어를 개발할 때 늘 따를 수 있는 단 하나의 계획이란 것은 없다.
• 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다.
• 만병통치약은 없고, 현재의 방법론들도 아직 완성되려면 멀었다.

진짜 목표

• 진짜 목표는 당연히 "스크럼을 한다"나 "애자일을 한다", "린을 한다" 같은 종류가 아니다.
• 진짜 목표는 작동하는 소프트웨어를 제공함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다.

 

Tip 88 사용자에게 필요할 때 제공하라.

• 버전 관리 시스템의 기능(feature) 브랜치가 아니라 주(main) 브랜치 혹은 트렁크(trunk)에서 개발해야 한다.
• 사용자에게 선택적으로 시범적 기능을 공개할 때는 '기능 스위치'같은 기법을 활용하라.
• 하지만 우리말을 곧이곧대로 받아들이지는 말라.
• 직접 이런 접근 방법들을 조사하고 시도해 보라.
• 하지만 지나치지 않도록 주의하라.
• 하나에 고착되면 머지않아 다른 길을 보기 어렵게 된다.

Topic 51 실용주의 시작 도구

생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다.

• 일상적인 작업은 모두 자동화해야 한다.
  • 빌드, 릴리스, 테스트, 프로젝트 서류 등
• 프로젝트에서 일관성과 반복 가능성을 확보하고 싶다.

 

버전 관리로 운용하라

• 프로젝트를 빌드하는데 필요한 모든 것을 버전 관리하에 두어야 한다.
• 빌드 머신이나 빌드 클러스터를 필요할 때마다 클라우드의 스폿 인스턴스를 이용하여 만들어 쓸 수 있다.
• 배포 설정도 역시 버전 관리 시스템 안에 있으므로 실제 서비스에 릴리스하는 것도 자동으로 처리된다.
• 프로젝트 차원에서는 버전 관리 시스템이 빌드와 릴리스 프로세스를 운용한다.

 

Tip 89 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.

• 버전 관리 시스템의 커밋이나 푸시로 빌드와 테스트, 배포가 시작된다.
• 빌드는 클라우드의 컨테이너 위에서 돌아간다.
• 테스트를 위해 스테이징 서버에 배포할지 실제 서비스에 릴리스할지는 버전 관리 시스템의 태그를 사용하여 지정한다.
• 빌드 장비나 개발자의 장비에 의존하지 않는 진정한 지속적 배포가 가능해진다.

 

가차 없고 지속적인 테스트

• 많은 개발자들이 무의식적으로 코드가 어디에서 깨지는지 파악하고서는 약한 지점을 피해 다니면서 살살 테스트하려 한다.

 

Tip 90 일찍 테스트하고, 자주 테스트하라, 자동으로 테스트하라.

• 훌륭한 프로젝트에는 제품 코드보다 테스트 코드가 더 많을 수도 있다.
• 길게 보면 테스트를 하는 쪽이 훨씬 더 싸게 먹히며, 결함이 거의 없는 제품을 만드는 꿈이 정말 이루어지기도 한다.
• 테스트를 통과했다는 것은 그 코드가 '완성'되었다는 말에 높은 수준의 확신을 준다.

 

Tip 91 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.

• 자동 빌드가 모든 가용한 테스트를 수행한다.
• "진짜 상황 테스트"를 목표로 하는 것이 중요하다.
  즉 테스트 환경은 실제 환경과 최대한 비슷해야 한다.
  두 환경의 차이에서 버그가 번식한다.
• 빌드 과정에는 소프트웨어 테스트의 몇 가지 주요 유형이 들어가야 한다.
  • 단위 테스트, 통합 테스트, 유효성 평가 및 검증, 성능 테스트가 그것이다.
• 단위 테스트
  • 하나의 모듈을 테스트하는 코드
• 통합 테스트
  • 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 테스트
  • 단위 테스트의 확장
• 유효성 평가 및 검증
  • 사용자들이 필요로 하는 것인가?
  • 시스템의 기능적 요구 사항을 충족하는가?
  • 버그가 없는 시스템일지언정 잘못된 문제를 푼다면 별 쓸모가 없다.
• 성능 테스트
  • = 스트레스 테스트
  • 소프트웨어가 실세계 조건에서 선능 요구 사항들을 준수하는지 테스트
• 테스트를 테스트하기
  • 의도적으로 버그를 생기도록 하여 테스트
  • e.g. 카오스 몽키

 

Tip 92 버그를 심어 놓고 테스트를 테스트하라.

• 철저한 테스트
  • 100 % 커버리지를 기대하지는 말라.
  • 프로그램의 모든 가능한 상태를 확인해야 할 것이다.

 

Tip 93 코드 커버리지만 올리지 말고 상태 조합을 테스트하라.

• 속성 기반 테스트

 

그물 조이기

 

Tip 94 버그는 한 번만 잡아라.

• 한번 인간 테스트가 버그를 찾았다면 해당 버그를 확인할 수 있게 자동화 테스트를 수정해야 한다.

 

전체 자동화

• 수작업이 필요해서는 안 된다.

 

Tip 95 수작업 절차를 사용하지 말라.

• 모든 것이 자동화의 의존한다.
• 버전 관리, 가차 없는 테스트, 전체 자동화라는 세 기둥이 있다면 프로젝트에 필수적인 견고한 기반이 생긴 것이다.

Topic 52 사용자를 기쁘게 하라

당신이 사람들을 황홀하게 만들 때, 당신의 목표는 그들로부터 돈을 벌거나, 당신이 원하는 일을 시키는 것이 아닙니다.
사람들을 커다란 기쁨으로 충만하게 하는 것입니다.

• 개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다.
• 사용자가 기대하는 것은 소프트웨어와 관련이 없다.
• 소프트웨어는 목적을 달성하기 위한 수단일 뿐이다.

사용자 관점에서 생각하기

• 모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다.
• 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라.
• 이런 기대를 염두에 두고 사용자 요구 사항을 비판적으로 분석하라.
  요구 사항을 바꾸면 프로젝트가 목표에 가까워진다는 것을 보여줄 수 있는가? 주저하지 말고 바꾸자고 제안하라.
• 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 사용하라.

 

Tip 96 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라.

• 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정한 우리의 직함은 "문제 해결사"다.
• 우리는 문제를 해결한다.

Topic 53 오만과 편견

너는 지금까지 우리를 충분히 즐겁게 해 주었단다.

• 실용주의 프로그래머는 책임을 회피하지 않는다.
• 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다.
• 설계 혹은 코드를 맡는다면 자신이 보기에 자랑스러운 작품으로 만들어 낼 것이다.

 

Tip 97 자신의 작품에 서명하라.

• 익명성은 특히 큰 프로젝트에서 적당주의나 실수, 태만, 나쁜 코드의 온상이 될 수 있다.
• 우리는 소유권에 대한 긍지(pride)를 보고 싶다.
• "내가 이걸 만들었고, 내 작품의 품질을 보증합니다."
• 우리의 서명이 품질의 보증 수표로 인식되게 해야 한다.
• 사람들이 코드에 붙은 우리의 이름을 보고 그것이 튼튼하고 잘 작성되었으며 제대로 테스트되었을 뿐 아니라 훌륭히 문서화되었을 것이라고 기대하도록 만들자.
• 전문가가 만든 진정으로 전문가다운 결과물.