5 습관 프로그래머의 일상 - ChoDragon9/posts GitHub Wiki
5. 습관: 프로그래머의 일상
5.1 프로그래머의 3대 미덕
태만(자동화) 전체의 노력을 줄이기 위해 수고를 아끼지 않는 기질이다. 나중에 모두가 편해지도록 지금 유용한 코드를 작성한다. 귀찮은 업무, 몇 번이나 되풀이되는 업무는 소프트웨어를 만들어 자동화한다.
성급(서식화) 컴퓨터가 충분히 효율적으로 동작하고 있지 않거나 의도대로 동작하지 않는다면 즉시 코드를 다시 작성한다. 작업의 품질과 작업에 드는 시간도 개선된다.
오만(모듈화) 높은 자존심을 갖고 남에게 내놓아도 부끄럽지 않는 코드를 작성한다. 책임감있게 전문가라는 의식을 갖고 작업에 착수한다.
프로그래머의 중노동에는 의미가 없다. 업무를 하면 할수록 문제 영역에 관한 이해가 깊어지고 같은 목적을 달성하는 데 필요한 노력과 시간은 점차 줄어든다. 자신의 업무에서 어떤 불필요한 것이 있는지를 늘 관찰하고 결과를 나중의 업무에 반영시켜 나가면 착실히 효율화를 도모할 수 있다.
5.2 보이 스카우트 규칙
보이 스카우트에는 간단한 규칙이 있다. 자기가 머물렀던 자리를 떠날 때는 자기가 왔을 때보다 깨끗이 치워야 한다는 규칙이다.
처음 코드를 작성한 사람이 누구인지와는 상관없이, 조금씩이라도 코드를 개선하려는 노력을 계속해야 한다.
프로그래밍은 '급할수록 돌아가라'
- 직접적인 가치를 얻을 수 없다는 이유로 단위 테스트 작성을 생략한다.
- 변경을 가했을 때 제대로 수정되었는지를 확인할 수 없기 때문에 테스트가 없으면 사소한 변경이라도 수작업을 통한 테스트가 필요해지므로 소프트웨어가 깨지기 쉽고 유지보수에 비용이 든다.
- 비용 경감을 위해 목적에 적합하지 않는데도 기존 시스템을 억지로 사용한다.
- 이렇게 무리를 하는 이상 힘들어지고 언젠가는 파탄이 난다.
- 결국 제대로 요구사항에 맞춰서 아키텍처를 다시 만들 수밖에 없다.
- 비용은 처음부터 올바른 선택을 했을 때와 비교하면 멀리 돌아온 만큼 대폭 증가한다.
5.3 성능 튜닝에 관한 금언
성능 튜닝은 프로그래밍의 초기에 고려해야 할 작업이 아니다. 프로그래밍에서는 빠른 코딩보다 우선 바르고 읽기 쉬운 것을 주안점을 둔 좋은 코드를 작성하는 데 노력해야 한다.
빠른 코드는 수지가 맞지 않는 다.
- 가독성의 저하, 품질의 저하, 복잡성의 증가, 보수의 저해, 환경 간의 경합, 작업량의 증대
성능 튜닝의 순서
- 최적화의 필요성을 증명한다.
- 성능을 계측하고 병목을 특정한다.
- 병목 코드를 최적화한다.
- 성능을 계측하고 최적화 효과를 확인한다.
- 최적화환 코드의 동작에 문제가 없음을 검증한다.
5.4 비자아적 프로그래밍
프로그래밍할 때는 자만과 자존심을 버리고 동료에게 협력을 구하도록 한다. 자기 능력을 뽐내는 것이 아니라 코드가 더 좋아지는 것에 초점을 맞추어야 한다.
5.5 한 걸음씩 조금씩
프로그래밍은 한 번에 작은 하나만을 수행한다. 작지만 확실한 한 걸음을 반복해서 나아가야 결과적으로 품질도 시간 효츌도 높아진다. 왜냐하면 한 번에 여러 가지를 작업하면 작업에 혼선을 빚어 모두 실패할 가능성이 커지기 때문이다. 한 걸음씩 나아가면 마지막 한 걸음을 되돌리기가 편하다.
5.6 TMTOWTDI(There's more than on way to do it)
방법은 하나가 아니다.
다른 사람이 사용할 툴을 설계할 때는 달성하고자 하는 것의 수단을 여러 개 준비한다. 이렇게 하면 툴 자체는 복잡해지더라도 툴을 사용하는 쪽은 다양한 상황에서도 단순한 코드를 작성할 수 있다.