•
작성자: @한재엽
•
Updated: 22.6.26
Table of Contents
총평
Part I. 전제
Chapter 1. 소프트웨어 엔지니어링이란?
•
소프트웨어 엔지니어는 시간의 흐름과 언젠가 변경될 가능성에 더 신경써야 한다.
•
소프트웨어 기대 생애 동안 요구되는 모든 가치 있는 변경에 대응할 수 있다면 그 프로젝트는 지속 가능하다. 라고 할 수 있다.
•
소프트웨어 엔지니어링이란 여러 버전의 프로그램을 여러 사람이 참여해 개발하는 것이다.
•
“기발한”이 칭찬으로 느껴지면 프로그래밍이라 하고, 질책으로 느껴진다면 소프트웨어 엔지니어링이라고 한다.
•
개발 프로세스, 업무 프로세스는 눈치채기 어렵게 천천히 나빠지는 경향이 있다. “끓는 물 속 개구리가 되지 않도록 주의하자”
•
비욘세 규칙 (The Beyonce Rule)
◦
인프라를 변경하여 서비스가 중단되는 등의 문제가 발생하더라도, 같은 문제가 지속적 통합 시스템의 자동 테스트에서 발견되지 않는다면 인프라 팀의 책임이 아니다.
⇒ 네가 좋아했다면 CI 테스트를 준비해뒀어야지.
•
원점 회귀?
◦
개발 과정에서 문제를 일찍 발견할수록 비용이 적게 든다.
◦
타임라인에서 문제 발견 시점을 왼쪽으로 이동시킬수록 수정 비용이 줄어든다.
▪
개념잡기 → 설계 → 구현 → 리뷰 → 테스트 → 커밋 → 카나리 → 배포
•
비용이란?
◦
경제적 비용 (돈)
◦
리소스 비용 (하드웨어)
◦
인적 비용 (엔지니어링)
◦
거래 비용 (실행에 옮기는 비용)
◦
기회 비용 (실행에 옮기지 않는 비용)
◦
사회적 비용 (선택이 사회 전체에 미치는 영향에 대한 비용)
•
좋은 엔지니어링 결정이란 가용한 모든 근거 자료에 적절한 가중치를 부여하고 이러한 지식을 바탕으로 균형점을 잡는 일.
◦
반드시 해야 하는 일 (법적 요구사항, 고객 요구사항)
◦
근거에 기반하여 내릴 수 있는 최선의 선택
Action Item
원점회귀 할 수 있는 시스템 만들기•
Design review request (or Pre-commit review)
•
Pair programming time
•
Testing Study
테스트 환경 구축과 테스트 문화 만들기 (진정한 지속적 통합 환경 만들기)•
테스트 scaffolding
•
learning share
•
best practice
Part II. 문화
Chapter 2. 팀 워크 이끌어내기
•
인간은 간헐적 버그들의 집합에 가깝다.
•
혼자 일하려 한다면 실패할 위험성을 불필요하게 키우고 자신의 성장 잠재력을 속이는 것이다.
•
조기 공유?
◦
이미 구현된 선례가 있는 것은 아닌지 파악할 수 있다.
◦
초기 설계에 숨겨져 있는 근본적인 실수를 방지할 수 있다.
◦
혼자하는 것보다 아무튼 더 빠르게 할 수 있다.
◦
프로젝트의 버스 지수(Bus factor)를 높일 수 있다.
•
사회적 상호작용의 세 기둥
◦
겸손(Humility)
▪
당신은 모든 것을 알지도 완벽하지도 않습니다. 겸손한 사람은 배움에 열려 있습니다.
◦
존중
▪
함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해합니다.
◦
신뢰
▪
동료들이 유능하고 올바른 일을 하리라 믿습니다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋습니다.
•
우리 자존감을 우리가 작성한 코드와 동일시해서는 안 됩니다. 나는 내 코드가 아님을 명심하세요.
◦
자신과 만든 것을 구분짓고 자신을 믿고 동료를 믿으세요.
Action Item
•
코드 리뷰 가이드 만들어보기
Chapter 3. 지식 공유
•
다음 두 가지가 먼저 자리 잡아야 지식이 전파될 수 있다.
◦
모르는 것을 인정할 수 있도록 돕는 심리적 안전
◦
배우고자 하는 배움의 문화
•
안티패턴
◦
거짓된 놀람 금지: 뭐? useCallback이 뭔지 모른다고?
◦
세세하게 고쳐주기 금지: 자신을 뽐내려는 무의식에 기인하는 경향이 있다.
◦
뒷자석 운전 금지: 토론 중 적절한 발언권 없이 끼어들어 의견 제시하지 말기
•
지식 공유는 질문에서부터
•
쿠도스 제도 (공개칭찬)
◦
동료의 기여를 공개적으로 인정하는 제도
Action Item
•
심리적 안전을 위한 환경이 구축될 수 있도록 고민하기
•
Weekly I Learned 라는 코너?
Chapter 4. 공정 사회를 위한 엔지니어링
•
편견에서 벗어날 수 없다.
◦
이를 인정하고 의식적으로 개선하려 하자.
◦
다양한 사용자 층을 포용하기 위해선 조직 구성에 있어서도 다양성을 갖춰야 한다.
•
자신을 솔직하게 바라보고 성찰하자
•
모두를 위해 만들지 말자. 모두와 함께 만들자
•
제품을 이용하기 가장 어려운 이들을 위해 설계하자
•
가정하지 말고, 시스템 전반의 공정성을 측정하자
•
변할 수 있다
•
일부 사용자에게 해를 끼칠 수 있는 제품이라면 출시를 늦추는 것이 맞다
Action Item
인터뷰어 풀 신경쓰기 접근성 공부하고 라이트닝 톡 준비하기Chapter 5. 팀 이끌기
•
Manager: 사람을 이끈다.
◦
엔지니어링 관리자 (EM)은 구성원의 성과, 생산성, 행복을 책임지면서 제품의 사업적 요구까지 충족시켜야 한다.
•
Tech Lead: 기술과 관련된 책임을 진다.
◦
직접 나서서 일을 빠르게 처리하기도 하고
◦
다른 팀원에게 위임할지 판단한다.
◦
규모와 역량이 커질수록 위임하는 편이 낫다.
•
테크 리드 매니저 = Manager + Tech Lead
•
바나나를 재배하면서 사과를 세는 함정에 빠지지 말 것
◦
관리 업무는 효과가 나타나기까지 보통 더 긴 시간을 인내해야 한다.
•
피터의 법칙
◦
자신의 무능력이 드러나는 직급까지 승진하는 경향
•
Servant Leadership
◦
마치 집사가 가정의 안녕과 건강을 챙기듯, 팀을 떠받드는 것
◦
관리하려는 충동을 이겨내는 것
•
무슨 일을 처리할지 고민하고(What) 어떻게 처리할지는 팀에게 믿고 맡긴다.
•
안티패턴
◦
안티패턴 1. 만만한 사람 고용하기
▪
좌지우지할 수 있는 사람을 고용해서 권위와 위치를 공고히 한다
◦
안티패턴 2. 저성과자 방치
▪
기대를 충족해주지 못하는 사람을 다루는 것이 가장 고난이도 문제
▪
팀은 누가 저성과자인지 정확하게 알고 있다
▪
저성과자를 방치하는 것은 고성과자가 팀에 합류하는 것을 막고 고성과자가 팀을 떠나게 하는 요소가 된다.
▪
기간을 정하고 구체적인 목표를 제시할 것.
▪
점진적이고 측정가능한 목표.
◦
안티패턴 3. 사람문제 무시하기
▪
사회적 문제 / 기술적 문제 둘 다 신경쓸 것
◦
안티패턴 4. 만인의 친구되기
◦
안티패턴 5. 채용 기준 타협하기
◦
안티패턴 6. 팀을 어린이처럼 대하기
•
올바른 패턴
◦
자존심 버리기
▪
대신 집단으로서의 자존심과 정체성 강화하기
◦
마음 다스리기
▪
평정심 유지하기
▪
사람들을 고무시키는 것
▪
스스로 문제를 해결하도록 질문하고 직접 해결하기는 가장 마지막에 택하기
◦
촉매재가 되기
▪
팀원간의 상호작용을 만들기
◦
장애물 치우기
▪
정확한 답을 알고 있기 보다 올바른 사람을 알고 연결해주기
▪
꼭 멈춰야 된다고 생각되는 열차만 선택해서 멈추기
◦
선생이자 멘토되기
▪
멘티에게 도움이 얼마나 필요한지 측정하고 적절하게 input 넣기
◦
명확한 목표 세우기
▪
사명감
◦
정직하기
▪
피드백을 칭찬 속에 숨기지 말기
◦
행복한지 확인하기
•
경력 관리 챙겨주기
◦
새로운 것 배우기
◦
의미있는 제품, 서비스 론칭
◦
똑똑한 사람들과 일하기
▪
등을 성취할 수 있도록 고민하기
•
위임하되 곤란한 일은 직접 처리하기
•
대신할 사람을 찾기
•
혼란으로부터 팀을 보호하되 정직하기
◦
가능한 한 많은 정보를 팀과 공유하되 업무에 방해받지 않도록 하기
Action Item
엔지니어 경력 프레임워크 만들어서 경력 개발 1on1 하기 프런트엔드 챕터의 목적 생각해보기 플랫폼 팀의 이니셔티브 정의하기Chapter 6. 성장하는 조직 이끌기
•
Always Be Deciding (늘 결정하라)
◦
이 결정대로 시도해보고 어떻게 되는지 지켜보자. 상황을 보고 그 때 또 결정해보죠.
•
Always Be Leaving (늘 떠나기)
◦
스스로 single point of failure 되지 않도록 하기
◦
이 문제를 처리할 수 있는 사람이 정말 나뿐일까?
◦
업무 크리티컬 패스 상에서 내가 사라지도록 하기
◦
관찰과 경청 9%, 절묘하고 시의적절한 개입 5%
•
Always Be Scaling (늘 확장하라)
◦
상황을 주도하는 능동형 일보다 상황에 맞춰 대응하는 반응형 일의 비중이 커진다.
◦
급한 문제와 중요한 문제가 있는데, 급한 문제는 중요하지 않고 중요한 문제는 급하지 않다.
◦
나만이 할 수 있는 일을 처리해야 한다.
◦
따로 blocking 시간을 준비해둘 것.
◦
정말 중요한 20% 남기고 나머지 80%는 버릴 것.
Action Item
최대한 위임하기 blocking 시간 마련하기Chapter 7. 엔지니어링 생산성 측정하기
•
조직이 2배 커지면 소통 비용은 제곱으로 늘어난다. - 맨먼스 미신
•
선별하라. - 측정할 가치가 있는가?
◦
어떤 결과를 기대하고, 왜 그런가?
◦
데이터가 기대한 결과를 뒷받침 한다면 어떤 조치를 취하겠는가?
▪
딱히 액션이 없다면 측정할 가치가 없다. (현상 유지 편향)
◦
부정적인 결과가 나온다면 적절한 조치를 취할 것인가?
▪
대부분의 경우 이미 정해진 진로를 잘 틀지 않는다.
▪
결과가 부정적이더라도 딱히 액션이 없다면 측정할 가치가 없다.
◦
결과에 따른 조치는 누가 결정하고, 언제 수행하는가?
▪
결과, 결정에 따라 수행할 여유가 있는가?
◦
결과가 상대적으로 긴 시간동안 유의미한가?
◦
측정 결과를 단순히 계획의 뒷받침 용도로 쓰려고 하는가?
◦
측정할 수 있는 지표들이 문제를 평가하기에 충분히 정확한가?
•
GSM 프레임워크 기반의 선별
◦
Goal (목표): 원하는 최종 결과를 고차원 어휘로 표현한다.
◦
Signal (신호): 최종 결과를 이뤘는지 판단하는 방법
◦
Metric (지표): 실제로 측정하는 대상
•
엔지니어링 생산성을 구성하는 다섯가지 요소, 퀀츠(QUANTS)
◦
코드 품질 (Quality of the code)
◦
엔지니어들의 몰입도 (Attention from engineers)
◦
지적 복잡성 (Intellectual complexity)
◦
박자와 속도 (Tempo and velocity)
◦
만족도 (Satisfaction)
Action Item
•
측정하고자 하는 대상이 있는지, 있다면 GSM 기반으로 분석해보고 측정 시작하기
•
생산성을 개선할 수 있는 요소가 있는지 살펴보기
Part III. 프로세스
Chapter 8. 스타일 가이드와 규칙
•
규칙은 좋은 행동을 장려하고 나쁜 행동을 억제하기 위해 필요하다.
•
이루고자 하는 목표를 명확히 했을 때, 규칙이 따라온다.
•
규칙을 만들 땐,
◦
규칙의 양을 최소화 해야 한다.
◦
코드를 읽는 사람에게 맞춰야 한다.
◦
일관되어야 한다.
◦
예상치 못한 동작을 유발하는 구조는 피해야 한다.
◦
실용성을 생각해 예외를 허용한다.
•
코드는 작성되는 횟수보다 읽히는 횟수가 더 많으며 시간이 지날수록 더 벌어진다.
◦
쓰기에 간편함보다 읽기에 간단한 쪽에 가치를 둔다.
•
주석?
◦
문서화 주석과 구현 주석으로 나뉜다.
◦
문서화 주석은 jsdoc을 생각하면 된다.
◦
구현 주석은 뻔하지 않은 선택을 한 이유를 명시하기 위해 사용된다.
•
일관성
◦
코드가 일관되면 의미 단위로 잘 구분되어 분석하기 쉬워진다.
◦
어떻게 구현할지 고민하는 대신 무엇을 수행하느냐에 집중할 수 있다.
◦
모듈화하기도 쉽다.
•
규모가 커지면서…
◦
완전히 일관되는 일은 없을 것이며 그것을 목표로 삼지 않게 되었다.
◦
완벽한 일관성을 추구하기에는 얻는 것보다 비용이 큰 단계에 도달한 것이다.
◦
jscodeshift 같은 도구로 일괄 변경해도 완벽하지는 않기 때문이다.
•
스타일 가이드의 목적
◦
위험을 피하기 위함인가?
◦
모범 사례를 적용하기 위함인가?
◦
일관성을 보장하기 위함인가?
•
규칙은 고정불변이 아니다.
◦
다른 결론에 도달할 수 있는지를 다시 평가할 수 있다.
•
투표가 아니라 합의로 이뤄진다.
◦
개인 취향은 무시한다.
◦
트레이드 오프 평가에 기초하여 의사결정한다.
◦
다수결이 아니다.
•
가능한 규칙들은 ‘자동으로' 적용되게끔 해야 한다.
Action Item
•
운영중인 ADR을 스타일 가이드로 수정하고 근거가 되는 스레드를 추가한다.
◦
UX Engineering 부분도 살펴보자.
•
규칙을 변경할 수 있는 프로세스를 고민해본다.
◦
GitHub Discussion?
•
자동화 영역이 남아있는지 확인해본다.
Chapter 9. 코드 리뷰
코드 리뷰는 작성자 이외의 사람이 코드를 비판적으로 검토하는 프로세스이다.
구글에서 코드 리뷰는 소프트웨어 엔지니어라면 모두가 반드시 따라야 하는 몇 안 되는 전사적인 프로세스이다.
•
코드는 부채다
◦
코드가 그 자체로 부채임을 인정해야 한다.
◦
존재만으로 어느 순간 누군가가 유지보수해야 할 대상이 된다.
◦
밑바닥부터 만들고 있다면 뭔가 잘못하고 있는 것이다.
▪
누군가 비슷한 코드를 이미 작성해놓았을 가능성이 크다.
◦
새로운 걸 설계할 때는 작성 전에 챕터에서 이야기하면 좋다.
•
무엇을 검토하는가?
◦
정확성
◦
이해 용이성
◦
가독성
•
고민
◦
이 코드는 유지보수하기 쉬운가?
◦
내게 기술 부채를 안겨주나?
◦
우리 팀원 중에 이 코드를 유지보수해줄 전문가가 있나?
•
뭐가 좋지?
◦
코드가 정확한지 확인한다.
▪
일반적으로 변경 작성자가 선택한 방식을 존중해준다.
▪
완벽하다고 합의될 때까지 기다리지 않고 코드베이스를 개선한다고 인정되면 변경을 승인한다.
▪
완벽할 필요가 없다.
◦
변경된 코드를 다른 엔지니어도 잘 이해한다.
▪
지속해서 유지 가능한 코드인지 검토한다.
◦
코드베이스가 일관되게 관리된다.
▪
일정한 표준을 따라야 조직 안에서 이해되고 유지보수될 수 있다.
◦
팀이 소유권을 더 강하게 느낀다.
▪
리뷰 프로세스로 모노레포는 조직의 공동 소유물임일 인식시킨다.
◦
지식이 공유된다.
◦
코드 리뷰 자체의 기록이 남는다.
•
모범 사례
◦
방식에 결함이 있을 때만 대안을 제시한다.
◦
방식이 잘못되었다고 가정하기 전에 그렇게 처리하게 된 이유가 무엇인지부터 물어본다
◦
신속하게 피드백한다.
◦
제안한 변경은 팀의 소유임을 잊지 말아야 한다.
◦
작성자 또한 왜 그렇게 처리했는지 설명할 준비를 해둬야 한다.
◦
리뷰어가 단 댓글은 모두 할일로 취급해야 한다.
◦
작성자와 리뷰어 모두에게 배움의 기회임을 기억해야 한다.
•
요청자 입장에서,
◦
작게 만들어야 한다.
▪
200줄 이하
◦
변경에 대한 설명을 잘 써야 한다.
▪
무엇을 왜 변경하는지,
◦
리뷰어는 최소한으로
◦
가능한 자동화 한다.
•
코드 리뷰의 종류는?
◦
그린필드 리뷰 (신규 프로젝트 또는 새로운 기능)
▪
초기에 내린 가정들이 변해도 여전히 유지보수하기 쉬워야 한다.
▪
설계 리뷰를 강도 높게 진행한다.
▪
소유자를 명확히 한다.
◦
동작 변경, 개선, 최적화
◦
버그 수정 (롤백)
▪
기능 추가가 포함되어선 안 된다.
▪
롤백을 유발할 수 있는 모든 변경은 가능한 작고 원자적이어야 한다.
◦
리팩터링과 대규모 변경
Action Item
•
코드 리뷰 가이드 만들어보기
코드 리뷰 관련해서 계속 개선해나갈 working group 만들기Chapter 10. 문서
•
문서도 코드와 같다.
◦
문서에 정책과 규칙이 있어야 한다.
◦
버전 관리 시스템에 등록해 관리해야 한다
◦
관리 책임자를 명시해야 한다
◦
변경 시 리뷰를 거쳐야 한다
◦
주기적으로 평가해야 한다.
◦
최신 정보 반영 여부가 확인되어야 한다.
◦
하나의 문서는 하나의 목적에 집중해야 한다.
•
종류
◦
참조용 문서 자료
◦
설계 문서
◦
튜토리얼
◦
개념 설명 자료
◦
랜딩 페이지
•
문서화
◦
누가: 대상 독자가 누구인지 문서 안에서 명확히 밝혀줘야 할 때가 있다.
◦
무엇: 목적
◦
언제: 문서가 생성되고, 리뷰되고, 갱신된 날짜가 명시되어 있어야 한다.
◦
어디에: 장소
◦
왜: 목적, 문서에 대한 소개에 들어가곤 한다.
•
좋은 문서
◦
의도한 역할을 잘 수행하는 문서
•
폐기
◦
신선도 보증 기간
◦
마지막으로 리뷰한 날짜를 기준으로 3개월 동안 갱신되지 않을 시 알림 메일을 보낸다.
•
문서 자료를 테스트와 같은 수준으로 취급해야 할지는 모르겠다.
◦
하지만 문서는 조직의 규모가 커질수록 중요해진다.
Action Item
문서 쓸 때는 작성자와 날짜 남기는 습관 들이기•
GitHub에서 문서를 관리해야 하나 싶기도…
Chapter 11. 테스트 개요
테스트는 엔지니어에게 신뢰를 줄 때만 가치가 있다.
•
작성한 테스트는 수시로 실행될 수 있어야 한다.
•
Why?
◦
디버깅 감소
▪
코드의 존속 기간 전체로 봤을 때, 결함이 줄어든다.
◦
자신있게 변경 할 수 있다.
▪
리팩터링을 통해 코드 품질을 끊임없이 개선할 수 있다.
◦
더 나은 문서자료
▪
애플리케이션의 행위를 기술함으로써 문서로써의 역할을 한다.
◦
더 단순한 리뷰
▪
리뷰할 때도 동작을 예측하기 쉽다
◦
설계
▪
테스트를 잘 작성하면 잘못된 설계를 바로잡을 수 있다.
•
불필요한 노출 등을 숨기면서 더 응집도 높은 설계가 만들어진다.
•
테스트를 작성하는 것과 ‘잘' 작성하는 것은 별개이다.
◦
테스트를 작성하고 맨날 깨진다고 하는 것은 테스트를 잘못 작성했기 때문이다.
◦
대개 테스트에 대한 공부없이 테스트를 작성하곤 한다.
◦
테스트의 장점을 크게 누리지 못한 사람들이 부정적인 견해를 드러내곤 한다.
•
테스트는 두 가지 기준으로 분류할 수 있다.
◦
크기: 테스트 케이스 하나를 실행하는데 필요한 자원 (메모리, 프로세스, 시간)
▪
(LOC가 아니라) 프로세스 하나, 기기 하나, 여러 기기에서 테스트가 돌아감을 기준으로 크기를 구분짓는다.
▪
전통적인 단위 테스트, 통합 테스트 대신 크기로 구분짓는다.
▪
큰 테스트는 가장 복잡하고 검증하기 어려운 시나리오에만 제한적으로 활용한다.
◦
범위: 검증하려는 코드 경로
•
크기에 따른 테스트
◦
작은 테스트
▪
하나의 프로세스에서 실행되어야 하는 테스트 ( → 스레드 )
▪
테스트도 테스트 대상 코드와 같은 프로세스에서 실행되어야 한다.
▪
네트워크와 디스크에 접근하는 블로킹 호출을 사용해선 안 된다.
•
필요한 경우 테스트 대역을 사용한다.
◦
강한 의존성을 가벼운 인프로세스 의존성으로 대체해주는 수단
•
Why?
◦
블로킹 호출이 작은 테스트에 포함되면 전체적인 테스트 수행 속도가 느려진다.
◦
외부와 의존하게 되면서 불규칙한 결과가 나오고 이로 인해 테스트 수행 결과가 비결정적이 된다.
▪
범위와 상관없이 언제나 작은 테스트를 작성하길 권장한다.
◦
중간 테스트
▪
블로킹 호출을 이용할 수 있으나(로컬호스트) 외부 시스템과의 통신은 불허한다.
▪
흔히 말하는 통합테스트: 웹 UI와 서버 코드의 조합도 테스트 할 수 있다.
▪
외부 요인이 개입되므로 성능과 결정성을 온전히 우리 스스로가 보장할 수 없다.
◦
큰 테스트
▪
여러 개의 기기를 활용할 수 있다.
▪
비결정성으 크게 높아지기 때문에 몇 가지 용도에 한정해서 활용한다.
•
end to end test는 설정을 검증하는게 주된 목적이다.
▪
빌드나 릴리스 때만 수행되도록 하여 개발 워크플로우에 영향을 주지 않도록 한다.
•
크기와 상관없이 테스트의 공통 특성
1.
하나의 테스트 suite는 밀폐되어 있어야 한다.
•
setup, execute, tear down 하는데 필요한 모든 정보를 담고 있어야 한다.
•
테스트 수행 순서 같은 외부 환경에 관해서는 가능한 한 아무것도 가정하지 않아야 한다.
2.
확인하려는 행위를 수행하는 데 필요한 정보’만’ 포함해야 한다.
3.
무엇을 검사하는지가 명확해야 한다.
a.
정확성 검사는 사람이 직접해야 하기 때문에 조건문이나 순환문 같은 제어문은 쓰지 않는게 좋다.
b.
복잡해질수록 버그가 발생할 수 있으며 실패 원인을 파악하기 힘들어진다.
4.
테스트는 오직 실패했을 때만 들여다봐야 한다.
•
범위에 따른 테스트
◦
좁은 범위 테스트: 보통 단위 테스트
◦
중간 범위 테스트: 보통 통합 테스트
◦
넓은 범위 테스트: 보통 기능, 종단간 테스트
◦
구글은 되도록 작은 테스트, 좁은 범위 테스트를 추구한다.
▪
크기, 범위 별로 80:15:5 비율을 유지한다.
•
커버리지는 테스트되지 않은 코드가 어디인지 알려줄 수 있지만 시스템이 얼마나 제대로 테스트되었느냐를 판가람하는 지표로는 적합하지 않다.
•
구글의 테스트 혁명
◦
오리엔테이션 수업
◦
테스트 인증 프로그램
◦
화장실에서도 테스트
Action Item
•
테스트 혁신 진짜 해야겠다
Chapter 12. 단위 테스트
•
단위테스트는
◦
빠르고 결정적이어서 개발자들이 수시로 수행하며 피드백을 즉각 얻을 수 있다.
◦
작성하기 쉽다.
◦
실패 시 원인을 파악하기 쉽다.
◦
자연스럽게 예제 코드가 되며 문서 역할을 하게 된다.
•
1원칙: 테스트는 유지보수하기 쉬워야 한다. (maintainability)
◦
무엇이 테스트를 신뢰하지 못하게 하는가?
▪
검증 대상과 관련 없는 변경 때문에 실패하는 ‘깨지기 쉬운 테스트’ 때문에 (brittle)
▪
깨지면 무엇을 고쳐야 하는지 파악하기 어려운 ‘불명확한 테스트' 때문에 (unclear)
•
깨지기 쉬운 테스트 예방하기
◦
실제로 버그가 없음에도 상관없는 변경 때문에 실패하는 테스트
◦
테스트가 변경에 영향을 덜 받도록 해주는 패턴을 찾자.
•
테스트는 시스템의 요구사항이 바뀌지 않는 한 수정할 일이 없어야 한다.
◦
행위를 의도적으로 변경하는 경우에는 테스트도 함께 갱신해줘야 한다.
▪
이 경우, 작성된 테스트를 먼저 수정해도 좋다.
•
리팩터링 시 테스트가 깨졌다면?
◦
리팩터링 중 기능이 변경되진 않았는지 살펴보자
◦
테스트의 추상화 수준이 적절하지 못하진 않았는지 살펴보자
▪
세부 구현에 의존하고 있진 않았는지?
•
공개 API를 이용해 테스트 한다.
◦
공개 API란 서드파티에 노출한 API를 말한다.
◦
테스트 코드도 다른 사용자가 시스템을 호출하는 방식과 똑같은 방식으로 시스템을 호출한다.
◦
“사용하듯이”
◦
private 접근자를 제거하고 노출시킨다음 테스트하고 싶은 유혹을 떨쳐낼 것.
◦
보조하는 용도가 다인 메서드나 클래스라면 독립된 단위로 생각하지 않는 것이 좋다.
▪
고민) 한 컴포넌트에서만 사용되는 hooks는 독립된 단위가 아니기 때문에 따로 테스트하지 않고 이를 사용하는 컴포넌트를 통해서 테스트되도록 테스트 케이스를 구성한다????????????
◦
다방면으로 유용한 기능을 제공하도록 설계된 패키지나 클래스는 직접 테스트해야 하는 단위이다.
▪
hooks라도 유틸성 hooks는 테스트 대상이다.
•
상호작용이 아니라 상태를 테스트하자.
◦
대부분의 상황에서, 상호작용 테스트는 상태 테스트보다 깨지기 쉽다.
▪
상태 테스트는 결과가 “무엇인지”에 집중하고 (What)
▪
상호작용 테스트는 시스템이 “어떻게 작동하냐”를 확인하려 하기 때문이다. (How)
◦
상태 테스트: 메서드 호출 후 시스템 자체를 관찰
◦
상호작용 테스트: 호출을 처리하는 과정에서 다른 시스템과 협력하여 기대한 일련의 동작을 수행하는지 확인할 때
◦
상호작용 테스트가 만들어지는 가장 큰 원인은 모의 객체 프레임워크에 지나치게 의존하기 때문
▪
가짜 객체는 변한값을 반영하지 않기 때문
•
명확한 테스트를 작성하자.
◦
명확한 테스트란 존재 이유와 실패 원인을 엔지니어가 곧바로 알아차릴 수 있는 테스트를 의미한다.
◦
완전하고 간결한 테스트를 작성하면 된다.
▪
테스트 코드를 읽는 사람 입장에서 이 테스트를 이해하는 데 필요한 모든 정보를, 테스트 케이스 본문에 담고 있는 테스트를 말한다.
▪
이와 동시에 관련없는 정보는 담지 않아야 한다.
•
관련없는 정보가 포함되어 있다가 상관없는 변경으로 인해 테스트 케이스가 깨지기 마련이다.
▪
공통 객체를 사용하는 대신에, 헬퍼 메소드를 사용하여 값 객체를 만들자.
◦
메서드가 아니라 행위를 테스트하자
▪
행위란 특정 상태에서 특정한 일련의 입력을 받았을 때, 시스템이 보장하는 ‘반응'을 뜻한다.
▪
메서드 당 테스트 케이스 1개일 필요가 없다. 1:N의 관계이다.
•
메서드가 여러개만 N:N의 관계인 것이다.
▪
테스트 케이스 하나에서 하나의 행위만 테스트하자.
•
코드가 많아지지만, 더 좁은 범위이기 때문에 실패했을 때 그 원인을 좀 더 빠르게 파악할 수 있다.
•
테스트 명세가 한 가지만 드러내므로 더 파악하기 쉽다
◦
테스트의 구조는 행위가 부각되어야 한다.
▪
given, when, then으로 구분지어서 표현하기도 한다.
•
given: 시스템 설정을 정의한다.
•
when: 시스템이 수행할 작업을 정의한다.
•
then: 결과를 검증한다.
▪
여러 단계로 진행되는 작업은 교대로 when, then을 정의해도 된다.
▪
긴 블록의 경우 and로 연결해줄 수도 있다.
◦
테스트 명세는 행위 중심이 되어야 한다.
▪
동작과 예상 결과를 모두 담아야 한다.
▪
테스트 이름에 “그리고”가 들어가면 테스트 케이스를 나눠야 하나? 하는 의심을 할 수 있다.
•
테스트에 논리를 넣지 말자
◦
약간의 중복을 허용하더라도 순회문이나 조건문은 배제하자
◦
직설적인 코드로 작성하자
◦
DRY대신 DAMP(Descriptive And Meaningful Phrase)
•
공유 도우미 메서드와 공유 검증 메서드
◦
테스트용 값을 생성하는 코드 부분을 공유 도우미 메서드를 사용할 수 있다.
◦
검증을 공유 검증 메서드로 처리한다면?
▪
버그 하나로 인해 여러 테스트가 동시다발로 실패할 수 있다.
◦
공유 검증 메서드는 단 하나의 개념적 사실만을 검증해야 한다.
Action Item
•
테스트 혁신 가즈아!
Chapter 13. 테스트 대역
•
테스트 대역을 사용하면 실제 구현을 테스트 대역으로 교체하여 테스트할 수 있게 됩니다.
•
하지만 잘못사용하면 깨지기도 쉽고 복잡하고 효율도 나쁜 테스트로 전락합니다.
•
그렇기 때문에 되도록 실제 구현을 이용하시길 권합니다.
Part IV. 도구
트렁크 기반 개발, 모노레포, 정적분석 등 대부분 이미 토스에서 하고 있는 것들이라 메모가 적음.
(테스트가 메모가 많은 것도 동일한 이유)
Chapter 16. 버전 관리와 브랜치 관리
•
트렁크 기반 개발 짱
◦
트렁크 기반 개발과 뛰어난 소프트웨어 조직 사이에는 양의 상관관계가 존재
•
운 없는 엔지니어는 빌드 마스터, 병합 관리자, 콘텐츠 관리 엔지니어 같은 타이틀을 달고 조직 내의 모든 이질적인 브랜치를 병합하는 책임을 떠맡는다.
•
완벽하지 않거나 테스트되지 않는 기능은 비활성화하는 방향
◦
Feature Flag를 적극 활용하고 모든 변경사항은 main branch로 집어넣는다.
▪
(완전 동의)
◦
개발 브랜치를 만들지 말고, 만들더라도 매우 짧게 쓰고 없애야 한다.
◦
진행 중인 작업을 줄일 것
•
원 버전 정책
◦
모든 코드는 모노레포에.
◦
모듈들은 하나의 버전
▪
개발자가 이 구성요소는 어떤 버전을 사용해야 하죠?라고 묻는 상황을 만들지 않아야 한다.
•
빌드 호라이즌 정책
◦
프로덕션 환경에서 구동 중인 모든 제품은 최대 6개월 안에 다시 빌드하여 재배포해야 한다.
•
모노리포
◦
일관성 덕분에 도구를 새로 도입하거나 코드를 최적화한 혜택이 조직 전체에 훨씬 빠르게 전파된다.
Action Item
•
Feature flag 활성화 방안 생각해보기
Chapter 17. Code Search
사내 모노리포 검색 툴, 좋다는 자랑!
•
왜?
◦
이 코드가 왜 추가되었는가? 왜 이런 식으로 동작하는가? 에 대한 답을 찾기 위해 검색 목적으로 사용
◦
특정 시점의 코드베이스 상태를 찾기 위해
▪
새로 추가한 코드가 실패할 경우, 몇 분 전 추가된 변경을 살펴볼 때 사용
Chapter 18. 빌드 시스템과 빌드 철학
•
빌드?
◦
의존 관계를 생각해서
◦
각 조각을 올바른 순서로
◦
그 조각에 적합한 도구를 이용하여
◦
해야 하는 것
•
Not 태스크 기반의 빌드 시스템, But 아티팩트 기반의 빌드 시스템
•
원격 캐싱
◦
공통의 원격 캐시 서비스를 참조 (레디스 or GCP)
•
때로는 엔지니어의 힘과 유연성을 제한해야 생산성을 높일 수 있다.
•
의존성의 버전 관리는 너무 어렵다
•
작은 모듈 방식이 굵직한 모듈 방식보다 잘 확장된다.
Chapter 19. 구글의 코드 리뷰 도구, Critique
토스에서 사용하고 있는 프론트엔드 종달새 bot이 더 잘해주고 있음.
Chapter 20. 정적 분석
skip. 우리 챕터는 이미 너무 잘하고 있음
Chapter 21. 의존성 관리
•
안하는 것이 최선이다.
◦
모노레포에서 라이브러리, 서비스를 한꺼번에 관리하고 있어서 아직 필요성을 크게 느끼지 못하고 있음.
◦
필요하다면 외부 서드파티 라이브러리에 대한 의존성 관리가 필요함
•
라이브러리 분리는 아직 고려하지 않고 있음.