[책] 실용주의 프로그래머 9장 실용주의 프로젝트

실용주의 프로그래머

The Pragmatic Programmer

 

9장. 실용주의 프로젝트

Pragmatic Projects (p.77)

 

Topic 49. 실용주의 팀 (p.378)

실용주의 철학을 살리면서 이를 어떻게 이룰 수 있는지.

 

이 책에서 이제까지 살펴본 실용주의 기법들은 팀에도 적용된다.

 

실용주의 팀은 작다.

구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다.

모두가 서로 잘 알고, 신뢰하며, 의존해야 한다.

 

TIp 84. 작고 안정적인 팀을 유지하라
팀은 작고 안정적이어야 한다. 모두가 서로를 신뢰하고 의존해야 한다.

 

* 깨진 창문을 없애라

품질은 팀의 문제다.

품질은 팀원 모두가 제각기 기여할 때만 보장된다.

품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다.

 

* 삶은 개구리

모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라.

무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다.

새 요구사항에 대한 수치를 관리하라.

 

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

성공을 원하는 팀이라면 자신들의 지식과 기술에 투자하는 것을 고려해야 한다.

새로운 기능을 만드는 것 외에도 해야 할 일들이 있다.

1. 구형 시스템 유지 보수

2. 프로세스 회고와 개선

3. 새로운 기술 탐험

4. 학습 및 기술 갈고 닦기

 

Tip 85. 실현하려면 계획하라.
계획하지 않으면 실현되지 않을 것이다. 회고, 실험, 학습, 기술연마를 계획하라.

 

* 팀의 존재를 소통하라

팀도 나머지 세상과 명확하게 의사소통해야 하는 존재다.

외부 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트팀이야말로 최악이다.

 

훌륭한 프로젝트팀은 뚜렷한 특성이 있다.

생산해 내는 문서는 깔끔하고 정확하며 일관적이다.

 

프로젝트 시작할 때, 팀 이름을 짓고 괴짜스러운 로고도 만들어 사용하라.

사람들과 대화를 할 때 자신의 팀 이름을 거리낌 없이 사용하라.

팀은 정체성 확립의 기반을 얻을 것이고,

세상은 여러분의 작업과 관련해서 기억할 만한 뭔가를 얻게 될 것이다.

 

* 반복하지 말라

즉각적이고 매끄러운 의사소통이 중복된 일(문제)을 피하는 핵심이다.

여러분은 팀 동료에게 질문을 하고 거의 즉각적으로 답을 받을 수 있어야 한다.

DRY(Don’t Repeat Yourself)를 지키려면 서로 관심을 유지하라.

 

* 팀 예광탄

작업에 필요한 기술을 팀 안에 모두 갖추어야 한다.

프론트엔드, UI/UX, 서버, DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다.

 

Tip 86. 모든 기능을 갖춘 팀을 조직하라.
직무가 아니라 기능성을 중심으로 팀을 조직하라.
UI/UX 디자이너와 코더를 분리하거나, 프론트엔드와 백엔드,
테스터와 데이터 모델러, 설계와 배포를 분리하지 말라.
코드를 처음부터 끝까지 점진적이고 반복적으로 만들 수 있는 팀을 조직하라.

 

* 자동화

일관성과 정확성을 모두 보장하는 확실한 방법은 팀이 하는 모든 일을 자동화하는 것이다.

도구 제작 역량을 팀내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라.

 

* 멈춰야 할 때를 알라

각 팀원이 자신의 방식대로 빛나게 하라.

팀원들을 지원하기에, 그리고 프로젝트가 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라.

 

 

Topic 50. 코코넛만으로는 부족하다 (p.387)

성공의 진정한 비법.

 

눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망하지 말라.

피상적인 결과물에만 투자하지 말라.

 

* 맥락의 중요성

유행에 속아 넘어가지 말라.

특정한 결과물, 피상적인 구조나 정책, 프로세스, 방법론만으로는 부족하다.

 

