지름길을 방지하기 위해서는 먼저 지름길 자체를 파악해야 한다.

11.1. 왜 지름길은 깨진 창문 같을까?

• 깨진 창문 이론

코드 작업에 적용될 때의 의미는 다음과 같ㄷ다

• 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기가 쉽다.
• 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.
• 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.

이 모든 것을 고려하면 레거시 코드가 많아져 품질이 심하게 낮아질 것이다.

11.2. 깨끗한 상태로 시작할 책임

우리는 깨진 창문 심리에 무의식적으로 영향을 받는다. 그래서 가능한 한 지름길을 거의 쓰지 않고 기술 부채를 지지않은 채로 프로젝트를 깨끗하게 시작하는 것이 중요하다. 지름길이 몰래 스며드는 순간 깨진 창문과 같아져 버려 더 많은 지름길을 끌어들이기 때문이다.

소프트웨어 프로젝트는 대개 큰 비용이 들고 장기적인 노력을 필요로 하기 때문에 깨진 창문을 막는 것이 소프트웨어 개발자들의 아주 막대한 책임이다.

때로는 지름길을 취하는 것이 더 실용적일 때도 있다. 작업 중인 부분이 프로젝트 전체로 봤을 때 그리 중요하지 않은 부분이거나, 프로토타이핑 작업 중이거나, 경제적인 이유가 있을 수도 있다.

의도적인 지름길에 대해서는 세심하게 잘 기록해둬야 한다.

11.3. 유스케이스 간 모델 공유하기

유스케이스마다 다른 입출력 모델을 가져야 한다고 했었다. 즉, 입력 파라미터의 타입과 반환값의 타입이 다라야 한다는 뜻이다.

유스케이스 간에 입출력 모델을 공유하게 되면 유스케이스들 사이에 결합이 생긴다.

공유로 인한 영향은 SendMoneyUseCase와 RevokeActivityUseCase가 결합된다는 것이다. 공유하고 있는 SendMoneyCommand 클래스가 변경되면 두 유스케이스 모두 영향을 받는다. 단일 책임 원칙에서 말하는 ‘변경할 이유’를 공유하는 것이다. 출력 모델을 공유하는 경우에도 마찬가지다.

유스케이스 간 입출력 모델을 공유하는 것이 유스케이스들이 기능적으로 묶여 있을 때 유효하다. 즉, 특정 요구사항을 공유할 때 괜찮다는 의미다. 이 경우 특정 세부사항을 변경할 경우 실제로 두 유스케이스 모두에 영향을 주고 싶은 것이다.