책상을 정리하다가 “라라벨 빨간책”이라 알려진 책을 집필하며 2016년 초에 쓴 메모 중 일부를 찾았다.

실무 개발자로 일하지 않던 시절 피상적으로만 생각하던 내용들이 지금은 피부에 와 닿는다. 이 포스트의 본문은 최근 나 또는 내가 속한 팀이 처한 상황에 거의 흡사하게 오버랩핑되는 2016년 메모의 일부분이다. 내 기억이 맞다면, 누군가의 영상 강의를 보고 메모한 것이다.

이 시대의 스승(엉클 밥, 파울러 옹 등)들이 언급한 소프트웨어 개발자로서 코드를 대하는 자세, 즉 소프트웨어의 제 2가치와 제 1가치에 대해 다시 한번 되새겨본다.

개발해서 남에게 납품하는 소프트웨어는 굳이 이럴 필요까진 없다고 생각한다. 그러나, 자신의 서비스를 위해 소프트웨어를 개발한다면, 개발자가 코드를 완전히 소유할 수 있는 시간과 비용을 인정해 줘야 한다.

Cost of Code(=~Program)

• Cost of introduction (최초 개발 비용, 모두가 합의한 비용)
• Cost of change (수정 비용, 사업적 필요에 의해 발생할 수 밖에 없는 비용)
• Cost of ownership (소유 비용, Time and effort it takes to maintain the owned application logic to support its ongoing change)

That’s why some engineers try to increase the cost of introduction in an attempt to affect the cost of change curve.

Ownership of Code.

• Own only the logic you need to change (계속 유지보수할 코드만 소유).
• Write only the logic you need to own (완전히 소유할 코드만 작성).
• Own everything you write (작성한 것은 완전히 소유).
• Try not to write anything that you will not own (소유유지보수하지 않을 코드는 쓰지 말것).
• Reuse everything else (나머지이미 발명된 바퀴는 전부 재사용).

Code Process

• Document the needs (요구사항 문서화).
• Experiment with tools available (선행 기술 조사).
• Document changes and constraints (변경 필요 요구사항과 한계점 판단).
• Stabilize. Claim ownership when the thing grows outside of tool boundary (소유할 것과 하지 않을 것을 구분해서 개발).
• Isolate religiously (경계를 명확히).

Memo Captured(pdf)