Existe-t-il un paradigme de programmation qui encourage à rendre les dépendances extrêmement évidentes pour les autres programmeurs?

Je travaille dans un entrepôt de données qui source plusieurs systèmes via de nombreux flux et couches avec des dépendances de labyrinthe reliant divers artefacts. À peu près tous les jours, je rencontre des situations comme celle-ci: je lance quelque chose, cela ne fonctionne pas, je passe par beaucoup de code, mais quelques heures plus tard, je me rends compte que j'ai réussi à conceptualiser la carte de processus d'une infime partie de ce que je sais maintenant plus tard dans la journée est nécessaire, donc je demande à quelqu'un et ils me disent que cet autre flux doit être exécuté en premier et que si je vérifiais ici (indiquant une partie apparemment arbitraire d'une énorme pile d'autres dépendances codées), alors j'aurais vu ca. C'est incroyablement frustrant.

Si je pouvais suggérer à l'équipe que ce serait peut-être une bonne idée de faire plus pour rendre les dépendances entre les objets plus visibles et évidentes, plutôt que de les intégrer profondément dans des niveaux de code récursifs, ou même dans les données qui doit être présent car il est alimenté par un autre flux, peut-être en se référant à un paradigme logiciel bien connu et éprouvé - alors je pourrais peut-être rendre mon travail et tout le monde beaucoup plus simple.

C'est un peu difficile d'expliquer les avantages de cela à mon équipe. Ils ont tendance à accepter les choses telles qu'elles sont et à ne pas `` voir grand '' en termes de voir les avantages de pouvoir conceptualiser l'ensemble du système d'une nouvelle manière - ils ne voient pas vraiment cela si vous pouvez modéliser un énorme système efficacement, il est moins probable que vous rencontriez des inefficacités de mémoire, des contraintes uniques d'arrêt de flux et des clés en double, des données absurdes car il est beaucoup plus facile de les concevoir conformément à la vision d'origine et vous ne rencontrerez plus tard tous ces problèmes qui nous vivons maintenant, ce que je sais être inhabituel des emplois passés, mais qu'ils semblent penser comme inévitable.

Alors, quelqu'un connaît-il un paradigme logiciel qui met l'accent sur les dépendances et promeut également un modèle conceptuel commun d'un système en vue d'assurer l'adhésion à long terme à un idéal? En ce moment, nous avons à peu près un gâchis géant et la solution à chaque sprint semble être "juste ajouter cette chose ici, et ici et ici" et je suis le seul à craindre que les choses commencent vraiment à s'effondrer.

Découvrabilité

Son absence afflige de nombreuses organisations. Où est cet outil que Fred a construit à nouveau? Dans le référentiel Git, bien sûr. Où?

Le modèle logiciel qui me vient à l'esprit est Model-View-ViewModel. Pour les non-initiés, ce modèle est un mystère complet. Je l'ai expliqué à ma femme comme "cinq widgets flottant au-dessus de la table qui se parlent via une force mystérieuse." Comprenez le modèle et vous comprenez le logiciel.

De nombreux systèmes logiciels ne documentent pas leur architecture car ils supposent qu'elle s'explique d'elle-même ou émerge naturellement du code. Ce n'est pas le cas et ce n'est pas le cas. À moins que vous n'utilisiez une architecture bien définie, de nouvelles personnes se perdront. Si ce n'est pas documenté (ou bien connu), de nouvelles personnes se perdront. Et les anciens combattants se perdront aussi, une fois qu'ils auront été loin du code pendant quelques mois.

Il est de la responsabilité de l'équipe de proposer une architecture organisationnelle sensée et de la documenter. Cela inclut des choses comme

• Organisation des dossiers
• Références projets
• Documentation de classe (ce qu'elle est, ce qu'elle fait, pourquoi elle existe, comment elle est utilisée)
• Projet, module, assemblage, quelle que soit la documentation.

Il est de la responsabilité de l'équipe de rendre les choses organisées et découvrables afin que l'équipe ne réinvente pas constamment la roue.

Soit dit en passant, la notion selon laquelle «le code devrait être auto-documenté» n'est que partiellement correcte. Bien qu'il soit vrai que votre code doit être suffisamment clair pour que vous n'ayez pas à expliquer chaque ligne de code avec un commentaire, les relations entre les artefacts tels que les classes, les projets, les assemblys, les interfaces et autres ne sont pas évidentes, et restent doivent être documentés.

La meilleure façon d'aborder ce genre de problèmes est progressivement. Ne soyez pas frustré et proposez de vastes changements architecturaux. Ceux-ci ne seront jamais approuvés et le code ne s'améliorera jamais. Cela suppose que vous pouvez même déterminer les modifications architecturales larges et correctes à apporter, ce qui est peu probable.

