YAGNI 는 어느 시점 에서 좋은 코딩 관행에 우선 순위를 두어야 합니까? 나는 직장에서 프로젝트를 진행 중이며 동료들에게 좋은 코드 표준을 천천히 소개하고 싶습니다 (현재는 없으며 운율이나 이유없이 모든 것이 해킹됩니다). 그러나 일련의 클래스를 만든 후에 (우리는 TDD 또는 슬프게도 단위 테스트를 전혀하지 마십시오.) 나는 물러서서이 클래스를 확장 할 필요가 없다는 것을 확실히 알고 있기 때문에 YAGNI를 위반한다고 생각했습니다.
다음은 의미하는 구체적인 예입니다. 기본 CRUD 함수와 함께 기본 리포지토리 스타일 패턴을 사용하는 저장 프로 시저 집합을 래핑하는 데이터 액세스 계층이 있습니다. 모든 리포지토리 클래스에 필요한 소수의 메서드가 있기 때문에 리포지토리에 대한 일반 인터페이스 ()를 만들었습니다 IRepository. 그러나 각 리포지토리 유형 (예 :)에 대해 "마커"인터페이스 (예 : 새로운 기능을 추가하지 않는 인터페이스 ICustomerRepository)를 만들고 구체적인 클래스가이를 구현합니다. 저장 프로 시저에서 반환 한 DataReaders / DataSets에서 비즈니스 개체를 빌드하기 위해 Factory 구현과 동일한 작업을 수행했습니다. 내 저장소 클래스의 서명은 다음과 같습니다.
public class CustomerRepository : ICustomerRepository
{
ICustomerFactory factory = null;
public CustomerRepository() : this(new CustomerFactory() { }
public CustomerRepository(ICustomerFactory factory) {
this.factory = factory;
}
public Customer Find(int customerID)
{
// data access stuff here
return factory.Build(ds.Tables[0].Rows[0]);
}
}
여기서 내가 염려하는 것은 YAGNI를 위반한다는 것입니다. 99 % 확실하게이 CustomerFactory저장소에 구체적인 것 이외의 다른 것을 줄 이유가 없다는 것을 알고 있기 때문 입니다. 우리는 단위 테스트가 없기 때문에 MockCustomerFactory비슷한 것을 필요로하지 않으며 인터페이스가 너무 많으면 동료를 혼란스럽게 할 수 있습니다. 한편, 공장의 구체적인 구현을 사용하는 것은 디자인 냄새처럼 보인다.
적절한 소프트웨어 설계와 솔루션을 오버 아키텍트하지 않는 것 사이에 타협 할 수있는 좋은 방법이 있습니까? 나는 모든 "단일 구현 인터페이스"가 필요한지 또는 약간의 좋은 디자인을 희생 할 수 있는지, 예를 들어 기본 인터페이스와 단일 콘크리트를 가질 수 있는지에 대한 질문을하고있다. 구현이 사용될 경우 인터페이스.
(관심있는 사람, 이것을