8장. 프로젝트 전에

안녕하세요 😀

 유로띠 입니다 😉

 

 

 

 

 

 

실용주의 프로그래머

---

TIL (Today I Learned)

3줄 요약

 

✏️  우리가 하는 일은 특이한 경우에 대해 집요하게 캐물어서 사람들을 화나게 해야 한다. 

✏️  행운은 준비된 사람에게 찾아온다. 🍀

✏️  코드에 혼자 들어가지 말자... 코드 리뷰를 하자.

 

DAY 8

오늘 읽은 범위: 8장. 프로젝트 전에

 

😉 책에서 기억하고 싶은 내용을 써보세요.

🟢  프로젝트가 닻을 올리기 전에 이런 중요한 문제들이 잘 정리되어야 '분석 마비증'을 모면할 수 있다. 프로젝트를 정말로 시작하고, 성공적으로 마칠 수 있다. (P.350)

 

요구 사항의 구렁텅이

🟢  요구 사항이 땅 위에 놓여 있는 경우는 드물다. 보통은 가정과 오해, 정치의 지층 속 깊숙이 묻혀 있다. 심지어 아예 존재하지 않을 때도 있다. (P.350)

🟢  자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다. (P.350)

🟢  무엇을 다루든 정확한 명세란 것은 거의 불가능하다고 볼 수 있다. 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다. (P.351)

🟢  신입 개발자들이 자주 범하는 실수는 이런 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다. 우리의 경험상 최초의 요청 사항은 궁극적인 요구 사항이 아니다. 의뢰인은 인식하지 못할 수도 있지만, 의뢰인의 요청 사항은 사실 함께 탐험을 떠나자는 초대장이다. (P.352)

🟢  간단해 보이는 무언가를 받으면 특이한 경우에 대해 캐물어서 사람들을 화나게 하는 것 말이다. 이것이 우리가 하는 일이다. (P.352)

🟢  요구사항은 피드백을 반복하며 알게 된다. (P.354)

🟢  우리가 하는 모든 일은 일종의 모형을 만드는 것이다. 프로젝트가 막바지에 이르러서도 우리는 의뢰인이 원하는 것을 계속 해석해야 한다. 사실 프로젝트 막바지가 되면 의뢰인의 수가 늘어난다. QA 사람들, 운영팀, 마케팅, 어쩌면 고색사의 테스트 조직까지 모두 의뢰인이 된다. (P.354)

🟢  우리는 짧은 주기로 반복하는 것을 선호한다. 우리가 정말로 잘못된 방향으로 가더라도 잃어러비는 시간을 최소화할 수 있다. (P.355)

🟢  시스템은 다양한 정책을 처리할 수 있도록 일반적으로 구현해야 한다. (P.356)

🟢  문서는 구현 과정에서 안내 역할을 하는 이정표일 뿐이다. (P.357)

🟢  의뢰인이 프로그래머를 고용하는 이유는 의뢰인은 고차원적이고 모호한측면이 있는 문제를 풀고 싶어 하는 반면, 프로그래머는 세부 사항과 미묘한 차이 하나하나에 관심을 두기 때문이다. (P.358)

🟢  의뢰인에게 두꺼운 기술 문서를 들이미는것은 평범한 개발자에게 고대 그리스어로 된 <<일리아스>>를 한 권 주면서 이걸로 비디오 게임을 만들라고 하는 것이나 마찬가지다. (P.359)

🟢  좋은 요구 사항은 추상적이다. 요구 사항을 기술할 때는 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다. 요구사항은 필요를 표현하는 것이다. (P.359)

🟢  많은 프로젝트가 범위의 증가 때문에 실패한다고 알려져 있다. 해답은 다시 한번 피드백이다. (P.360)

🟢  프로젝트 용어 사전을 만들고 관리하라. (P.360)

 

불가능한 퍼즐 풀기

🟢  제약 조건은 절대적이지만, 다른 것들은 단순한 지레짐작에 불과하다. 절대적 제약 조건은 그것이 아무리 불쾌하거나 어리석어 보여도 꼭 따라야 한다. (P.363)

🟢  생각의 틀을 벗어나지 말고, 틀을 찾아라 (P.364)

🟢  제일 구속이 심한 제약부터 파악해 내고 나머지 제약을 그 안에서 맞춰 보아야 한다. (P.365)

🟢  간단히 표현하면 딴짓을 한 사람이 의식적으로 노련한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다. 그저 문제에 대해 이야기하는 것으로 주의를 돌리기만 해도 깨달음을 얻을 때가 있다. (P.365)

