Une base de code simple mais monolithique vs de nombreuses dépendances clairement documentées

Question

Souvent, lorsque je commence un nouveau projet, je commence par ce que je crois être la meilleure des intentions en termes de structure du code. J'adore l'idée de nombreux petits modules qui fonctionnent bien, qui sont découplés des autres parties de la base de code et qui pourraient être réutilisés par moi-même dans d'autres projets (similaires) ou ouverts pour que d'autres puissent en profiter.

Cependant, la semaine où je cherche à mettre en production quelque chose, il y a eu plus d'une occasion où la complexité de la gestion de ces différents modules s'est avérée trop lourde (malgré une bonne documentation et méthodologie de déploiement). À cette époque, j'ai simplement changé de tactique et regroupé tous les modules dans un même référentiel, ce qui signifie que je peux tout suivre à travers différentes branches, déployer dans des environnements de test et de test, etc ...

Quels sont les avantages et les inconvénients de ces différentes approches, et comment gérez-vous le travail d'une manière ou d'une autre?

Avantages d'une base de code monolithique:

• Facile à déployer
• Facile à rollback
• Facile à ramifier/gérer tous les changements ensemble
• Non (ou moins) dépendances potentiellement complexes à documenter et gérer

Avantages des dépendances modulaires:

• réutilisabilité
• l'architecture propre (un module fait une chose bien)

Answer 1

Je ne vois pas les opposés autant que vous le faites. Prenant une expérience .NET comme exemple, je peux m'assurer que certaines parties de mon code sont orientées vers des responsabilités bien définies, je peux structurer mon code dans des espaces de noms, m'assurer que les points de contact sont bien définis et que les classes vraiment appartenir ensemble. Cependant, tout ceci peut se produire dans une seule unité de déploiement, un seul projet, une seule branche, etc. Si vous y tenez, les unités de code qui peuvent devenir réutilisables dans le contexte des projets que vous faites vont se cristalliser et ce serait le point où vous pourriez décider d'introduire une nouvelle unité de code, avec son propre artefact de déploiement, branche de contrôle de source

Answer 2

Voici un exposé de Google explaining (a little bit) how they handle their gigantic monolithic code repository. Et pourquoi ils en ont un. Par ailleurs, je ne pense pas que cela doive être opposé à un ensemble bien défini de dépendances. Je dirais même que pour gérer une base de code monolithique, il faut être très prudent avec le graphe de dépendance et les responsabilités. Parce qu'avec ce genre d'organisation, il est facile d'ajouter beaucoup de deps plus ou moins utiles ...