- 소스코드 관리시스템을 사용하고 있습니까?
- 한방에 빌드를 만들어낼 수 있습니까?
- 일일 빌드를 하고 있습니까?
- 버그 추적시스템을 운영하고 있습니까?
- 코드를 새로 작성하기 전에 버그를 수정합니까?
- 일정을 업데이트하고 있습니까?
- 명세서를 작성하고 있습니까?
- 조용한 작업 환경에서 일하고 있습니까?
- 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
- 테스터를 별도로 두고 있습니까?
- 프로그램 채용 인터뷰 때 코딩 테스트를 합니까?
- 무작위 사용편의성 테스트를 수행하고 있습니까?
예나 아니오로 쉽게 답할 수 있다.
소스코드 관리 시스템을 사용해야 다른 프로그래머가 무엇을 했는지 알 수 있고, 실수를 되돌릴 수 있다.
빌드 과정이 복잡하다면 분명히 실수가 발생한다.
요즘은 CI를 써서 커밋할 때마다 빌드를 하는 거 같다.
사람의 기억력을 믿을 수 없다. 무조건 버그를 잊어먹을 수밖에 없다.
최소한 다음 항목을 포함해야 한다.
- 버그를 재현하기 위한 완벽한 단계
- 예상 수행 결과
- 관찰한 (버그로 간주되는) 실제 수행 결과
- 수정을 맡을 개발 책임자
- 수정했는지 여부
버그를 수정하는 시기를 뒤로 미루면 미룰수록, 수정과정에서 더 많은 시간과 돈이 들어간다.
버그가 없다 == 언제든지 출시 준비 상태로 유지할 수 있다 == 경쟁사 발 빠른 대응 가능
사업에는 고객 데모, 전시회 참가, 광고 같은 수많은 계획과 결정사항이 필요하다.
이를 제대로 진행하기 위해 일정을 만들고 계속해서 업데이트해야 한다.
프로그램의 통제력을 위해
프로그래머의 생산성은 단기 기억에서 세부적인 사항 대부분을 한 번에 처리하는 능력에 의존한다.
사소한 방해로 업무흐름이 끊기면 업무흐름을 다시 따라잡기 위한 시간이 낭비된다.
EX) 신형 컴퓨터를 도입해서 컴파일 시간을 조금이라도 줄이면 생산성이 올라간다.
시급 3만원인 테스터가 수행할 작업을 시급 10만원인 프로그래머 수행하도록 돈을 낭비해서는 안된다.
꼭 코드를 작성해보게 한다.
사용자 인터페이스를 개선하기 좋은 방법이다.