🟢  행운은 준비된 사람에게 찾아온다. (P.366)

 

함께 일하기

🟢  한 사람이 코드를 입력하는 동안 한 명 혹은 여러 명의 팀 동료가 조언하고 고민하며 문제를 함께 푸는 것이다. 이 방식은 함께 일하는 아주 강력한 방법이다. 끝없는 회의나 제안서보다, 그리고 유용성보다 무게를 더 중시하는 법률 문서스러운 문서 뭉치보다 훨씬 낫다. 이것이 우리가 말하는 '함께 일하기'다. 그저 질문하고, 토론하고 메모하는 것이 아니라,실제로 코딩을 하는 와중에 질문을 하고 토론을 하는 것이다. (P.368)

🟢  짝 프로그래밍에는 여러 가지 장점이 있다. 사람들은 모두 다르므로 다른 배경과 경험을 가지고 있고, 문제를 푸는 데도 다른 기법과 접근 방법을 사용한다. (P.369)

🟢  다른 사람이 지켜보고 있으면 민망할 수도 있는 꼼수를 덜 쓰게 되고, 결과적으로 소프트웨어의 품질이 좋아진다. (P.370)

🟢  몹 프로그래밍을 '실시간 코딩을 곁들인 밀접한 협업'이라고 생각해도 될 것이다. (P.370)

함께 일하는 인간적인 측면의 몇가지 팁
- 누가 가장 똑똑한지 겨루는것이 아니다. 우리 모두는 각자 뛰어난 부분이나 장단점이 있다.
- 소규모로 시작하라.
- 코드만 비판하고 사람을 비판하지 말라. "넌 틀렸어." 보다는 "이 부분을 한번 볼까요?"가 훨씬 듣기 좋다.
- 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다.
- 자주 회고를 하라. 그래서 다음번에 시도하거나 개선할 점을 찾아라. (P.371)

 

🟢  코드에 혼자 들어가지 말라. (P.371)

 

애자일의 핵심

🟢  '애자일(agile)'은 '기민하다'는 뜻의 형용사다. 즉, 무언가를 하는 방식이다. (P.372)

🟢  애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다. (P.372)

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

 

🟢  애자일의 가치는 소프트웨어를 만드는 더 나은 방법을 지속적으로 탐구하는 과정에서 찾고 알게 되는 것이기 때문이다. 애자일 선언 고정불변의 문서라기보다는 만들어 가는 과정에 대한 제안이다. (P.373)

 

🟢  애자일 프로세스라는 것은 있을 수 없다. - 사실 누군가가 "이걸 하세요. 그러면 애자일인 겁니다."라고 한다면 이건 틀린 말이다. 정의상 그렇다. (P.373)

🟢  애자일 선언은 피드백을 모으고 그에 맞게 행동함으로써 불확실성을 헤쳐 나가라고 제안한다.

여러분이 어디에 있는지 알아내라.

도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.

어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.

위과정을 끝날 때까지 반복하라. (P.375)

🟢  우리 피드백 고리를 효율적으로 만들려면 가능한 한 고치는 일이 쉬워야 한다. 애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다. 좋은 설계는 무언가를 바꾸기 쉽게 하기 때문이다. 바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로잡을 수 있을 것이다. 이것이 애자일이다. (P.376)

 

🧐 오늘 익은 소감은? 떠오르는 생각을 가볍게 적어보세요

 

✅  의뢰인의 요청사항은 함께 탐험하는 초대장이다. 초대를 받고 계속해서 피드백을 받지 않으면 결국 우리는 아무것도 모른 채 아래의 나무를 자를 수도 있다. 

프로젝트 용어 사전을 만들라고 하였는데, DDD(Domain Driven Design)에서도 구성원의 의사소통을 위해서 보편언어(Ubiquitous Language)를 사용하자고 한다.

 

✅  '함께일하기'는 remote환경에서 쉽지 않지만 그럼에도 쉽게 할 수 있는 방법이 바로 '코드 리뷰'라고 생각한다. 팀원뿐만 아니라 다른 팀원들에게서 코드에 대한 다양한 생각과 의견을 받고 토론할 수가 있다. 책에서 처럼 모든 작성한 코드를 코드 리뷰를 통해 확인되다 보니, 누군가 지켜보기 때문에 꼼수를 쓰지 않게 되고 코드로만 의도가 전달하게끔 하기 위해 품질이나 이름 짓기에도 신경을 많이 쓰게 되며, 다른 사람의 다양한 관점을 보고 이해할 수 있게 된다.

 

🙋‍♂️ 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.