Pragmatic TIL - 11 (2022-04-06)

오늘 TIL 3줄 요약

 

• 소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것!
• 모든 프로젝트에서 후원자를 어떻게 기쁘게 하는지!
• 자신의 작업에 자부심을 갖고 여러분의 서명을 남겨라!

 

TIL (Today I Learned) 날짜

 

2022. 04. 06

 

오늘 읽은 범위

 

9장. 실용주의 프로젝트

 

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

 

• 작고 안정적인 팀을 유지하라. 모두가 서로 잘 알고 신뢰하며 의존해야 한다. - page.379
• 팀 전체가 깨진 창문을 용납하지 않아야 한다. 사소한 결점을 아무도 고치지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다. - page.379
• 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. 새 요구 사항에 대한 수치를 관리하라. - page.380
• 성공을 원하는 팀이라면 자신들의 지식과 기술에 투자하는 것을 고려해야 한다. 팀이 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다.
  
  "시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다"는 것이다.
  
  1. 구형 시스템 유지 보수
  2. 프로세스 회고와 개선
  3. 새로운 기술 탐험
  4. 학습 및 기술 갈고닦기
  
  실현하려면 계획하라. - page.382
• 팀의 존재를 소통하라. 팀이 하나로 의사소통하게 도와주는 간단한 마케팅 비결이 있다. 프로젝트를 시작할 때 이름을 지어주는 것이다. (유별난 이름이면 더 좋다) 또한 30분 정도 투자해서 괴짜스러운 로고를 만들어 사용해라. 팀은 정체성 확립의 기반을 얻을 것이고, 세상은 여러분의 작업과 관련해서 기억할 만한 뭔가를 얻게 될 것이다. - page.383
• 좋은 의사소통이란 즉각적이고 매끄러운 것을 의미한다. 여러분은 팀 동료에게 질문을 하고 거의 즉각적으로 답을 받을 수 있어야 한다. DRY를 지키려면 서로 관심을 유지하라. - page.383
• 프런트 앤드, UI/UX, 서버, DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다. 모든 기능을 갖춘 팀을 조직하라. - page.384~385
• 자동화는 모든 프로젝트 팀에게 필수 부 가결한 요소다. 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라. - page.385
• 팀은 개인들로 이루어진다는 사실을 명심하라. 각 팀원이 자신의 방식대로 빛나게 하라. 그리고 프로젝트가 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라. - page.385
• 이 특정한 개발 방법이나 프레임워크, 테스트 기법을 굳이 사용하는 이유가 무엇인가? 정말로 지금 하는 일에 잘 맞아서인가, 자신에게 잘 맞아서인가? 아니면 그저 최근에 인터넷에서 회자된 성공 사례에서 사용했기 때문에 도입한 것인가? 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라. - page.388
• 진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다. 사용자가 필요로 할 때마다, 사업적으로 배포가 있을 때마다 배포하라.
  사용자에게 필요할 때 제공하라. 또한 버전 관리 시스템의 기능 브랜치가 아니라 주 브랜치 혹은 트렁크에서 개발해야 한다. 그리고 사용자에게 선택적으로 시범적 기능을 공개할 때는 '기능 스위치' 같은 기법을 활용하라. - page.390~391
• 버전 관리 , 회귀 테스트 , 전체 자동화. 이 셋은 모든 프로젝트를 지탱하는 기둥이다.
  
  버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.
  
  일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
  모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.
  
  단위 테스트는 하나의 모듈을 테스트하는 코드이다. 다음 단계로 넘어가기 전 여러분이 사용하는 모든 모듈의 단위 테스트가 반드시 통과해야 한다.
  
  통합 테스트는 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다. 이것은 전체 서브 시스템들이 모두 계약을 제대로 지키는지 테스트하는 것뿐이다.
  
  성능 테스트 혹은 스트레스 테스트 역시 프로젝트의 중요한 측면이다. 예상하는 사용자 수나 접속 수 혹은 초당 트랜잭션 숫자를 염두에 두고 테스트해야 한다.
  
  버그를 심어놓고 테스트를 테스트하라.
  
  철저한 테스트로 프로그램의 모든 가능한 상태를 확인해야 한다. 단순히 코드 커버리지만 올리지 말고 상태 조합을 테스트하라.
  
  버그가 기존 테스트의 그물을 빠져나갔다면 다음번에는 그걸 잡아낼 수 있도록 새 테스트를 추가해야 한다. 버그는 한 번만 잡아라.
  
  전체 자동화를 통해 수작업 절차를 사용하지 말라.
  
  모든 것이 자동화에 의존한다. 빌드 전체가 자동화되어 있지 않다면 임의의 클라우드 서버에서 프로젝트를 빌드할 수 없을 것이다. - page. 393~401
• 개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다. 여러분의 사용자가 진짜로 원하는 것은 코드가 아니다. 그들에겐 자신의 목적과 예산에 맞추어 풀어야 하는 사업상의 문제가 있다. 그리고 여러분의 팀과 일하면서 문제를 풀어낼 수 있으리라 믿는다.
  
  사용자를 기쁘게 하라. 그저 코드만 내놓지 말라.
  
  여러분의 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정한 여러분의 직함은 "문제 해결사"다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다. 우리는 문제를 해결한다. - page.402~404
• 자신의 작품에 서명하라. 사람들이 코드에 붙은 여러분의 이름을 보고 그것이 튼튼하고 잘 작성되었으며 제대로 테스트되었을 뿐 아니라 훌륭히 문서화되었을 것이라고 기대하도록 만들자. 전문가가 만든 진정으로 전문가다운 결과물. - page.404~406

 

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

 

• 그동안 책을 보면서 계속 강조해왔던 것들이 쌓이고 쌓여 9장에서 모든 것을 설명해준 느낌이다. 책을 보면서 제대로 일할 줄 아는 전문가로서 성장하고 싶다는 생각이 들었었고 이 책을 읽으며 한 번에 모든 것을 적용할 수는 없겠지만 그토록 강조해온 테스트를 프로젝트에서 꼭 적용해 보아야겠다는 생각이 들었으니 책을 읽고 성장한 점 중 하나이다.
• 글쓴이가 굉장히 멋있는 개발자라는 생각이 들었다. 30년간 테스트를 해온 장인으로서 본받아야겠다고 생각이 들고 이러한 책을 내어서 한국에서 사는 나에게도 영향을 미치는 글쓴이를 보고 대단하다고 느끼고 나도 지식을 쌓고 공유하는 경험을 갖고 싶다는 생각을 했다.

 

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

 

• 기능 스위치가 무엇일까 궁금해서 구글링을 한국어로 해보니 검색이 잘 안 되는 것 같아 영어로 할 생각입니다.

 

오늘 읽은 다른 사람의 TIL

 

• dv3 tp53 fm 님의 TIL (url 링크)