9장. 실용주의 프로젝트

안녕하세요 😀

 유로띠 입니다 😉

 

 

 

 

 

 

실용주의 프로그래머

---

TIL (Today I Learned)

3줄 요약

✏️  팀과의 의사소통은 중요하다.

✏️  일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.

✏️  우리는 문제 해결사다.

 

DAY 10

오늘 읽은 범위: 9장. 실용주의 프로젝트

 

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

실용주의 팀

🟢  프로그래머는 고양이 같은 면이 있다. 호기심 많고 제멋대로이며, 고집이 세고, 독립적인 데다, 가끔은 인터넷에서 숭배를 받기도 한다. (p.378)

 

깨진 창문을 없애라. 

🟢  팀 전체가 깨진 창문을 용납하지 않아야 한다. 사소한 결점을 아무도 고치지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다. (p.379)

🟢  품질은 팀원 모두가 제각기 기여할 때만 보장되기 때문이다. 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다. (p.380)

 

삶은 개구리

🟢  제아무리 좋은 뜻을 가진 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에는 둔감할 수도 있다. 이에 맞서야 한다. 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. 범위의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다. 새 요구사항에 대한 수치를 관리하라. 이미 일어난 변화를 거부할 필요는 없다. 단지 그런 일이 벌어지고 있다는 것을 파악하고 있으면 된다. 그러지 않으면 여러분이 뜨거운 물속에서 삶아지는 신세가 될 것이다. (p.380)

 

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

🟢  여러분의 팀이 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다. "시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다."는 것이다. (p.381)

 

팀의 존재를 소통하라.

🟢  팀도 나머지 세상과 명확하게 의사소통해야 하는 존재다. 훌륭한 프로젝트팀은 뚜렷한 특성이 있다. 사람들은 이 팀과의 회의를 기대한다. (p.382)

 

반복하지 말라

🟢  중복된 일은 노력을 무위로 돌릴 뿐 아니라 결국 유지 보수를 악몽으로 만들 수도 있다. 좋은 의사소통이 이런 문제를 피하는 핵심이다. 여기서 "좋은"이란 즉각적이고 매끄러운 것을 말한다. 매ㅐ끄럽다는 것은 질문하기, 진행 상황이나 문제, 통찰 및 새롭게 알게 된 점을 공유하기, 또 동료가 뭘 하고 있는지 알고 있기가 쉽고 거추장스러운 단계가 적다는 뜻이다. DRY를 지키려면 서로 관심을 유지하라. (p.383)

 

팀 예광탄

🟢  예광탄을 시용하여, 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다. 예광탄 접근 방법을 사용하면 기능의 아주 조그만 부분을 아주 빠르게 개발할 수 있다. 또한 여러분의 팀이 얼마나 잘 소통하고 결과물을 만들어 내는지 즉각적인 피드백을 받을 수도 있다. (p.384)

 

자동화

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

 

멈춰야 할 때를 알라

🟢  팀은 개인들로 이루어진다는 사실을 명심하라. 각 팀원이 자신의 방식대로 빛나게 하라. 팀원들을 지원하기에, 그리고 프로젝트가 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라. 그러고 나면 <적당히 괜찮은 소프트웨어>에서 이야기한 화가처럼 계속 덧칠하려는 욕구를 참아야 한다. (p.385)

 

코코넛만으로는 부족하다.

🟢  화물 숭배의 함정은 너무 솔깃해서 빠지기 쉽다. 눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망한다. (p.387)

🟢  여러분이나 여러분의 팀이 이런 함정에 빠진 적은 없는가? 자문해 보라. 이 특정한 개발 방법이나 프레임워크, 테스트 기업을 굳이 사용하는 이유가 무엇인가? 정말로 지금 하는 일에 잘 맞아서인가, 자신에게 잘 맞아서인가? 아니면 그저 최근에 인터넷에서 회자된 성공 사례에서 사용했기 때문에 도인 한 것인가?.. 속아 넘어가지 말라. 특정한 결과물, 피상적인 구조나 정책, 프로세스, 방법론만으로는 부족하다. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.(p.388)

🟢  소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이다. 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다. (p.389)

 

실용주의 시작 도구

🟢  빌드와 릴리스 과정이건, 테스트나 프로젝트 서류 작업이건, 혹은 프로젝트에서 거듭 발생하는 다른 어떤 작업이건 간에 일상적인 작업은 모두 자동화해야 한다. 그래서 지원되는 모든 컴퓨터에서 반복 수행할 수 있어야 한다. (p.392)

🟢  프로젝트 차원에서는 버전 관리 시스템이 빌드와 릴리스 프로세스를 운용한다. (p.393)