Ce qui est probable, c'est que vous pourriez déterminer un changement plus petit qui vous aurait aidé avec le problème spécifique que vous venez de résoudre. Peut-être en inversant certaines dépendances, en ajoutant de la documentation, en créant une interface, en écrivant un script qui avertit d'une dépendance manquante, etc. Proposez donc cette petite modification à la place. Encore mieux, selon la culture de votre entreprise, ils peuvent tolérer ou même s'attendre à ce que vous apportiez des améliorations comme celle-ci dans le cadre de votre tâche d'origine.

Lorsque vous apportez ces changements mineurs à une partie régulière de votre travail et, par votre exemple, encouragez les autres à le faire également, ils s'accumulent vraiment au fil du temps. Beaucoup plus efficace que de pleurnicher sur des changements plus importants que vous n'êtes pas autorisé à effectuer.

Architecture.

Il n'y a pas de principe ou de pratique unique, spécifique et universel qui résout les problèmes de découverte et de maintenabilité qui s'appliquent à tous les aspects de tous les logiciels. Mais, le terme large pour désigner ce qui rend un projet sain d'esprit est l' architecture.

Votre architecture est l'ensemble des décisions concernant chaque point de confusion potentielle (ou historique) - y compris la désignation de la façon dont les décisions architecturales sont prises et documentées. Tout ce qui concerne le processus de développement, la structure des dossiers, la qualité du code, les modèles de conception, etc. sont toutes des choses qui peuvent entrer dans votre architecture, mais aucune d'entre elles n'est une architecture.

Idéalement, ces règles sont unifiées par une singularité d'esprit.

Une petite équipe peut certainement créer une architecture en collaboration. Mais, avec des opinions différentes, cela peut rapidement conduire à une architecture très schizophrénique qui ne sert pas à maintenir votre santé mentale. Le moyen le plus simple de vous assurer que votre architecture, et les nombreux TLA et modèles qu'elle contient, sont au service de la réussite de l'équipe avec une singularité d'esprit est d'en confier la responsabilité à un seul esprit.

Or, cela ne nécessite pas nécessairement un «architecte» pour pontifier . Et, alors que certaines équipes peuvent vouloir qu'une personne expérimentée prenne simplement ces décisions, le point principal est que quelqu'un doit posséder l'architecture, surtout à mesure que l'équipe grandit. Quelqu'un garde le pouls de l'équipe, modère les discussions architecturales, documente les décisions, surveille les décisions et travaille à l'avenir pour se conformer à l'architecture et à sa philosophie.

Je ne suis pas un grand fan d'une seule personne prenant toutes les décisions; mais identifier un «architecte» ou un «propriétaire de produit technique» chargé de modérer les discussions architecturales et de documenter les décisions combat un plus grand mal: la diffusion de la responsabilité qui ne conduit à aucune architecture perceptible.

