개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
요구 사항 문서는 클라이언트가 아니라 우리, 개발자를 위한 것임을 명심하자
함께 일하는 법을 배우자. 한 모듈에 동시에 여러명이 코딩하는 것이 항상 최선은 아니다.
고치기 쉽게 만들고 피드백하고 그것을 반복하라.
TIL (Today I Learned) 날짜
2022. 04. 03
오늘 읽은 범위
8장. 프로젝트 전에
책에서 기억하고 싶은 내용을 써보세요.
Topic 45. 요구 사항의 구렁텅이 (p.350)
자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
요구 사항을 이해하려면 탐험과 피드백을 거쳐야 한다.
결정한 요구 사항의 여파를 바탕으로 처음의 발상을 다듬는다.사용자처럼 생각하기 위해 사용자와 함께 일하라.
시스템이 정말로 어떻게 사용될지 통찰을 얻을 수 있는 가장 좋은 방법이다.요구 사항 문서는 계획을 위한 것이다.
요구 사항 설명을 짧게 제한하면 개발자들이 명확하지 않은 점을 물어보도록 유도할 수 있다.
좋은 요구 사항은 추상적이다.
프로젝트에서 쓰이는 용어와 어휘들을 모두 한곳에 모으고 관리하라.
Topic 46. 불가능한 퍼즐 풀기 (p.362)
절대적 제약 조건은 그것이 아무리 불쾌하거나 어리석어 보여도 꼭 따라야 한다.
문제는 틀을 찾는 것은, 곧 진짜 제약을 찾는 일이다.
문제가 생각보다 훨씬 어려울 때 잠깐 다른 일을 해보자. 산책을 하거나 아예 내일로 미루거나..그저 문제에 대해 이야기하는 것으로 주의를 돌리기만 해도 깨달음을 얻을 때가 있다.
여러분의 뇌에 경험을 주입하는 가장 좋은 방법은 이상적인 작업을 할 때 무엇은 잘되고 무엇은 안되는지 피드백을 주는 것이다.
Topic 47. 함께 일하기 (p.367)
사용자와 밀접하게 함께 일해라. 사용자는 여러분 팀의 일원이다.
그저 질문하고, 토론하고 메모를 하는 것이 아니라, 실제로 코딩을 하는 와중에 질문을 하고 토론을 하는것이다.
짝 프로그래밍(pair programming)
다른 사람이 지켜보고 있으면 민망할 수도 있는 꼼수를 덜 쓰게 되고,
결과적으로 소프트웨어의 품질이 좋아진다.
몹 프로그래밍(mob programming)
셋 이상의 사람이 참여하는 짝 프로그래밍의 확장판이다.
'실시간 코딩을 곁들인 밀접한 협업'이라고 생각해도 될 것이다.
여러분과 여러분의 팀이 늘 한 가지 방법으로만 일했다면, 다른 방식을 실험해 보는 것이 좋다.
프로그래밍은 어렵고 힘들 수 있다. 친구와 함께 가라.
Topic 48. 애자일의 핵심 (p.372)
애자일은 여러분이 일하는 방식이지 여러분이 아니다.
애자일은 형용사다. 즉, 무언가를 하는 방식이다.
애자일의 가치는 소프트웨어를 만드는 더 나은 방법을 지속적으로 탐구하는 과정에서 찾고 알게 되는 것이다.
소프트웨어를 개발할 때 따라야 할 단 한 가지 계획이란 없다. 온통 피드백을 수집하고 그에 대응하라.
지속적으로 프로세스를 실험하지 않는 팀은 애자일 팀이 아니다.
애자일이 전반적으로 작동하게 하려면 바꾸기 쉬운 좋은 설계를 만들어야 한다.
바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로잡을 수 있을 것이다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
요구 사항 문서를 정리 하는 것이 얼마나 중요한지 알게 되었어요. 또한 문서 정리를 잘하는 사람이 왜 그렇게 중요한 취급을 받고 더 중요한지도 다시 한번 더 생각하게 되었어요.
코드를 한명이 작성하고 1명~여러명의 사람이 함께 보며 조언을 하고 진행하는 것을, 책 내용에서처럼은 못한다 하더라도, 서로 작성한 코드를 함게 리뷰하는 시간만큼은 꼭 있으면 좋겠다고 생각했어요. 팀원들에게 서로 작성한 코드를 서로에게 설명하는 시간을 가져보자고 제안 해봐야겠어요.
저부터 바꾸기 쉬운 코드를 작성하고 피드백을 받고 테스트 하고 수정하는 과정을 짧고 반복적으로 수행할 수 있도록 노력 해봐야겠어요!
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
오늘 읽은 다른사람의 TIL
shuttle님의 TIL (https://nomadcoders.co/community/thread/4168)