Quand préférer une solution généralisée à la résolution de cas spécifiques

En programmation, nous sommes souvent confrontés à un choix: couvrir chaque cas d'utilisation envisageable individuellement ou résoudre le problème général:

Il est évident que la résolution du problème immédiat est plus rapide, mais la création d'une solution généralisée fera gagner du temps à l'avenir.

Comment savoir quand il vaut mieux essayer de couvrir une liste finie de cas, ou créer un système générique pour couvrir toutes les possibilités?

D'abord, vous passez le sel. Ensuite, vous passez le poivre. Ensuite, vous passez le parmesan râpé. À ce stade, vous avez suffisamment d'expérience pour commencer à développer un système général de passage des condiments.

Cela fonctionne dans les projets logiciels de la même manière: utilisez des systèmes à usage spécial que vous développez comme étapes d'apprentissage vers des processus généralisés, donc quand il est temps de démarrer votre système à usage général, vous avez une meilleure confiance dans ce que vous construisez, car vous avez plusieurs systèmes spéciaux sous votre ceinture.

Comment savoir quand il vaut mieux essayer de couvrir une liste finie de cas, ou créer un système générique pour couvrir toutes les possibilités?

Expérience.

La seule façon de savoir est d'avoir essayé un chemin avant, vu comment ça vous a mordu dans le cul (ou vous avez perdu beaucoup de temps). Répétez jusqu'à ce que vous soyez moins dans le cul.

Même alors, vous ne pas vraiment savoir ; vous avez juste une meilleure supposition.

Pour s'appuyer sur les réponses de dasblinkenlight et Paddy3118 , si vous n'avez pas plusieurs cas à implémenter, vous n'avez pas besoin de généraliser! La raison pour laquelle le dessin animé XKCD est drôle est qu'il dénonce la généralisation prématurée . Lorsqu'on lui a demandé de passer le sel, le personnage invisible saute immédiatement à "développer un système pour passer des condiments arbitraires" quand tout le premier caractère demandé était le sel. C'est une bonne blague pour les développeurs, car je pense que nous avons tous vu des cas de généralisation prématurée.

Le principe opposé à la généralisation prématurée est YAGNI (You Ain't Gonna Need It). Il existe de nombreux documents à ce sujet sur le Web, mais YAGNI souligne essentiellement un certain nombre de risques à généraliser sans bénéficier de plusieurs cas d'utilisation réels, y compris la possibilité que plusieurs cas d'utilisation n'apparaissent pas réellement. Ou, plus subtilement, l'absence de cas d'utilisation réels oblige à faire des hypothèses sur ce qui sera nécessaire à l'avenir. Ces hypothèses peuvent être, et sont souvent, incorrectes.

Il semble plus facile d'être générique dans le petit, c'est-à-dire de ne pas créer une classe pour gérer une table de recherche qui mappe des entiers à des chaînes lorsque vous pouvez créer une classe de dictionnaire raisonnable qui gère n'importe quelle paire de types (où le premier type prend en charge un certain type de Comparaison).

Dans une vie antérieure, j'ai réalisé de nombreux projets d'automatisation industrielle pour des machines qui manipulaient une bande continue de matériaux. Acier, aluminium, papier, plastique, .... Vous le déroulez à une extrémité et le retrouvez à l'autre après avoir fait quelque chose d'utile au milieu. Dans une industrie, vous commencez par la «bobine de gain», et non par le «dérouleur». Si vous utilisez la mauvaise terminologie, vous êtes un idiot aux yeux de plusieurs millions de dollars du client. Vous seriez étonné de voir à quel point peu de données pourraient être extraites pour être réutilisées d'un projet à l'autre. OTOH, on pourrait souvent créer un cadre ou un modèle comme point de départ. Il serait personnalisé pour le travail à accomplir, mais il aurait au moins l'avantage de tirer des enseignements des projets antérieurs. Et tout le monde dans l'équipe savait d'où nous partions.

Faites-le une fois, faites-le deux fois, faites-le trois fois, généralisez.

Un, deux, beaucoup!

Dans le deuxième cas, vous devriez penser à la généralisation. Lorsqu'on vous demande le troisième, vous devez le fournir à partir du code généralisé et utiliser le premier et le deuxième cas précédemment résolus individuellement comme cas de test.