개발 프로세스
작성: 0chilHow we (should) work?
Section titled “How we (should) work?”문제가 무엇이며, 왜 풀어야 하는지 정의한다.
프로그래밍은 소프트웨어의 통제권을 쥐는 행위다.
문제를 제대로 정의하지 않으면 통제권을 제대로 확보했는지 스스로 살필 수 없다.
옵션 살피기
Section titled “옵션 살피기”문제를 해결할 수 있는 수단들을 탐색한다.
해결 수단 선택
Section titled “해결 수단 선택”잘못된 수단의 선택은 팀 전체에 해악이다.
먼저 현재 상황을 살핀다. ex) 데드라인이 코앞이다, 완성도 높은 기능을 제작해야 한다, …
옵션 중 현재 상황에 맞는 최선의 선택을 찾는다.
선택한 해결 수단으로 문제를 해결한다.
기존 판단이 완벽할 리 없다.
의심이 된다면 지체없이 기존 단계로 돌아가서 다시 고민하자.
가능하면 테스트 코드를 작성한다.
테스트 코드는 문제와 그 해결 기준을 문서화하고, 심지어 자동으로 피드백까지 해주는 기가막힌 도구이다.
System
Section titled “System”
개발 프로세스
Section titled “개발 프로세스”개발을 통해 실제 문제를 해결하고, Pull Request를 작성한다.
코드 리뷰는 이 과정에서 이뤄진다.
작성된 PR은 시스템에 의해 검증되며, 문제 해결의 유연성을 위해 꼭 통과하지 않아도 머지할 수는 있다.
운영 배포 프로세스
Section titled “운영 배포 프로세스”운영 배포는 제품이 사용자와 마주하는 중요한 행위다.
미숙할 순 있으나, 미완성이어선 안된다.
때문에 정의한 문제들이 제대로 해결되었는지 시스템이 검증하고 배포하는 과정이 있다.
작성한 PR은 트리거(/merge)를 통해 시스템이 검증하고, 자동 fast-forward 머지되어 운영에 배포된다.
(main 브랜치는 운영 배포 프로세스를 통해 주기적으로 dev 브랜치를 따라간다)