Bienvenue en génie logiciel (dans les deux sens);) C'est une bonne question, mais il n'y a vraiment pas de réponses faciles, comme je suis sûr que vous le savez. Il s'agit vraiment d'évoluer vers de meilleures pratiques au fil du temps, de former les gens à être plus compétents (par définition, la plupart des gens de l'industrie ont des compétences médiocres) ...

Le génie logiciel en tant que discipline souffre de le construire d'abord et de le concevoir au fur et à mesure, en partie par opportunisme et en partie par nécessité. C'est juste la nature de la bête. Et bien sûr, les hacks s'appuient sur les hacks au fil du temps, car les codeurs susmentionnés mettent rapidement en place des solutions fonctionnelles qui répondent souvent aux besoins à court terme au prix de l'introduction de dettes techniques.

Le paradigme que vous devez utiliser est essentiellement d'obtenir de meilleures personnes, de former les personnes que vous avez bien et de souligner l'importance de prendre du temps sur la planification et l'architecture. On ne peut pas être facilement "Agile" quand on travaille avec un système monolithique. La mise en place de modifications, même minimes, peut prendre beaucoup de temps. La mise en place d'un excellent processus de documentation de haut niveau aidera également les personnes clés à maîtriser le code plus rapidement.

Les idées sur lesquelles vous pourriez vous concentrer seraient (au fil du temps, progressivement) d'isoler et de refactoriser les éléments clés du système de manière à les rendre plus modulaires et découplés, lisibles, maintenables. L'astuce consiste à travailler en fonction des exigences commerciales existantes, de sorte que la réduction de la dette technique puisse se faire simultanément avec la fourniture d'une valeur commerciale visible. La solution consiste donc à améliorer les pratiques et les compétences et à essayer d'avancer davantage vers une réflexion architecturale à long terme, comme je peux vous le dire.

Notez que j'ai répondu à cette question du point de vue de la méthodologie de développement logiciel plutôt que du point de vue de la technique de codage, car c'est vraiment un problème bien plus important que les détails du codage ou même le style architectural. C'est vraiment une question de comment vous planifiez le changement.

J'aime l'idée de @ RobertHarvey sur les conventions et je pense qu'elles aident. J'aime aussi l'idée de @ KarlBielefeldt de "documenter au fur et à mesure" et je sais que c'est essentiel parce que c'est la seule façon de maintenir la documentation à jour. Mais je pense que l'idée générale est que documenter comment trouver tous les morceaux de votre code, les construire et les déployer est important!

J'ai récemment envoyé un e-mail à un important projet open source qui avait une configuration XML qui générait du code était totalement non documenté. J'ai demandé au responsable: "Où ce processus de génération de code XML est-il documenté? Où est la configuration de la base de données de test documentée?" et il a dit: "Ce n'est pas le cas." Il s'agit essentiellement d'un projet à contributeur unique et maintenant je sais pourquoi.

Écoutez, si vous êtes cette personne et que vous lisez ceci, j'apprécie vraiment ce que vous faites. J'adore pratiquement les fruits de vos travaux! Mais si vous avez passé une heure à documenter la façon dont vos éléments vraiment créatifs sont assemblés, je pourrais passer quelques jours à coder de nouvelles fonctionnalités qui pourraient vous aider. Face au mur de briques du "manque de documentation n'est pas un problème", je ne vais même pas essayer.

Dans une entreprise, un manque de documentation est une énorme perte de temps et d'énergie. Des projets comme celui-ci sont souvent confiés à des consultants qui coûtent encore plus cher, juste pour qu'ils puissent comprendre des choses de base telles que «où sont toutes les pièces et comment s'assemblent-elles».

En conclusion

Ce qu'il faut, ce n'est pas tant une technologie ou une méthodologie, mais un changement de culture; une conviction partagée que documenter comment les choses sont construites et pourquoi est important. Cela devrait faire partie des revues de code, une condition pour passer à la production, liée aux augmentations. Lorsque tout le monde y croit et agit en conséquence, les choses vont changer. Sinon, ce sera comme ma contribution open source qui a échoué.

Pour répondre à la question telle qu'elle est posée (plutôt que de vous conseiller sur votre situation particulière):

Le paradigme de programmation connu sous le nom de programmation fonctionnelle pure exige que tout ce qui affecte la sortie d'une fonction soit spécifié dans les paramètres d'entrée. Il n'y a pas de dépendances cachées ou de variables globales ou d'autres forces mystérieuses agissant de manière invisible à travers la base de code. Il n'y a pas de couplage temporel "vous devez faire ce premier".

Chaque entrepôt de données est différent, mais vous pouvez faire beaucoup pour vous faciliter la tâche.

Pour commencer, chaque ligne de la base de données avait une colonne DATE_ADDED et DATA_UPDATED afin que nous puissions voir quand elle a été ajoutée à la base de données et quand elle a été modifiée. Nous avions également une colonne SOURCE_CODE afin que nous puissions suivre où chaque bit de données est entré dans le système.

Ensuite, nous avions des outils communs qui traversaient tous nos entrepôts de données tels que les tris, les correspondances de table, les trancheuses et les découpeuses, etc.

Le code sur mesure a été maintenu à un minimum absolu et même dans ce cas, il a dû être confirmé par différents styles de codage et de rapport.

Je suppose que vous connaissez déjà les suites ETL . Il y a beaucoup de fonctionnalités que vous obtenez gratuitement ces jours-ci qui n'étaient pas présentes lorsque j'étais dans le jeu il y a une dizaine d'années.

Vous voudrez peut-être également examiner les data marts pour présenter une version plus conviviale et aseptisée de votre entrepôt de données. Ce n'est pas une solution miracle, bien sûr, mais cela pourrait aider à résoudre certains problèmes plutôt que d'avoir à reconstruire / corriger votre entrepôt de données.

Je ne sais pas dans quelle mesure cela est pertinent pour votre cas, il existe des stratégies pour rendre les dépendances plus visibles et la maintenance générale du code-

• Évitez les variables globales, utilisez plutôt des paramètres. Cela s'applique également aux appels multilingues.
• Évitez autant que possible de modifier / muter les valeurs des variables. Créez une nouvelle variable et utilisez, si vous devez modifier la valeur, si possible.
• Rendez le code modulaire. S'il n'est pas possible de décrire ce que fait (pas comment) la portion est réellement en train de faire dans une phrase simple, décomposez-la en modules qui satisfont la condition.
• Nommez correctement vos portions de code. Lorsque vous pouvez réellement décrire ce qu'une portion de code fait en termes simples, ces termes deviennent le nom de la portion. Ainsi, le code devient auto-documenté à travers les noms des modules / classes / fonctions / procédures / méthodes etc.
• Testez votre code. Testez si les entités de votre code justifient leurs noms, discuté au point précédent.
• Consigner les événements dans le code. Maintenez au moins deux niveaux de journal. Le premier est toujours activé (même en production) et enregistre uniquement les événements critiques. Et utilisez l'autre pour tout enregistrer, mais vous pouvez l'activer ou le désactiver.
• Trouvez et utilisez des outils appropriés pour parcourir, maintenir et développer votre base de code. Même une simple option «Rechercher tout» de Visual Studio Code m'a beaucoup simplifié la vie dans certains cas.