서론: 일정 vs 퀄리티
•
프로그래머의 고민
◦
일정은 지키지만 버그가 많은 것 vs 일정은 못지키지만 버그가 없는 것
•
오늘 또 일을 미루고 말았다, 나카지마 사토시
◦
프로그래머에게 요구되는 것은 100점이 아닌 80~90점 짜리 프로그램을 기한 내에 완성하는 일이다
•
프로덕트 엔지니어의 일은 고객이 원하는 기능을 고객이 원하는 시점에 전달하는 것
•
우리가 해야하는 것
◦
아무리 급해도, 항상 80~90점짜리 소프트웨어를 일정 내 개발할 수 있는 방법
•
일정을 항상 잘 지키는 분들의 공통점
◦
A 코드 vs B 코드 중 가장 좋은 코드를 선택하는 방법은?
◦
일정을 지키고 일을 잘하는 분들은 본인만의 기준과 원칙으로 빠르게 결정
•
선택의 순간마다 고민 하는 사람 vs 원칙에 따라 빠르게 결정하고 중요한 것만 고민하는 사람
원칙: 제어할 수 없는 것에 의존하지 않기
현실 세계의 변화와 설계 사이의 결합도를 줄여야한다.
전화번호를 식별자로 사용하는가?
자신의 힘으로 제어할 수 없는 속성에 의존하지 마라
(실용주의 프로그래머 중)
•
예) 주민등록번호 수집 요구 금지
◦
절대 변하지 않을 것이라 믿고 의존했던 속성이었지만, 변경이 발생하여 대부분의 시스템의 주요 키 변경이 발생
◦
외부에서 전달 받은 값은 절대 주요키로 선택하지 않는다.
•
SQL 보다는 애플리케이션에서 값을 다룬다.
◦
password(), encrypt()…
•
제어할 수 없는 것에 의존할 수록 변화에 쉽게 흔들리는 소프트웨어가 만들어진다.
제어할 수 없는 코드
함수 내부에서 new Date()와 같이 시간 객체를 생성하는 것 → 제어 불가능
•
단위 테스트? 특정 날짜에만 패스. 나머지는 실패
◦
아마도 모듈 모킹으로 해결 가능
•
그러나 여전히 제어 불가능한 상황은 발생 가능
◦
날짜 라이브러리가 교체된다면?
◦
테스트 프레임워크가 교체된다면?
⇒ 변화에 쉽게 흔들리는 소프트웨어
•
제어할 수 있는 코드
◦
Default Parameter로 제어할 수 없는 값을 주입
◦
제어할 수 있는 상황 → 성공하는 테스트
전염되는 제어할 수 없는 코드
•
예시) 여러 강의들 중 결제 금액 계산 결과가 100원이 넘는 건들만 PG 결제
◦
함수를 리팩토링 했지만 모든 함수에 모킹이 필요함
◦
클린 코드에 따라 함수를 나눴더니, 상위 함수까지 전염되어 제어 할 수 없는 코드가 됨
•
제어할 수 없는 것
◦
외부 서비스 Modal
•
제어할 수 있는 것
◦
결제 금액 계산 100원 이상 걸러내기
•
제어할 수 있는 것과 제어할 수 없는 것을 구분하기
예시
•
제어 할 수 없는 코드란 순수하지 않은 코드 나 객체
◦
Business Logic
▪
제어 하기 쉬움
▪
제어가능한 코드를 최대한 늘려 나가야할 영역
◦
UI & Data
▪
제어하기 어려움
▪
제어가 어려운 코드를 밀어넣어서 격리할 영역
제어 할 수 없는 직원
•
어떻게하면 좋은 개발자를 채용할 것 인가?
◦
제어 할 수 없는 것
▪
우리 회사의 매출, 투자
▪
높은 개발자 연봉
▪
스타트업 전체의 권고사직
◦
제어할 수 있는 것
▪
?
▪
팀원의 성장 환경
•
좋은 개발자 채용은 제어할 수 있는 것이 아니다
•
내가 할 수 있는것? (제어할 수 있는 것) → 팀원의 성장 환경 조성
◦
좋은 시니어 사내 강연 → 좋은 시니어들의 노하우를 흡수
▪
정기적인 외부 시니어 강연
▪
필요한 노하우를 먼저 제시하는 팀원들
◦
잦은 피드백을 줄 수 있는 환경
▪
정적 분석
▪
테스트 코드
▪
Lint, 코드 포맷팅
•
할수 있는 것에만 집중, 긍정적으로 상황 해석하기
•
수년간 160키로 이상 떨어진 다른 학교에서 연습 경기를 해야하는 팀의 감독이라면?
◦
장소를 옮겨가면서 홈 경기를 치르면 원정경기에 강해질 것이다.
◦
다른 곳에서 시합할 떄의 산만함과 혼란스러움에 익숙할 테니까
마치며
•
안좋은 환경에서도 좋은 것을 찾아보는 것
•
좋은 환경만 있을 수 없다. 안좋은 일을 긍정적으로 바라보는 것이 필요
•
제어할 수 없는 것에 거리두기, 제어 할 수 있는것에 집중하기