실용주의 프로그래머 8장 < 프로젝트 전에 >
Impressive content
- 인상 깊었던 내용
...생각하기를 대신할 수는 없다.
Topic45. 요구 사항의 구렁텅이
완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 달성되는것이다.
- 앙투안 드 생텍쥐페리,<< 바람과 모래와 별들 >>
Tip 75 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
그래서 우리 프로그래머들이 등장한다. 우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다.
신입 개발자들이 자주 범하는 실수는 이런 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다. -352p.
이것이 우리가 하는 일이다. 간단해 보이는 무언가를 받으면 특이한 경우에 대해 캐물어서 사람들을 화나게 하는것 말이다.
Tip 77 요구 사항은 피드백을 반복하며 알게 된다.
"일하시는 데 일주일만 옆에 앉아 있어도 될까요?" 라고 부탁하는 것이 의뢰인과 신뢰를 구축하고 의사소통의 기반을 다지는 데 얼마나 도움이 되는지 놀라게 될 것이다. 단, 방해하지 않도록 주의하라.
Tip 79 정책은 메타데이터다.
이 예는 도구가 성공하려면 사용하는 사람의 손에 적응할 수 있어야 한다는 우리의 믿음을 잘 보여준다.
문서는 구현 과정에서 안내 역활을 하는 이정표일 뿐이다.
따라서 의뢰인이 말하는 것을 확장하여 법률 문서에 준하는 수준으로 만든 문서는 그저 사상누각에 불과하다.
좋은 요구 사항은 추상적이다. -359p.
밑에 깔려 있는 의미론적 불변식을 요구사항으로 잘 갈무리하고, 구체적인 작업 방식이나 현재의 작업 방식은 정책으로 문서화해야 한다.
요구사항은 필요를 설명하는 것이다.
'프로젝트 용어 사전' 을 만들고 관리하라. 프로젝트에서 사용하는 모든 용어와 어위를 모아 놓은 단 하나의 장소여야 한다. -360p.
Topic46. 불가능한 퍼즐 풀기
이런 퍼즐을 푸는 비법은 상상 속이 아닌 실제 제약 조건을 알아내고, 그 속에서 해법을 찾는 것이다. -363p.
어떤 제약 조건은 절대적이지만, 다른 것들은 단순한 지레짐작에 불과하다.
어떤 퍼즐이던 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 여러분에게 주어진 자유도degree of freedom를 파악하는 것이다. 퍼즐의 해답은 그 자유도 안에서 발견된다.
풀리지 않는 문제와 마주쳤다면 생각해 볼 수 있는 모든 해결 경로 후보를 눈앞에 나열해 보라.
간단히 표현하면 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다.
문제 해결에 필요한 원료는 바로 해답에 도움이 될 수 있는 경험이다.
Topic47. 함께 일하기
한 사람이 코드를 입력하는 동안 한 명 혹은 여러 명의 팀 동료가 조언하고 고민하며 문제를 함께 푸는 것이다. (짝 프로그래밍, 몹 프로그래밍)
실제로 코딩을 하는 와정에 질문을 하고 토론을 하는 것이다.
짝 프로그래밍은 개발자 한 명은 키보드를 조작하지만 다른 한 명은 하지 않는다. .. 둘이 함께 문제를 푼다.
입력을 담당한 개발자는 문법이나 코딩 스타일 같은 낮은 수준의 세부 사항에 집중해야만 한다. 반면에 다른 개발자는 문제를 더 높은 수준에서 넓은 범위를 보며 고민할 수 있다.
Tip 82 코드에 혼자 들어가지 말라.
Topic48. 애자일의 핵심
그 단어를 계속 쓰는군. 그 단어의 뜻이 네가 생각하는 그 뜻이 아닌 것 같은데.
- 영화 < 프린세스 브라이드 > 중 이니고 몬토야의 말
'애자일agile' 은 '기민하다'라는 뜻의 형용사이다. 즉, 무언가를 하는 방식이다. 애자일은 여러분이 일하는 방식이지 여러분 아니다. -372p.
- 공정과 도구보다 개인과 상호작용
- 포괄적인 문서보다 작동하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획을 따르기보다 변화에 대응하기
왼쪽에 있는 것도 가치가 있지만 우리는 오른쪽에 있는 것에 더 높은 가치를 둔다.
모든 것이 결국 여러분이 불확실성을 어떻게 다룰 것인가 하는 문제에 달렸다.
우리 피드백의 고리를 효율적으로 만들려면 가능한 고치는 일이 쉬어야 한다.
Thoughts I had while reading the book
- 오늘 책을 읽으면서...
이번주 수요일 프로젝트 문서화를 시작할 예정이였다. 요구사항에 대한 정리는 프로젝트 시작하기 전에도 너무 어려웠는데 오늘 내용을 읽고나니 좀 감이 잡힌다.
수요일에 문서화를 어떻게 할까 고민하고 있었는데 위 문구를 보고 작은 기능 단위로 나누어서 사용자에 관점에서 어떻게 작동하는지 설명하는 인덱스카드로 만들어보기로 결심했다.
함께 일하기를 읽으면서 나는 정말 함께 일할 수 있는 사람인지 고민했다. 원래는 혼자 포트폴리오를 만들어보려고 했는데 굳이 개발이 아니더라도 디자이너나 사용자를 옆에 두고 개발을 해봐야겠다는 생각을 했다.
도전해볼것
- 오늘 여러분이 풀려고 씨름한 어려운 문제 가운데 무엇이든 하나를 고라 유심히 살펴보라. 고르디우스의 매듭을 자를 수 있는가? 반드시 이 방법으로 해야 하는가? 이 일을 꼭 해야하는 것이 맞는가?