Tip 87. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.
다른 회사가 쓴다는 이유만으로 개발 방법론이나 기법을 도입하지 말라.
여러분의 팀과 여러분의 환경에 잘 맞는 것을 도입하라.

 

가장 근본적인 실용주의 기법을 적용하여 "잘 맞는 것"을 알 수 있다.

 

작은 팀 하나나 조직에서 아이디어를 시험해 보라.

잘 맞는 것 같은 좋은 부분만 유지하고

나머지는 낭비나 비용일 뿐이므로 버리면 된다.

 

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

소프트웨어를 개발할 때 늘 따를 수 있는 단 하나의 계획이란 것은 없다.

기존의 규칙 너머를 보고 개선의 여지를 찾아내는 능력이 필요하다.

여러 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해라.

 

* 진짜 목표

진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다.

 

Tip 88. 사용자에게 필요할 때 제공하라.
프로세스가 그렇다는 이유만으로 몇 주 혹은 몇 달이나 기다리게 하지 말라.

 

Topic 51. 실용주의 시작 도구 (p.392)

버전 관리, 테스트, 자동화.

 

어떤 작업이건 간에 일상적인 작업은 모두 자동화해야 한다.

 

* 버전 관리로 운용하라

Tip 89. 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.
커밋이나 푸시로 빌드, 테스트, 릴리스를 시작시켜라.
버전 관리 시스템의 태그로 서비스 배포 여부를 지정하라.

 

* 가차 없고 지속적인 테스트

Tip 90. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
빌드 때마다 도는 테스트는 책장에 꽂혀 있는 테스트 계획보다 훨씬 더 효과적이다.

 

코드를 작성하자마자 테스트해야 한다.

 

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

 

단위 테스트

'단위 테스트'는 하나의 모듈을 테스트하는 코드다.

다음 단계로 넘어가기 전 사용하는 모든 모듈의 단위 테스트가 반드시 통과해야 한다.

모든 모듈이 시스템 전체에 걸쳐 어떻게 사용되고 상호 작용하는지 테스트해야 한다.

 

통합 테스트

'통합 테스트(integration test)'는 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다.

 

유효성 평가 및 검증 (Validation and Verification)

최종 사용자의 접근 방식에 대해, 그리고 그것이 개발자의 테스트 데이터와 어떻게 다른지에 대해 관심을 기울여라.

 

성능 테스트

'성능(performance) 테스트' 혹은 스트레스 테스트 역시 프로젝트의 중요한 측면이다.

실세계 조건에서 성능 요구 사항들을 준수하는지 자문해 보라.

 

테스트를 테스트하기

완벽한 소프트웨어를 작성할 수 없기 때문에,

완벽한 테스트 소프트웨어 역시 작성할 수 없다.

 

Tip 92. 버그를 심어 놓고 테스트를 테스트하라.
소스 코드의 복사본에 고의로 버그를 심어 놓고 테스트가 잡아내는지 검증하라.

테스트를 작성할 땐 경보가 필요할 때 정말 울리는지 확인하라.

 

철저한 테스트

충분히 필요한 만큼 철저하게 테스트했다는 것은 알 수 없다!

Tip 93. 코드 커버리지만 올리지 말고 상태 조합을 테스트하라.
중요한 프로그램 상태들을 파악해서 테스트하라.
테스트에서 각 줄을 수행했다는 것만으로는 부족하다.

 

속성 기반 테스트

테스트하려는 코드의 계약과 불변식에 따라 테스트 데이터를 생성하는 '속성 기반' 테스트 기법을 사용하라.

 

* 그물 조이기

Tip 94. 버그는 한 번만 잡아라.
한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만나서는 안 된다.
그 이후로는 자동화 테스트가 확인해야 한다.

 

* 전체 자동화

Tip 95. 수작업 절차를 사용하지 말라.
컴퓨터는 똑같은 명령을 똑같은 순서로 반복해서 실행할 것이다.

 

