프로그래밍 설계상의 부채

처음 코드를 작성하는 것은 빚을 지는 것과 같다. 그리고 코드를 개선하는 것은 빚을 갚는 활동이다. 

약간의 빚을 지고 있는 동안에는 빚을 갚기 위한 개발이 가속화된다.

진정한 위험은 채무가 상황되지 않을 때 발생한다. 올바르지 않는 코드에 시간을 쏟는 일은 빚에 이자를 더하는 것이다.

완성도 낮은 코드로 인해 전체 엔지니어링 조직은 빚더미에 쌓인다.

문제는 거의 언제나 항상 제품 출시일 때문에 발생한다. 

다시 돌아가서 문제를 해결할 시간이 없다는 말이 있듯이 출시를 위해서 당분간 필요한 코드를 이리저리 조금씩 붙여 나가다가 어늗덧 감당할수 없게 된다.

프로그램이 빚더미에 앉았을 때 다음과 같은 징후가 발견된다.

취약성 

시스템의 내부로직과 의존할 뿐 누가 봐도 관련 없어 보이는 부분의 상세 구현 내용이 노출되거나 예상치 못한 부작용이 발생할 때 취약점이 느러나며 그 결과 코드를 변경할 때는 연관성이 없어 보이는 코드에서 사이드 이펙트가 발생한다.

경직성

유연하지 못한 소프트웨어는 변화에 큰 걸림돌이다. 실제로 잘못된 설계로 인해 작은 코드 변경에도 많은 노력이 필요하며, 보통은 비싼 비용이나 많은 시간, 위험 부담이 높은 리팩토링 등이 발생하기 때문에 새로운 변경을 위한 노력은 한없이 늦춰진다.

부동성

유능한 엔지니어는 소프트웨어를 안정적이고 유지보수도 쉽게 만들기 위해서 코드를 재사용 할수 있는 부분들을 먼저 찾는다. 하지만 이러한 노력도 특정 상황에만 해당되서 그 외에 재사용 할 수 없는 코드를 만나면 그 노력은 무용지물이 되고 만다. 주변 코드와 딱 달라 붙어서 아주 밀접한 관계를 맺는 코드를 구현한다거나 아니면 특정 도메인에 한정된 로직을 하드코딩하는 경우가 여기에 속한다.

비 이동성

팀원 중 딱 한명의 엔지니어만이 시스템의 특정 부분을 감당 할 수 있는 경우를 일컬어 비 이동성이라고 한다. 어떤 업무를 담당하는 사람은 그 기능을 처음 개발한 개발자이거나 불행히도 그 코드를 좀더 개선하고자 시도했던 사람 일수도 있다. 수많은 대규모 프로젝트에서는 모든 엔지니어가 프로젝트 전체를 구체적으로 이해한다는 것은 불가능 하지만 그렇다고 다른 개발자가 쉽게 코드를 이해하지 못하거나 효과적으로 요구사항을 반영하지 못하도록 영역을 나누는 것도 프로젝트에 결코 도움이 되지 않는다.