📚노마드 개발자 북클럽 '실용주의 프로그래머'(1기) 과제#15

📌 ASSIGNMENT 15. 22.04.05 TUE

 

📎 오늘 TIL 3줄 요약

• 실용주의 팀은 소규모로 서로에 대한 신뢰가 있어야 한다. 책에서 알려주었던 팁들을 내제시켜야 한다.
• 버전관리, 회귀 테스트, 자동화는 프로그래머에게 기반이 되어준다.
• 우리는 문제를 해결한다.

 

🔖 오늘 읽은 범위

9장. 실용주의 접근법

 

 

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

• 소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것.
• 실용주의 팀
  • 실용주의 팀은 작다. 구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고 신뢰하며, 의존해야 한다.
  • 깨진 창문을 없애라 - 팀 전체가 깨진 창문을 용납하지 않아야 한다. 사소한 결점을 아무도 고치지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다. 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다.
  • 삶은 개구리 - 팀은 개인보다 더 삶은 개구리가 되기 쉽다. 사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요청한 변경 사항을 팀 리더가 이미 동의 했겠거니 하고 여긴다. 제아무리 좋은 뜻을 가진 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에는 둔감할 수도 있다. 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. 범위(scope)의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다. 새 요구사항에 대한 수치를 관리하라.
  • 여러분의 지식 포트폴리오를 계획하라 - 성공을 원하는 팀이라면 마찬가지로 자신들의 지식과 기술에 투자하는 것을 고려해야 한다. 여러분의 팀이 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다. "시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다"는 것이다. 새로운 기술이나 프레임워크, 라이브러리를 그저 "다들 쓰니까"라는 이유로, 또는 콘퍼런스에서 본 것이나 인터넷에서 읽은 글을 바탕으로 도입하지 말라. 후보 기술로 프로토타입을 만들어 보고 신중하게 조사하라.
  • 팀의 존재를 소통하라 - 훌륭한 프로젝트팀은 뚜렷한 특성이 있다. 사람들은 이 팀과의 회의를 기대한다. 모든 사람이 좋아할 만한 잘 준비된 퍼포먼스를 보게 될 걸 알기 때문이다. 이들이 생산해 내는 문서는 깔끔하고 정확하며 일관적이다. 팀은 한 목소리로 이야기한다. 팀에 유별난 이름을 지어주면 팀은 정체성 확립의 기반을 얻을 것이고, 세상은 여러분의 작업과 관련해서 기억할 만한 뭔가를 얻게 될 것이다.
  • 반복하지 말라
  • 팀 예광탄 - '예광탄'을 사용하여, 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 잇는 단일 기능을 개발할 것을 추천한다. 이 말은 작업에 필요한 기술을 팀 안에 모두 갖추어야 한다는 뜻이다. 프론트엔드, UI/UX, 서버, DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다.
  • 자동화 - 자동화는 모든 프로젝트 팀에게 필수 불가결한 요소다. 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라.
  • 멈춰야 할 때를 알라
• 화물 숭배의 함정은 너무 솔깃해서 빠지기 쉽다. 눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망한다.
• 특정한 개발 방법이나 프레임워크, 테스트 기법을 굳이 사용하는 이유가 무엇인가? 정말로 지금 하는 일에 잘 맞아서인가, 자신에게 잘 맞아서인가? 아니면 그저 최근에 인터넷에서 회자된 성공 사례에서 사용했기 때문에 도입한 것인가?
• SW 개발의 진짜 목표 : 작동하는 소프트웨어를 제공함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것.
• 프로그래머를 위한 시작 도구(Pragmatic Starter Kit)
  • 버전 관리
    • 프로젝트를 빌드하는데 필요한 모든 것을 버전 관리하에 두어야 한다.
    • 프로젝트 차원에서는 버전 관리 시스템이 빌드와 릴리스 프로세스를 운용한다.
  • 회귀 테스트
    • 많은 개발자들이 무의식적으로 코드가 어디에서 깨지는지 파악하고서는 약한 지점을 피해 다니면서 살살 테스트하려 한다. 실용주의 프로그래머들은 지금 당장 버그를 찾아 나서도록 자신을 몰아세우지만, 덕분에 나중에 다른 사람이 자기 버그를 발견하게 되는 딱한 상황을 피할 수 있다.
    • 코드를 작성하자마자 테스트해야 한다.
    • 단위 테스트
      • 하나의 모듈을 테스트하는 코드
      • 다음 단계로 넘어가기 전 여러분이 사용하는 모든 모듈의 단위 테스트가 반드시 통과해야 한다.
    • 통합 테스트
      • 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다.
      • 시스템에서 버그가 가장 많이 나오는 부분은 모듈을 통합하는 부분
      • 단위 테스트의 확장에 지나지 않고 전체 서브시스템들이 모두 계약을 제대로 지키는지 테스트하는 것뿐.
    • 유효성 평가 및 검증
      • Q. 사용자들이 필요한 것을 이야기해 주긴 했지만, 그게 정말 사용자들이 필요로 하는 것인가?
      • Q. 시스템의 기능적 요구 사항을 충족하는가?
    • 성능 테스트
    • 테스트를 테스트하기
    • 철저한 테스트
      • 커버리지 분석 도구 - 테스트 중에 코드를 지켜보면서 코드의 어느 줄이 실행되지 않았는지 알려준다.
  • 전체 자동화
    • 수작업 절차를 사용하지 말라.
• 여러분의 직함이 명목상으로는 '소프트웨어 개발자'나 '소프트웨어 엔지니어' 비슷한 이름일지 몰라도 진정한 여러분의 직함은 '문제 해결사'다. 우리는 문제를 해결한다.
• 실용주의 프로그래머는 책임을 회피하지 않는다. 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다.

 

💬 오늘 소감은? 떠오르는 소감을 간단하게 적어보세요

1-8장에서 소개되었던 수많은 팁들을 일목요연하게 정리해둔 챕터였다. 실용주의 팀을 만들고 팀의 구성원으로써 난 어떻게 행동해야 하는지 다시 한번 알게 되었다. 또 내가 개발 도구를 선택함에 있어 고집이 있다면 그 이유를 고민해봐야겠다는 생각도 했다.

챕터의 마지막 부분에서 전 회사에서 팀장님이 우리의 역할은 '해결사'라고 종종 말을 했었던게 떠올랐다.

책을 드디어 완독했다. 솔직히 흥미있는 분야보다는 좀 재미가 없고 두꺼워서 혼자라면 시작도 안하거나 도중에 그만뒀을텐데 챌린지로 다같이 도전하고 매일 분량이 주어지니 쉽게 완주할 수 있었다. 개발자 추천 도서 중 손가락에 꼽히는 책을 읽은 것에 대해 자부심이 생긴다😤 책에 나온 팁들을 내 것으로 소화하고 실천할 수 있도록 노력해야겠다.