Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
9장 실용주의 프로젝트
#pragmatic
2년 전
1,120
1

오늘 TIL 3줄 요약

  • 팀 동료와 즉각적으로 소통할 수 있어야 한다

  • 가차없고 지속적인 테스트

  • 코트에는 주인이 있어야 하지만 꼭 개인일 필요는없다

책에서 기억하고 싶은 내용

49. 실용주의 팀

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

    • 실용주의 팀은 작다. 구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고, 신뢰하며, 의존해야한다.

  • 깨진 창문을 없애라

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

  • 삶은 개구리

    • 팀은 개인보다 더 삶은 개구리가 되기 쉽다. 사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요청한 변경 사항을 팀 리더가 이미 동의 했겠거니 생각하거나, 제아무리 좋은 뜻을 가진 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에는 둔감할 수도 있다. 이에 맞서야 한다. 늘 깨어서 의식해야 한다.

  • 지식 포트폴리오를 계획하라

    • 구형 시스템 유지 보수

    • 프로세스 회고와 개선

    • 새로운 기술 탐험

    • 학습 및 기술 갈고 닦기

  • 팀의 존재를 소통하라

    • 팀이라는 것 역시 더 큰 조직의 일부라는 사실을 잊어버리기 쉽다. 팀도 나머지 세상과 명확하게 의사소통해야 하는 존재다.

  • 반복하지 말라

    • 좋은 의사소통이 중복을 피하는 핵심이다. 여기서 ‘좋은'이란 즉각적이고 매끄러운 것을 말한다. 여러분은 팀 동료에게 질문을 하고 거의 즉각적으로 답을 받을 수 있어야 한다. DRY를 지키려면 서로 관심을 유지하라.

  • 팀 예광탄

    • 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발하는 것을 추천한다. 처음에는 아무리 작고 제한적인 기능밖에 만들지 못하더라도 말이다.

    • 그러기 위해서는 모든 기능을 갖춘 팀을 조직하라

  • 자동화

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

  • 멈춰야 할 때를 알라

    • 팀은 개인들로 이루어진다는 사실을 명심하라. 각 팀원이 자신의 방식대로 빛나게 하라.

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

‘화물 숭배(cargo cult)’ 눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망한다.

  • 맥락의 중요성

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

  • 만병통치약은 아무 병도 못 고친다

    • 소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이다. 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다. 현재의 방법론들도 아직 완성되려면 멀었다. 그러니 인기있는 방법론 하나만 좇지 말고, 다른 것들로도 눈길을 돌려야 한다.

  • 진짜 목표

    • 진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다.

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

51. 실용주의 시작 도구

  • 버전 관리로 운용하라

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

  • 가차 없고 지속적인 테스트

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

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

    • 단위 테스트

    • 통합 테스트

    • 유효성 평가 및 검증

    • 성능 테스트

    • 테스트를 테스트하기 - 버그를 심어 놓고 테스트를 테스트하라

    • 철저한 테스트 - 상태 조합을 테스트하라

    • 속성 기반 테스트

  • 그물 조이기

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

  • 전체 자동화

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

52. 사용자를 기쁘게 하라

여러분의 사용자가 진짜로 원하는 것은 코드가 아니다. 그들에겐 자신의 목적과 예산에 맞추어 풀어야 하는 사업상의 문제가 있다. 그리고 여러분의 팀과 일하면서 문제를 풀어낼 수 있으리라 믿는다.

53. 오만과 편견

  • 자신의 작품에 서명하라

    • 익명성은 큰 프로젝트에서 적당주의나 실수, 태만, 나쁜 코드의 온상이 될 수 있다.

    • 코드에는 주인이 있어야 하지만 꼭 개인일 필요는 없다.

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

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

벌써 마지막 장이 온 챌린지..중간에 아쉽게 몇번 결석했지만 하루하루 도장깨는 마음이어서 재미있었고, 또 배우는 시간이었던것 같다. 비전공자로 대충 교육받고 대충 작은 회사에 던져졌을때도, 버거운 마음에 늘 자신감이 없었고 내가 잘 할수있을지 의심의 연속이었는데, 그래도 어느덧 조금씩 자라서 이거저거 시도해보고 또 여러 커뮤니티를 보면서 자라고, 유튜브 덕분에 니꼬샘도 알게됐고, 이런 챌린지도 하게되고..🥹

여전히 나는 계속 자라야하지만, 이번 챌린지와 클린코드 챌린지로 정말 많은 정리가 된것 같다. 일단 개발하는 태도와 마음가짐도 정리가 됐고, 협업을 하면서 그리고 코드를 만들어가면서 지켜야 할것들을 알게 된게 크다. 프로토타입보다 예광탄으로 시작을 해야한다는거, 우리는 글을 쓰듯 코드를 써야한다는거. 누구나 코드로만 의사소통이 될 수 있도록. 테스트 도구를 사용해 본적이 없지만 테스트 코드가 무엇보다 중요하다는거!

이번 장에서 인상깊었던 부분은 앞으로 어떤 프로젝트간에, 코드에 대한 긍지를 나타내도록 작품에 서명하듯 코드에 서명해야겠는거. 뭐 잘못된게 있다면 계속 피드백 받고 수정하면 된다. 좋지 못한 코드더라도 내가 만들었음을 숨기지 말자. 그리고 누군가의 피드백을 반갑게 생각할것.

이번 챌린지도 많이 배운만큼 머리에서 휘발되지 않도록 짧게라도 정리한거 수욱 훑어봐야지!

함께 한 모두들 고생많으셨고 즐거웠습니다👍🏻

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

오늘 읽은 다른사람의 TIL

1 comment