Topic 52. 사용자를 기쁘게 하라 (p.402)

모든 프로젝트에서 후원자를 어떻게 기쁘게 하는지.

 

개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다.

 

어떻게 사용자들이 기대하는 것을 밝혀낼 수 있을까?

이 프로젝트가 끝나고 한 달(혹은 일 년이라든지) 후에 우리가 성공했는지 어떻게 알 수 있을까요?

고객 잔존율, 데이터의 품질, 절감한 비용 등으로 판단할 수 있다.

소프트웨어 프로젝트 자체가 아니라 이런 성공 척도가 진짜로 의미 있는 사업 가치다.

소프트웨어는 이런 목적을 달성하기 위한 수단일 뿐이다.

 

- 모두 사용자의 기대를 파악

- 사용자의 기대에 더 가까운 선택

- 요구 사항을 비판적으로 분석

- 프로젝트 진행 중 사용자의 기대에 대하여 계속 생각

 

Tip 96. 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라.
사용자의 사업 가치를 창조하는 해법을 개발하라.
그리고 매일 사용자를 기쁘게 하라.

진정한 여러분의 직함은 "문제 해결사"다.

이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다.

 

우리는 문제를 해결한다.

 

Topic 53. 오만과 편견 (p. 404)

자신의 작업에 자부심(pride)을 갖고 여러분의 서명을 남겨라.

 

실용주의 프로그래머는 책임을 회피하지 않는다.

Tip 97. 자신의 작품에 서명하라.
옛 장인들은 자신의 작품에 서명하는 것을 자랑스러워했다.
여러분도 그래야 한다.

 

다른 사람의 코드를 존중해야 한다.

코드에는 주인이 있어야 하지만 꼭 개인일 필요는 없다.

 

사람들이 코드에 붙은 여러분의 이름을 보고 그것이 튼튼하고 잘 작성되었으며,

제대로 테스트되었을 뿐 아니라 훌륭히 문서화되었을 것이라고 기대하도록 만들자.

 

전문가가 만든 진정으로 전문가다운 결과물.

실용주의 프로그래머.

 

끝.

 

 

맺는말

우리는 백지에서 시작하여 우리가 상상할 수 있는 거의 무엇이든 만들어 낼 수 있다.

그리고 우리가 만드는 것이 세상을 바꿀 수 있다.

어떤 결과가 나올지는 여러분의 손에 달렸다.

 

* 도덕적 잣대

의도치 않은 이 힘의 대가로 우리는 늘 경각심을 가져야 한다.

우리는 우리가 내놓는 모든 코드마다 두 가지 질문을 던질 책임이 있다.

1. 사용자를 보호했는가?

 나는 이 코드의 사용자를 위험으로부터 보호하기 위해 최선을 다했는가?

Tip 98. 먼저, 해를 끼치지 말라.
실패는 피할 수 없다. 그로 인해 누구도 고통받지 않게 하라.

2. 나라면 이것을 쓸까?

 내가 이 소프트웨어의 사용자라면 만족스러울까?

Tip 99. 쓰레기 같은 인간을 돕지 말라.
여러분도 똑같은 인간이 되고 말 것이다.

 

* 여러분이 원하는 미래를 상상하라

여러분에게 달렸다.

여러분은 자신 그리고 여러분 후손들의 미래를 만들고 있다.

우리 모두가 살고 싶은 미래를 만드는 것이 여러분의 책무다.

 

우리가 가질 수 있는 미래를 그리고, 실제로 그런 미래를 만들어 내는 용기를 가져라.

매일매일 허공에 성을 지어라.

 

우리 모두에게는 아름다운 인생이 있다.

Tip 100. 결국 당신의 삶이다.
삶을 사람들과 나누고, 삶을 축하하고, 삶을 만들어가라.
그리고 그걸 즐겨라!
우리에게 주어진 놀라운 삶을 즐기고, 위대한 일을 하라.