[오혜성] 8장: 실용주의 프로젝트

8장/오혜성.md

@@ -0,0 +1,94 @@
+# 실용주의 프로젝트
+
+## 실용주의 팀
+
+- 개인이 실용주의적이 되는 것에도 이득이 있지만, 그 개인이 실용주의 팀에서 일한다면 이득은 몇 배가 된다.
+
+- 팀 전체가 깨진 창문을 용납하지 않아야 한다
+
+- 개인보다 팀이 삶은 개구리가 되기 쉬움
+  - 누군가가 문제를 처리했겠거니 싶어짐
+  - 모든 사람이 적극적으로 환경 변화를 감시해야 함
+
+- 바깥 사람들에게 과묵하고 무뚝뚝해 보이는 팀이야 말로 최악
+  - 간단한 마케팅 비결은, 프로젝트를 시작할 때 이름을 비어주는 것. 유별난 이름으로.
+  - 멍텅구리 로고를 만들어 사용해라
+  - 정체성 확립의 기반, 세상이 기억할 만한 뭔가
+
+- 반복하지 않기 위해 프로젝트 사서를 두어라
+  - 사서가 감당하기 너무 크거나, 아무도 맡지 않으려 한다면 작업의 기능적 측면의 핵심 사안별로 사람을 임명하는 방법
+
+- 팀을 기능적으로 분리하자
+  - 개발자들이 더욱 헌신적인 집단이 되도록 해줌 (주인의식)
+  - 개인간 상호작용 횟수 감소, 품질 향상, 오류 감소에 도움이 됨
+
+## 유비쿼터스 자동화
+
+- 생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다
+
+- 사람들은 컴퓨터만큼 반복가능하지 않을 뿐더러, 기대해서도 안된다
+  - 알잘딱 자동화해라
+
+- 테스트를 주기적으로 실행해라
+  - 언제부터 깨졌는지 알기 위해
+
+- 반복적이고 지루한 것은 컴퓨터에게 시키자.
+  - 우리에겐 더 중요하고 어려운 일들이 있다
+
+## 가차 없는 테스트
+
+- 개발자 대부분은 테스트를 싫어함
+  - 코드가 어디에서 깨지는지 무의식적으로 알고 약한 지점을 피해다니면서 살살 테스트하려 함
+
+> 왜인지 모르게 공감됨 ㅋㅋㅋ
+
+- 버그 찾기는 그물낚시와 비슷
+  - 잔챙이를 잡기 위한 촘촘한 그물 (유닛 테스트)
+  - 식인상어를 잡기 위해 크고 성긴 그물을 쓰기도 함 (통합 테스트)
+
+- 완벽한 소프트웨어를 작성할 수 없기 때문에 완벽한 테스트 역시 작성할 수 없음
+
+- 버그가 있다면, 고치고 새로운 테스트를 추가해라
+  - 버그는 한 번만 잡아라
+
+- GUI 독립적으로 애플리케이션 로직을 테스트하는 것이 너무 어려운가?
+  - 이것이 그 GUI에 대해 무엇을 말해주는가?
+
+## 결국은 모두 글쓰기
+
+- 실용주의 프로그래머들은 문서화를 전체 개발 프로세스의 필요불가결한 부분으로 포용한다
+  - 문서를 늘 손에 닿는 가까이에 두면 문서 작성이 더 쉬워진다
+  - 가능하다면 코드 속에
+
+- 모든 문서는 코드의 겨울
+  - 불일치가 있다면 중요한 것은 코드
+
+
+- 주석은 왜 이렇게 되어 있는지, 그 목적을 논해야 한다
+  - 공학적 트레이드오프나 어떤 결정의 이유, 어떤 대안을 버렸는지 등을 문서화하기 위한 완벽한 기회
+
+## 위대한 유산
+
+- 프로젝트의 성공은 사용자들의 기대를 얼마나 잘 충족하는가에 따라 측정됨
+  - 기대에 못 미치는 프로젝트는 이론적으로 훌륭해도 실패
+  - 기대를 너무 지나쳐 버려도 역시 실패할 것
+
+- 우리의 역할은 사용자들의 희망을 제어하는 것이 아님
+  - 그들과 협동해서 그들이 아직 이야기하지 않은 기대까지 포함해 공통된 이해에 도달하는 것
+
+- 사용자들을 놀래켜 주려고 노력해야 함
+  - 기쁘게
+  - 그들이 기대하는 것보다 조금만 더 해주어라
+
+## 오만과 편견
+
+- 실용주의 프로그래머들은 책임을 회피하지 않음
+  - 도전을 수용하고 자신의 전문적 지식을 널리 알려지는 것을 기뻐함
+
+- 개발자간에 황금률
+  - 남들이 자신에게 해주기 바라는 대로 남에게 행하라
+
+- 여러분의 서명이 품질의 보증수표로 인식되게 해야 한다
+  - 이름을 보고 그것은 튼튼하고 잘 작성되고 제대로 테스트되었으며 훌륭히 문서화되었을 것이라고 기대하도록 만들자
+
+