Qu'est-ce qui devrait prendre la priorité: yagni ou bon design?

Question

À quel point devrait Yagni Priviez les bonnes pratiques de codage et vice versa? Je travaille sur un projet au travail et je veux introduire lentement de bonnes normes de code à mes collègues (actuellement il n'y en a pas et tout est juste un peu piraté ensemble sans rime ni raison), mais après avoir créé une série de classes (nous Ne faites pas du tout TDD, ou malheureusement tout type de test unitaire), j'ai pris du recul et j'ai pensé que cela violait Yagni parce que je sais à peu près avec certitude que nous n'avons pas besoin de prolonger certaines de ces cours.

Voici un exemple concret de ce que je veux dire: j'ai une couche d'accès aux données enveloppe un ensemble de procédures stockées, qui utilise un motif de style référentiel rudimentaire avec des fonctions CRUD de base. Puisqu'il existe une poignée de méthodes dont toutes mes classes de référentiel ont besoin, j'ai créé une interface générique pour mes référentiels, appelés IRepository. Cependant, j'ai ensuite créé une interface "marqueur" (c'est-à-dire une interface qui n'ajoute aucune nouvelle fonctionnalité) pour chaque type de référentiel (par exemple ICustomerRepository) et la classe concrète implémente cela. J'ai fait la même chose avec une implémentation d'usine pour créer les objets métier à partir de données de données / ensembles de données renvoyés par la procédure stockée; La signature de ma classe de référentiel a tendance à ressembler à ceci:

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]);
    }
}

Ma préoccupation ici est que je viole Yagni parce que je sais avec une certitude à 99% qu'il n'y aura jamais de raison de donner autre chose qu'un béton CustomerFactory à ce référentiel; Comme nous n'avons pas de tests unitaires, je n'ai pas besoin d'un MockCustomerFactory Ou des choses similaires, et avoir autant d'interfaces pourrait confondre mes collègues. D'un autre côté, l'utilisation d'une implémentation en béton de l'usine semble être une odeur de conception.

Existe-t-il un bon moyen de parvenir à un compromis entre la conception de logiciels appropriée et ne pas surarchiter la solution? Je me demande si j'ai besoin d'avoir toutes les "interfaces de mise en œuvre unique" ou si je pouvais sacrifier un peu de bonne conception et avoir, par exemple, l'interface de base puis le béton unique, et ne pas m'inquiéter de la programmation de la Interface Si l'implémentation est qui sera jamais utilisée.