실용주의 프로그래머 #19일차

 

🧑🏻‍💻 오늘 TIL 3줄 요약

 

• 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.

 

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

 

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

 

 

TIL (Today I Learned)

 

• 2022. 4. 5.

 

📕 오늘 읽은 범위

 

• 9장. 실용주의 프로젝트

 

🙂 책에서 기억하고 싶은 내용

 

Topic 49. 실용주의 팀 _p.378

 

• Tip 84. 작고 안정적인 팀을 유지하라.

 

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

 

• 모든 사람이 적극적으로 환경 변화를 감시하도록 권장 하라. 범위scope의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다. 

 

• Tip 85. 실현하려면 계획하라.

 

• 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다.

 

• 이 말은 작 업에 필요한 기술을 팀 안에 모두 갖추어야 한다는 뜻이다. 프론트엔드, UI/ UX, 서버, DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다.

 

• Tip 86. 모든 기능을 갖춘 팀을 조직하라.

 

• 자동화는 모든 프로젝트 팀에게 필수 불가결한 요소다. 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만 들고 적용하라.

 

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

 

• 특정한 개발 방법이나 프레임워크, 테스트 기법을 굳이 사용하는 이유가 무 엇인가? 정말로 지금 하는 일에 잘 맞아서인가, 자신에게 잘 맞아서인가? 아 니면 그저 최근에 인터넷에서 회자된 성공 사례에서 사용했기 때문에 도입한 것인가?

 

• Tip 87. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.

 

• 그러니 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다. 만병통치약은 없고, 현재의 방법론들도 아직 완성되려면 멀 었다. 그러니 인기 있는 방법론 하나만 좇지 말고, 다른 것들로도 눈길을 돌 려야 한다.

 

• Tip 88. 사용자에게 필요할 때 제공하라.

 

• 초심 자라면 프로젝트 관리는 스크럼으로 시작하고, 익스트림 프로그래밍XP의 기 술 실천 방법을 추가로 도입할 수 있다. 더 경험이 많고 단련된 팀이라면 칸 반Kanban이나린Lean 기법을살펴볼수있다.둘다팀혹은더큰조직관리문 제를 다루기 좋다.

 

Topic 51. 실용주의 시작 도구

 

• Tip 89. 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.

 

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

 

• Tip 90. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.

 

• 사실, 훌륭한 프로젝트에는 제품 코드보다 테스트 코드가 더 많을 수도 있 다. 테스트 코드를 만들기 위해 들이는 시간에는 그 노력만큼의 가치가 있 다. 길게 보면 이쪽이 훨씬 더 싸게 먹히며, 결함이 거의 없는 제품을 만드는 꿈이 정말 이루어지기도 한다.

 

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

 

• 성능테스트
  소프트웨어가 실세계 조건에서 성능 요구 사항들을 준수하는지 자문해 보 라. 예상하는 사용자 수나 접속 수 혹은 초당 트랜잭션 숫자를 염두에 두고 말이다. 감당 가능한가?
  어떤 애플리케이션은 부하를 현실적으로 시뮬레이션하기 위해 특화된 테 스트용 하드웨어나 소프트웨어가 필요할 수도 있다.

•  Tip 92. 버그를 심어 놓고 테스트를 테스트하라.

 

• Tip 93. 코드 커버리지만 올리지 말고 상태 조합을 테스트하라.

 

• Tip 94. 버그는 한 번만 잡아라.

 

• Tip 95. 수작업 절차를 사용하지 말라.

 

Topic 52. 사용자를 기쁘게 하라

 

• 개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다.

 

• Tip 96. 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라.

 

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

 

Topic 53. 오만과 편견

 

• Tip 97. 자신의 작품에 서명하라.

 

• 경계심 때문에 여러분의 코드를 참견하 는 사람으로부터 방어하려고 해서는 안 된다. 같은 맥락에서, 다른 사람의 코 드를 존중해야 한다. 이 팁이 효과를 보려면 개발자 사이에 황금률(“남에게 대접 받고자 하는 대로 너희도 남에게 대접하라.”)과 상호 존중이라는 기반이 꼭 필요하다.

 

• 우리는 소유권에 대한 긍지pride를 보고 싶다. “내가 이걸 만들었고, 내 작품 의 품질을 보증합니다.” 여러분의 서명이 품질의 보증 수표로 인식되게 해야 한다.

 

 

🤔 오늘 읽은 소감은?

 

• 드디어 책의 마지막 장 '실용주의 프로젝트'를 끝으로 실용주의 프로그래머 책이 마무리 되었다. 마지막 장은 프로젝트에 임하는 프로그래머의 자세를 보여주고, 프로그래머 업무의 본질과 본인 업무에 대한 자긍심을 강조하면서 마무리 하고있다. 어렵고 이해안가는 부분들도 있고, 아마 다회차가 되어서야 보이는 부분들도 있을 것이다. 하지만 이 책은 개발 업무를 하는 사람들이 무언가로 인해 답답함을 느꼈다면, 시원한 소화제 역할을 해줄 수 있을 것이다. 주변 개발 현업에 종사하는 분들께 한번 읽어볼 것을 적극 추천드린다.