실용주의 프로그래머 읽어보기 7주차

들어가며

이 포스트는 데이비드 토머스, 앤드류 헌트의 「실용주의 프로그래머」 Topic42 ~ 45까지 읽고 개인적으로 학습한 내용을 정리한 글입니다.

• 책: 실용주의 프로그래머
• 저자: 데이비드 토머스, 앤드류 헌트
• 출판사: 인사이트
• 챕터: Topic 46 ~ Topic 53

핵심 내용 정리

Topic 46 불가능한 퍼즐 풀기

• 실제 제약 조건을 알아내고, 그 속에서 해법을 찾는 것

자유도

Tip 81 생각의 틀을 벗어나지 말고, 틀을 찾아라

• 어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 자신에게 주어진 자유도를 파악하는 것이다
• 제약을 범주별로 나누고 우선순위를 매겨라

자신만의 방법에서 빠져나오라

간단히 표현하면 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다

Topic 47 함께 일하기

• 페어 프로그래밍은 함께 일하는 강력한 방법이다

짝 프로그래밍

• 짝 프로그래밍에서 개발자 한 명은 키보드를 조작하지만, 다른 한 명은 하지 않는다. 키보드 담당은 필요에 따라 바꿀 수 있고, 둘이 함께 문제를 푼다
• 짝 프로그래밍의 단점
  • 문제를 푸는 다른 기법과 접근 방법을 배울 수 있다
  • 두 번째 사람으로 인해 사회적 압력을 받아 프로그래밍의 나쁜 습관이나 약점을 제거할 수 있다

몹 프로그래밍

• 셋 이상의 사람이 참여하는 짝 프로그래밍의 확장판

무엇을 해야 할까?

• 짝 프로그래밍 시도하기
  • 한 번에 1~2시간 최소 2주 해보기
• 짝 프로그래밍 tip
  • 코드를 짜는 거지 ego를 쌓는 것이 아니다. 누가 가장 똑똑한지 겨루는 것이 아니다
  • 소규모로 시작하라
  • 코드만 비판하고 사람을 비판하지 말라
  • 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다
  • 자주 회고 하라

Topic 48. 애자일의 핵심

Tip 83 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다

• 애자일 선언에서의 가치
  • 공정과 도구보다 개인과 상호작용
  • 포괄적인 문서보다 작동하는 소프트웨어
  • 계약 협상보다 고객과의 협력
  • 계획을 따르기보다 변화에 대응하기

애자일 프로세스라는 것은 있을 수 없다

• 물리적 세계이든 소프트웨어 개발에서든 애자일은 변화에 대응하는 것, 일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것이 전부이다
• 소프트웨어를 개발할 때 따라야 할 단 한 가지 계획이란 없다

그래서 우리는 무엇을 해야 할까?

• 애자일하게 일하는 방법
  • 자신이 어디에 있는지 알아내라
  • 도달하고 싶은 곳을 항해 의미 있는 발걸음을 가능한 작게 옮겨라
  • 어디에 도착했느지 평가하고, 망가트린 것이 있으면 고쳐라
  • 위의 과정을 끝날 때가지 반복하라

Topic 49 실용주의 팀

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

깨진 창문을 없애라

• 품질은 팀의 문제다
• 아무리 부지런한 개발자라도 품질에 무심한 팀에 배치된다면, 자질구레하게 계속되는 문제를 고치는 데 필요한 열정을 유지하긴 어려울 것이다
• 팀 전체가 깨진 창문을 용납하지 않아야 한다
• 사소한 결점을 아무도 고치지 않고 놔두어서는 안되고, 반드시 제품의 품질에 책임을 져야 한다

삶은 개구리

• 팀은 개인보다 더 삶은 개구리가 되기 쉽다
  • 방관자 효과 ( 제노비스 사건 )
  • https://ko.wikipedia.org/wiki/%ED%82%A4%ED%8B%B0%EC%A0%9C%EB%85%B8%EB%B9%84%EC%8A%A4%EC%82%AC%EA%B1%B4

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

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

