1. 책임 실용주의 프로그래머는 경력에 대해 책임을 지고 자신의 무지나 실수를 인정하기를 두려워하지 않는다. 결과에 대해 책임을 진다는 것은 안좋은 결과가 나타났을 때 변명이 아닌 대안을 제시한다는 것과 같다. 단순히 안 된다고 할 것이 아니라 상황을 개선하기 위해 무
1. 중복의 해악 소프트웨어는 항상 변한다. 요구사항이 변경될 수도 있고, 규제로 인해 어쩔 수 없이 변경하거나 비즈니스 로직 자체가 바뀔 수도 있다. 이는 개발자가 개발의 대부분을 유지보수에 사용해야 한다는 것을 뜻한다. 그런데 유지보수는 개발이 끝나야 시작하는 것이
개발자는 지식을 수집하고 그 지식을 표현한다. 그리고 지식을 저장하는 최고의 포맷은 일반 텍스트이다.일반 텍스트란 사람이 직접 읽고 이해할 수 있는 형태의 인쇄가능한 문자로 이루어진 텍스트이다.일반 텍스트로 작성된 데이터는 다른 형태의 데이터보다 오래 살아남을 수 있고
1. 계약에 의한 설계 소프트웨어 모듈이 서로 소통하는 것을 돕기 위해 만들어진 것이 계약에 의한 설계(DBC)이다. 계약은 선행조건, 후행조건, 클래스 불변식으로 구성되어 있는데, 모든 선행조건을 충족한다면 종료시 모든 후행조건과 불변식이 참이 될 것을 보증해야 한다
1. 결합도 줄이기와 디미터 법칙 모듈이 서로 결합되고 의존하게 되면 어떤 일이 일어날까? 시스템의 무관한 변화가 코드에 영향을 미치게 되고, 간단한 수정으로도 시스템 전체에 해를 끼칠 수 있다. 이러한 위험을 덜어내기 위해 결합도를 줄이고자 노력하게 된다. 결합도를
1. 우연에 맡기는 프로그래밍 코드를 작성할 때 이 코드가 왜 잘 돌아가는지를 인식하면서 작성하는가? 코드를 작성하다보면 이따금 루틴을 의도에 맞지 않게 호출해도 원하는 동작을 하는 것처럼 보일 때가 있다. 이렇게 우연히 잘 동작하는 것을 확인하지 않고 내버려 두게 되
1. 요구사항의 구렁텅이 요구사항이 분명한 경우는 많지 않다. 또한 비즈니스 정책이 포함된 요구사항이라면 바뀌기도 쉽다. 따라서 요구사항은 최대한 일반적 진술로 만들고, 정책은 하나의 구현예로, 애플리케이션의 메타데이터로 만들어야 한다. 이렇게 해야 정책이 바뀌어도 메
1. 실용주의 팀 지금까지 살펴봤던 실용주의 기법들은 개인뿐만아니라 팀 전체에도 적용할 수 있다. 아래에서 그동안의 기법들 중 일부를 팀 전체에 어떻게 적용할 수 있는지 살펴보자. 깨진 창문 없애기 팀 전체가 상품의 품질에 책임을 져야 마땅하므로 깨진 창문을 용납해서