개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
나, 팀, 그리고 사용자가 사용하는 결과물 함께 성장시키자
개발자로써 우리의 목표는 사용자를 기쁘게 하는 것이다. 나는 과연 "문제 해결사" 직함에 어울리는가?
전문가가 만든 진정으로 전문가 다운 결과물을 만들자
"내가 이걸 만들었고, 내 작품의 품질을 보증합니다."
TIL (Today I Learned) 날짜
2022.04.05
오늘 읽은 범위
9장. 실용주의 프로젝트
책에서 기억하고 싶은 내용을 써보세요.
프로젝트의 성패를 좌우하는 핵심적인 부분 몇 가지
프로젝트에 참여하는 사람이 복수가 되면 기본적인 규칙 몇 가지를 정립하고 그에 따라 프로젝트의 각 부분을 위임해야 한다. 실용주의 철학을 살리면서 이를 어떻게 이룰 수 있는지를 설명
-> 항목 49. 실용주의 팀소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이다.
소프트웨어 개발 방법론들을 이용하여 프로젝트 성공의 진정한 비법을 설명
-> 항목 50. 코코넛만으로는 부족하다안정적인 소프르퉤어를 지속적으로 생산해 내지 못한다면 방법론은 아무 의미가 없다.
버전 관리, 테스트, 자동화 이 세가지 기반에 대해서 설명
-> 항목 51. 실용주의 시작 도구프로젝트는 후원자의 눈에 들어야 성공이다. 결국 중요한 것은 결과가 성공인지 여부
-> 항목 52. 사용자를 기쁘게 하라자신의 작업에 자부심을 갖고 여러분의 서명을 남기라고 요청
-> 항목 53. 오만과 편견(pride and prejudice)
실용주의 팀
프로그래머는 고양이 같은 면이 있다. 호기심 많고 제멋대로이며, 고집이 세고, 독립접인 데다, 가끔은 인터넷에서 숭배를 받기도 한다.
팀이라는 측면에서 '깨진 창문을 없애라' 다시 보기
팀 전체가 깨진 창문을 용납하기 않아야 한다.
사소한 결점을 아무도 고치지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다.
'깨진 창문을 없애라' 철학을 이해하는 개발자들을 지원하고, 그렇지 못한 개발자들은 이해하도록 독려하는 팀을 만들어라
몇몇 팀 방법론에 있는 '품질 관리 담당자' 가 제품의 품질에 대한 책임을 팀에게서 위임받는 것은 생각해봐야 할 문제다. 왜냐하면 품질은 팀원 모두가 제각기 기여할 때만 보장되기 때문이다.
품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다.
팀이라는 측면에서 '삶은 개구기' 다시 보기
팀은 개인보다 더 삶은 개구리가 되기 쉽다.
제아무리 좋은 뜻을 가진 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에는 둔감할 수도 있다.
-> 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라!범위(scope)의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다.
이미 일어난 변화를 거부할 필요는 없다. 단지 그런일이 벌어지고 있다는 것을 파악하고 있으면 된다.
팀이라는 측면에서 '여러분의 지식 포트폴리오를 계획하라' 다시 보기
새로운 기능을 만드는 것 외에도 해야 할 일들이 있다.
구형 시스템 유지 보수
프로세스 회고와 개선
: 지속적인 개선이 일어나려면 주위를 둘러보고 무엇이 잘되고 무엇이 잘되지 않았는지 확인한 다음 변화를 일으킬 시간이 있어야 한다.새로운 기술 탐험
: 새로운 것을 시도해 보고 결과를 분석하는 업무를 일정표에 추가하라학습 및 기술 갈고 닦기
: 많은 기술이 팀 전체로 퍼졌을 때 더 효과적이다.
실현하려면 계획하라!
팀이라는 측면에서 '팀의 존재를 소통하라' 다시 보기
팀도 나머지 세상과 명확하게 의사소통해야 하는 존재다
외부 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트팀이야말로 최악이다.
: 문서마다 생김새도 제각각이고, 서로 다른 용어를 사용하는 팀훌륭한 프로젝트 팀
: 문서는 깔끔하고 정확하며 일관적이다. 팀은 한 목소리로 이야기 한다.팀이 하나로 의사소통하게 도와주는 간단한 마케팅 비결
-> 프로젝트를 시작할 때 이름을 지어 주는 것. 유별난 이름이라면 더 좋음
: 바보같이 들리겠지만 팀은 정체성 확립의 기반을 얻을 것이고 세상은 여러분의 작업과 관련해서 기억할 만한 뭔가를 얻게 될 것이다.
팀이라는 측면에서 '반복하지 말라' 다시 보기
중복된 일은 노력을 무위로 돌릴뿐 아니라 결국 유지 보수를 악몽으로 만들 수도 있다.
칸칸이 분리된 '연통(stovepipe)형' 혹은 '사일로형' 시스템이 이런 팀들의 모습.
이런 팀에서는 공유되는 것이 거의 없고, 중복된 기능은 아주 많다.좋은 의사소통이 이런 문제를 피하는 핵심이다. 여기서 "좋은"이란 즉각적이고 매끄러운 것을 말한다.
-> 여러분은 팀 동료에게 질문을 하고 거의 즉각적으로 답을 받을 수 있어야 한다.매끄럽다는 것은 질문하기, 진행 상황이나 문제, 통찰 및 새롭게 알게 된 점을 공유하기, 또 동료가 뭘 하고 있는지 알고 있기가 쉽고 거추장스러운 단계가 적다(low ceremony)는 뜻이다.
DRY를 지키려면 서로 관심을 유지하라
팀이라는 측면에서 '팀 예광탄' 다시 보기
처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다.
-> 작업에 필요한 기술을 팀 안에 모두 갖추어야 한다는 뜻이다.프론트엔드, UI/UX, 서버, DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다.
코드를 끝에서 끝까지 점진적이고 반복적으로 쌓아 올릴 수 있는 팀을 만들어라
모든 기능을 갖춘 팀을 조직하라!
팀이라는 측면에서 '자동화' 다시 보기
자동화는 모든 프로젝트 팀에게 필수 불가결한 요소다. 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라.
팀이라는 측면에서 '멈춰야 할 때를 알라' 다시 보기
팀은 개인들로 이루어진다는 사실을 명심하라. 각 팀원이 자신의 방식대로 빛나게 하라. 팀원들을 지원하기에, 그리고 프로젝트가 가치를 만들어 내기에 딱 좋을 만틈의 구조를 제공하라.
코코넛만으로는 부족하다
화물 숭배의 함정은 너무나 솔깃해서 빠지기 쉽다.
눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망한다.아래의 것들을 나 그리고 나의 팀에 자문해보자
특정한 개발 방법이나 프레임워크, 테스트 기법을 굳이 사용하는 이유가 무엇인가?
정말로 지금 하는 일에 잘 맞아서인가?
자신에게 잘 맞아서인가?
그저 최근에 인터넷에서 회자된 성공 사례에서 사용했기 때문에 도입한 것인가?
속아 넘어가지 말라. 특정한 결과물, 피상적인 구조나 정책, 프로세스, 방법론만으로는 부족하다
-> 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라!"잘 맞는 것"을 어떻게 알 수 있을까?
: 가장 근본적인 실용주의 기법을 적용하면 된다.
직은 팀 하나나 조직 하나에서 아이디어를 시험해 보라.
잘 맏는 것 같은 좋은 부분만 유지하고 나머지는 낭비나 비용일 뿐이므로 버리면 된다.소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이다.
기존의 규칙 너머를 보고 개선의 여지를 찾아내는 능력이 필요하다.
어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다. 만병통치약은 없고, 현재의 방법론들도 아직 완성되려면 멀었다. 그러니 인기 있는 방법론 하나만 좇지 말고, 다른 것들로도 눈길을 돌려야 한다.
진짜 목표는 당연히 "스크럼을 한다"나 "애자일을 한다", "린을 한다" 같은 종류가 아니다.
-> 진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다.필요할 때마다 출시한다는 것
-> 끊임없이 1분에 한 번씩 배포한다는 뜻이 아니라, 사용자가 필요로 할 때마다, 사업적으로 배포가 의미 있을 때마다 배포하는 것이다.
-> 사용자에게 필요할 때 제공하라!지속적 개발을 도입하려면 매우 견고한 기반 구조(infrastructure)가 필요
: 버전 관리 시스템의 기능(feature)브랜치가 아니라 주(main)브랜치 - 혹은 트렁크(trunk) - 에서 개발해야 한다. 그리고 사용자에게 선택적으로 시범적 기능을 공개할 때는 '기능 스위치' 같은 기법을 활용하라특정 방법론에 과도하게 투자하면 다른 대안을 보지 못하게 될 수도 있다. 하나에 고착되면 머지않아 다른 길을 보기 어렵게 된다. 한 가지 방식이 너무 굳어져 버리면 더 이상 빠르게 적응할 수 없게 된다.
실용주의 시작 도구
빌드와 릴리스 과정이건, 테스트나 프로젝트 서류 작업이건, 혹은 프로젝트에서 거듭 발생하는 다른 어떤 작업이건 간에 일상적인 작업은 모두 자동화해야 한다.
게다가 우리는 프로젝트에서 일관성과 반복 가능성을 확보하고 싶다.
수작업은 일관성을 운에 맡긴다. 반복 가능성도 보장받디 못한다. 특히 그 작업 절차를 여러 사람이 서로 다르게 해석할 여지가 있다면 더 그렇다.
방법론이나 언어, 기술 스택에 상관없이 모든 팀에게 필요한 가장 기본적이고 중요한 요소 세 가지
버전 관리
회귀 테스트
전체 자동화
버전 관리로 운용하라
프로젝트를 빌드하는데 필요한 모든 것을 버전 관리하에 두어야 한다.
프로젝트 차원에서는 버전 관리 시스템이 빌드와 릴리스 프로세스를 운용한다.
-> 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라!
가차 없고 지속적인 테스트
버그 찾기는 그물 낚시와 비슷하다. 잔챙이를 잡기 위해 촘촘한 그물(단위테스트)을 쓰기도 하고, 식인 상어를 잡기 위해 크고 성긴 그물(통합테스트)을 쓰기도 한다.
일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라!
: 코드를 작성하자마자 테스트해야 한다.모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다!
: 테스트를 통과했다는 것은 그 코드가 '완성'되었다는 말에 높은 수준의 확신을 준다.자동 빌드가 모든 가용한 테스트를 수행한다. "진짜 상황 테스트"를 목표로 하는 것이 중요하다. 즉, 테스트 환경은 실제 환경과 최대한 비슷해야 한다.
빌드 과정 들어가야 하는 소프트웨어 테스트의 몇 가지 주요 유형
단위 테스트
: '단위 테스트'는 하나의 모듈을 테스트하는 코드다.
부분으로 떼어 놓았을 때 제대로 작동하지 않는다면 합쳤을 때도 역시 제대로 작동하지 않을 것이다.통합 테스트
: '통합 테스트(integration test)'는 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다.유효성 평가 및 검증
: 시스템의 기능적 요구 사항을 충족하는가? 이것 역시 테스트해 봐야 한다.성능 테스트
: 성능(performance)테스트 혹은 스트레스 테스트
예상하는 사용자 수나 접속 수 혹은 초당 트렌젝션 숫자등의 성능 요구 사항들을 준수하는지
버그를 심어 놓고 테스트를 테스트하라!
-> 정말 진지하게 테스트해 보고 싶다면 소스 트리에서 별도의 브랜치를 하나 만든 다음 고의로 버그를 심어 놓고 테스트가 잡아내는지 검증하라. 테스트를 작성할 땐 경보가 필요할 때 정말 울리는지 확인하라.테스트하려는 코드의 계약과 불변식에 따라 테스트 데이터를 생성하는 '속성 기반' 테스트 기법을 사용하라
버그는 한 번만 잡아라!
-> 한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만다서는 안 된다. 그 순간 이후로는 무조건, 매번, 예외 없이, 아무리 사소해도, 개발자가 "그런 상황은 절대 또 일어날 리 없습니다." 라고 불평을 하더라고, 해당 버그를 확인할 수 있게 자동화 테스트를 수정해야 한다.수작업 절차를 사용하지 말라!
-> 사람들은 컴퓨터처럼 같은 일을 반복할 수 없을뿐더러 그런 것을 기대해서도 안 된다.
모든 것이 자동화에 의존한다. 빌드 전체가 자동화되어 있지 않다면 임의의 클라우드 서버에서 프로젝트를 빌드할 수 없을 것이다. 수작업 단계가 끼어 있다면 자동 배포를 할 수 없을 것이다.
'딱 이거 하나만.....' 이라는 생각으로 수작업 단계를 넣는다면 아주 커다란 창문을 깨트리는 것이다.
사용자를 기쁘게 하라
개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다.
"이 프로젝트가 끝나고 한 달(혹은 일 년이라든지)후에 우리가 성공했는지 어떻게 알 수 있을까요?"
: 어떻게 사용자들이 기대하는 것을 밝혀낼 수 있을지를 찾기위해 위와 같은 질문을 던져라소프트웨어 프로젝트 자체가 아니라 이런 성공 척도가 진짜로 의미 있는 사업 가치다. 소프트웨어는 이런 목적을 달성하기 위한 수단일 뿐이다.
제품 추천을 개선하는 프로젝트라도 실제로는 고객 잔존율로 성공을 판단할 수 있다
두 데이터베이스를 통합하는 프로젝트는 데이터의 품질로 판단하거나 절감한 비용으로 판단
숨겨져 있던 프로젝트 배후의 가치에 대해 사용자가 기대하는 바의 일부가 수면 위로 올라 왔다면, 비로소 이런 기대를 어떻게 충족시킬 수 있을지 고민을 시작할 수 있다.
모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다.
결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라
이런 기대를 염두에 두고 사용자 요구 사항을 비판적으로 분석하라.
우리가 겪은 많은 프로젝트에서 명시된 '요구 사항'은 사실 기술로 무엇을 할 수 있는지 추측한 것일 뿐이었다. 요구 사항 문서의 형태를 띠었지만 실제로는 비전문가의 구현 계획이었던 것이다. 요구 사항을 바꾸면 프로젝트가 목표에 더 가까워진다는 것을 보여줄 수 있는가? 그렇다면 주저하지 말고 바꾸자고 제안하라.프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.
사용자를 기쁘게 하라. 그저 코드만 내놓지 말라!
-> 여러분의 고객을 기쁘게 하고 싶다면 고객이 문제를 풀 때 적극적으로 도와 줄 수 있는 관계를 구축하라.여러분의 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정한 여러분의 직함은 "문제 해결사"다.
오만과 편견
실용주의 프로그래머는 책임을 회피하지 않는다. 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다.
자신의 작품에 서명하라!
-> 옛 장인들은 자신의 작품에 서명하는 것을 자랑스러워 했다. 여러분도 그래야 한다.어떤 프로젝트에서는 코드 소유권이라는 발상 때문에 협력에 차질이 빚어질 수도 있다.
: 자신의 코드만 좋게 보고 동료들의 코드는 깎아내리는 편견(prejudice)을 갖게 된다.
-> 경계심 때문에 여러분의 코드를 참견하는 사람으로부터 방어하려고 해서는 안 된다.
같은 맥락에서 다른 사람의 코드를 존중해야 한다.
-> 이 팁에 효과를 보려면 개발자 사이에 황금률("남에게 대접 받고자 하는 대로 너희도 남에게 대접하라")과 상호 존중이라는 기반이 꼭 필요하다.익명성은 특히 큰 프로젝트에서 적당주의나 실수, 태만, 나쁜 코드의 온상이 될 수 있다.
-> 훌륭한 코드를 작성하는 대신 끝없는 상황 보고 속에서 어설픈 변명만 내뱉는 거대한 기계의 부속품으로 전락하게 될 것이다.우리는 소유권에 대항 긍지(pride)를 보고 싶다.
"내가 이걸 만들었고, 내 작품의 품질을 보증합니다."
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
최근 몇개월 사이에 내가 속한 팀에 많은 변화가 진행되었고 그 변화는 아직 현재 진행형 중이다.
처음 팀에 변화가 생기기 시작했을 때는 그것이 변화의 시작인지 인지하기 못했다. 그러다 변화가 차츰 눈에 보이기 시작했을 때는 이미 돌이킬수 없는 형태가 되어있었다. 그 때문에 '팀에 변화가 찾아온 진정한 이유' 에 대한 근본적인 것에 대한 생각 대신에 다른 외부적인 요인들을 끌어 들이며 왜 안정적이라고 생각했던 팀에 돌맹이를 던져 파란을 만들어내는 걸까? 라고 원망섞인 생각도 했었다.
그리고 현재 팀은 여전히 변화 진행중이다. 원망섞인 생각을 하던 전과 비교 하자면 이제는 변화를 받아들이게 되었고 이미 변화가 찾아와 진행중인 팀에 속한 나는 그렇다면 이 팀에 속했있는 동안에 나 자신, 그리고 팀, 그리고 최종 사용자가 만족할 만한 결과물들을 만들어내기 위해 어떤것들을 차츰 해내야 할까? 라는 고민이 많은 시기에 오늘 읽은 9장의 내용은 현재 수많은 고민들속 안개같은 상황속에서 앞으로 내가 어떤길로 나아가야 할지 알려주는 나침반 같은 장이였다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
오늘 읽은 다른사람의 TIL