구형 시스템 유지 보수

• 팀이 이 업무를 맡고 있따면, 진짜로 수행하라

프로세스 회고와 개선

• 지속적인 개선이 일어나려면 주위를 둘러보고 무엇이 잘되고 무엇이 잘되지 않았는지 확인 후 다음 변화를 일으킬 시간이 있어야 한다

새로운 기술 탐험

• 후보 기술로 프로토타입을 만들어보고 신중하게 조사하라

학습 및 기술 갈고 닦기

• 팀원들을 전도할 계획을 세워라
• 점심 먹으며 가볍게 이야기할 수도 있고, 더 형식을 갖추어 스터디 시간을 잡을 수도 있다

팀의 존재를 소통하라

• 훌륭한 프로젝트팀은 뚜렷한 특성이 있다
  • 사람들은 이 팀과의 회의를 기대한다
  • 이들이 생산해내는 문서는 깔끔하고 정확하고 일관적이다

반복하지 말라

• 좋은 의사소통은 즉각적이고 매끄러운 소통
  • 질문하기, 진행 상황이나 문제, 통찰 및 새롭게 알게 된 점 공유하기, 동료가 뭘 하고 있는지 알고 있기가 쉽고 거추장스러운 단계가 적다는 의미

팀 예광탄

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

• 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천
• 팀 모두가 함께 일하는 것에 편안하고 익숙해야 한다

자동화

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

멈춰야할 때를 알라

• 각 팀원이 자신의 방식대로 빛나게 하라
• 팀원들을 지원하기에 그리고 프로젝트가 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라

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

• cargo cult
  • 너무 솔깃한 함정

맥락의 중요성

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

• 각자 나름의 방식으로 소프트웨어를 개발하고 관리하지만, 맥락을 고려해야 한다

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

• 소프트웨어를 개발할 때 늘 따를 수 있는 단 하나의 계획이란 없다
• 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정해 사용해야 한다

진짜 목표

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

• 진짜 목표는 작동하는 소프트웨어를 제공함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다
• 제품을 몇 년에 한 번꼴로 출시하고 있다면, 주기를 몇 달에 한 번으로 줄이도록 노력해 보라

Topic 51. 실용주의 시작 도구

버전 관리로 운용하라

• 프로젝트 차원에서 버전 관리 시스팀이 빌드와 릴리스 프로세스를 운용한다

가차 없고 지속적인 테스트

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

• 많은 개발자들이 무의식적으로 코드가 어디에서 깨지는 지 파악하고 약한 지점을 피해 다니며 살살 테스트하려 한다
• 실용주의 프로그래머들은 버그를 찾도록 자신을 몰아세워, 다른 사람이 자기 버글르 발견하게 되는 딱한 상황을 피할 수 있다

단위 테스트

• 부분으로 떼어 놓았을 때 제대로 작동하지 않는다면 합쳤을 때도 역시 제대로 작동하지 않을 것이다

통합 테스트

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

유효성 평가 및 검증

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

성능 테스트

• 소프트웨어가 실세계 조건에서 성능 요구 사항들을 준수하는지 자문해 보라

테스트를 테스트하기

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

철저한 테스트

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

그물 조이기

Tip 94 버그는 한 번만 잡아라

전체 자동화

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

Topic 52. 사용자를 기쁘게 하라

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

• 사용자들이 기대하는 것을 밝히는 방법
  • “이 프로젝트가 끝나고 한 달(혹은 일 년이라든지) 후에 우리가 성공했는지 어떻게 알 수 있을까요?”
• 사용자의 기대를 충족시키기 위한 고민 방법
  • 모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다
  • 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라
  • 이런 기대를 염두에 두고 사용자 요구 사항을 비판적으로 분석하라
  • 프로젝트를 진행하면서도 계속 사용자의 기대에 대해 생각하라

Topic 53. 오만과 편견

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