🟢  버전 관리 시스템의 커밋이나 푸시로 빌드와 테스트, 배포가 시작된다. 빌드는 클라우드의 컨테이너 위에서 돌아간다. 테스트를 위해 스테이징 서버에 배포할지 실제 서비스에 릴리스할지는 버전 관리 시스템의 태그를 사용하여 지정한다. 릴리스 절차가 훨씬 더 간단해져서 일상의 일부가 된다. 빌드 장비나 개발자의 장비에 의존하니 않는 진정한 지속적 배포가 가능해진다. (p.394)

🟢  일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. (p.394)

🟢  테스트 코드를 만들기 위해 들이는 시간에는 그 노력만큼의 가치가 있다. 길게 보면 이쪽이 훨씬 더 싸게 먹히며, 결함이 거의 없는 제품을 만드는 꿈이 정말 이루어지기도 한다. 그에 더해서, 테스트를 통과했다는 것은 그 코드가 '완성'되었다는 말에 높은 수준의 확신을 준다. (p.395)

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

빌드 과정에는 소프트웨어 테스트의 몇 가지 주요 유형이 들어가야 한다. 단위 테스트, 통합 테스트, 유효성 평가 및 검증, 성능 테스트가 그것이다. 하지만 이것만 갖춘다고 절대 완벽한 것은 아니다. 몇몇 특별한 프로젝트에는 이 외에도 다른 종류의 테스트가 필요할 것이다. 하지만 이 목록은 훌륭한 출발점이 된다. (p.395)

단위 테스트

: 하나의 모듈을 테스트하는 코드다.

통합 테스트

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

유효성 평가와 검증

: 시스템의 기능적 요구 사항을 충족하는가? 이것 역시 테스트해 봐야 한다.

성능 테스트

: 성능 테스트 혹은 스트레스 테스트 역시 프로젝트의 중요한 측면이다.

테스트를 테스트하기

: 버그를 심어 놓고 테스트를 테스트하라.

철저한 테스트

: 커버리지 분석도구를 적용해 볼지도 모르겠다. 이런 도구들 덕에 여러분의 테스트가 얼마나 포괄적인지 대략적인 느낌은 얻을 수 있다. 하지만 100% 커버리지를 기대하지는 말라.

속성 기반 테스트

: 여러분의 코드가 예상치 못한 상태를 어떻게 다루는지 탐험하기 위해 컴퓨터가 그런 상태들을 생성하도록 하면 졸을 것이다.

그물 조이기

: 버그가 기존 테스트의 그물을 빠져나갔다면 다음번에는 그걸 잡아낼 수 있도록 새 테스트를 추가해야 한다. 버그는 한 번만 잡아라.

전체 자동화

: 모든 것이 자동화에 의존한다. 수작업 단계가 끼어 있다면 자동 배포를 할 수 없을 것이다. '딱 이거 하나만...'이라는 생각으로 수작업 단계를 넣는다면 아주 커다란 창문을 깨트리는 것이다.

 

사용자를 기쁘게 하라

🟢  모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다.

결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라.

이런 기대를 염두에 두고 사용자 여구 사항을 비판적으로 분석하라. 우리가 겪은 많은 프로젝트에서 명시된 '요구 사항'은 사실 기술로 무엇을 할 수 있는지 추측한 것일 뿐이었다. 요구 사항 문서의 형태를 띠었지만 실제로는 비전문가의 구현 계획이었던 것이다. 요구 사항을 바꾸면 프로젝트가 목표에 더 가까워진다는 것을 보여줄 수 있는가? 그렇다면 주저하지 말고 바꾸자고 제안하라.

프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.(p.403)

🟢  여러분의 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정한 여러분의 직함은 "문제 해결사"다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다.(p.404)

🟢  우리는 문제를 해결한다.(p.404)

 

오만과 편견

🟢  실용주의 프로그래머는 책임을 회피하지 않는다. 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다. 설계 혹은 코드를 맡는다면 자신이 보기에 자랑스러운 작품을 만들어 낼 것이다. (p.404)

 

 

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

✅  드디어 실용주의 프로그래머 책을 완독 하였다. 책을 읽으면서 확실히 다양한 면에서 공감이 가는 책이다.

✅  자신의 작품(코드)에 서명하는 날까지...

 

 

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

⭐️  번업 차트

전체 작업량과 완료한 작업량을 따로따로 표시한다. 마일스톤을 완료했을 때 전체 작업량과 완료한 작업량이 만난다.

⭐️  번 다운 차트

마일스톤까지 남은 작업의 양을 표시한다. 마일스톤을 완료했을 때 남은 작업량 그래프가 X축과 만난다.