이 책은 프로젝트 과정 전반에 거쳐 소프트웨어 전문가답게 진행하는 방법에 대해 서술되어있다. 전반적으로 이해가 잘되도록 쓰여져 있고, 현인의 어록과도 같은 책이라 참고할만한 부분도 많이 있다.
하지만 조직문화나 권한의 한계, 물리적인 시간의 한계로 모든 팁을 다 따르기는 어렵다. 또한 이러한 내용은 완전히 습관이 되어야하는데, 긴 책 내용을 전부 기억하기는 현실적으로 어렵다. 따라서 현재 내 상황에서 실천 가능한 팁들을 간단히 정리하였다.
이 문서는 1차, 2차, … 로 비정기적으로 업데이트 해나갈 것이다. 다음 업데이트는 이전 차수 내용이 완전히 체화 되었을 때이다.
실천 가능한 팁 정리 - 1차
- 팀 내 구성원끼리 서로를 믿을 수 있어야한다. 신뢰가 기반이 되어야 안전하게 아이디어를 교류할 수 있다.
- 자신이 작성한 코드에 책임을 져라. 어설픈 변명 대신 대안을 내라. 그저 모르겠다는 대답은 하지마라
- 깨진 창문을 방치하지마라. 당장 시간이 없다면 주석이나 메모라도 작성하여 인지는 하라
- 어떤 변화를 만들고 싶으면 작은 성공을 먼저 보여줘라. (Topic 4)
- 당장의 일에만 정신을 쏟지말고 큰 그림을 기억하라
- 피드백 주기를 만들어라
- 회귀 테스트, 의뢰인 피드백, 짧은 배포주기
- 모호한 요구사항에 대해서도 여러번 질문을 하여 피드백받아 구체화하라
- 너무 먼 미래를 내다보지 말고 피드백을 받아라
- 지식 포트폴리오를 만들어라 : 주기적인 투자, 리스크 관리, 다각화, 리밸런싱
- 문서는 애초에 포함하고 나중에 집어넣으려고 하지 말라 (ex : swagger가 좋은 예시)
- 에디터를 잘 활용하라. 자주 수동으로 사용하는 동작을 단축키로 해결할 수 있는지 찾아봐라
- 변경하기 쉬운 설계를 하라
- DRY : 코드를 포함한 문서, 데이터, 주석, 개발자 간의 주석을 줄여라 (Topic 9)
- 직교성 : 코드 사이의 결합도를 줄여라. 전역 데이터도 결합이다. 데메테르 법칙(
.은 하나만)- 상속 대신 인터페이스, 위임, 믹스인을 사용하는 것이 결합도가 낮다.
- 프로그램을 데이터 변환 모델이라고 생각하라
- PERT 기법 : 최상, 일반, 최악의 시나리오별로 예상되는 추정치를 전달하는 방법
- 엔지니어링 일지를 적어라 : 디버깅 기록, 엉뚱한 생각 등 어떤 것이든 기억할만한 무엇이든 적어도 됨
- 있을 수 없는 일이 발생했다면 최대한 빨리 멈춰라. 빨리 멈추는게 계속 작동하는 것보다 좋다
- 있을 수 없는 일을 검사하기 위해 단정문을 사용할 수 있다. 단정문에 걸리면 최대한 빨리 멈춰라
- 무언가 불안한 느낌이 들면, 왜 그런 느낌이 드는지 이유를 천천히 생각해보고, 테스트해봐라
- 잘못된 가정으로 코딩을 하지마라. 가정을 세웠다면 그것을 증명하라
- 속성 기반 테스트를 통해 예상치못한 상태를 검증할 수 있다.
- 리팩터링은 일찍 자주 습관적으로 하라.
- 테스트는 코드의 첫번째 사용자다. 테스트를 생각하는 것만으로도 큰 도움이 된다.
- 이름을 지을땐 코드의 역할에 따라, 일관적으로 지어라.
- 어려운 문제를 맞이했을때, 불필요한 제약조건을 세우진 않았는지 생각하라
- 어려운 문제를 맞이했을때, 잠시 숨을 돌리거나 고무오리 기법을 사용하는 것도 좋다
- 일상적으로 반복되는 작업을 자동화하라
- 특정한 방법론에 얽매이지말고, 팀에 잘 맞는 방법론의 좋은 점만 취하여라
사용자가 기대하는 것이 무엇인지 계속 생각하라. 그것이 진짜 목표이다.
- 하나의 메서드, 컴포넌트를 작성한 이후에는 어떻게 테스트할지를 생각해보자
- 중요한 메서드, 컴포넌트에는 테스트를 추가하자 (속성기반 테스트, 단위테스트 등)
- 반복되는 작업이 보이면 자동화하자