J'espère que ce n'est pas une question trop générale; Je pourrais vraiment utiliser quelques conseils expérimentés.

Je suis récemment devenu le seul "ingénieur SW" dans un assez petit magasin de scientifiques qui ont passé les 10 à 20 dernières années à bricoler une vaste base de code. (Il a été écrit dans un langage pratiquement obsolète: G2 - pensez à Pascal avec des graphiques). Le programme lui-même est un modèle physique d’une usine de traitement chimique complexe; l'équipe qui l'a écrite possède une connaissance approfondie du domaine, mais peu ou pas de formation formelle sur les bases de la programmation. Ils ont récemment appris quelques leçons difficiles sur les conséquences d'une gestion de configuration non existante. Leurs efforts de maintenance sont également grandement entravés par la vaste accumulation de "boues" non documentées dans le code lui-même. Je vous épargne la "politique" de la situation (il y a toujours politique!), mais il suffit de dire qu’il n’ya pas consensus sur ce qui est nécessaire pour la voie à suivre.

Ils m'ont demandé de commencer à présenter à l'équipe certains des principes du développement logiciel moderne. Ils veulent que je présente certaines des pratiques et stratégies standard de l'industrie concernant les conventions de codage, la gestion du cycle de vie, les modèles de conception de haut niveau et le contrôle de la source. Franchement, la tâche est assez ardue et je ne sais pas par où commencer.

Au départ, je suis enclin à leur enseigner certains des concepts centraux de The Pragmatic Programmer , ou Factler Refactoring ("Code Smells", etc.). J'espère également présenter un certain nombre de méthodologies Agiles. Mais finalement, pour être efficace, je pense que je vais devoir affiner 5 à 7 principes fondamentaux; en d’autres termes, quels sont les principes ou pratiques les plus importants qu’ils peuvent réellement commencer à mettre en œuvre et qui leur donneront le plus pour leur argent.

Voilà donc ma question: qu'incluez- vous dans votre liste des stratégies les plus efficaces pour redresser les spaghettis (et les prévenir à l'avenir)?

Avant-propos

Il s’agit là d’une tâche décourageante, et il ya beaucoup de chemin à parcourir. Je propose donc humblement de donner à votre équipe un guide assez complet contenant des outils et du matériel pédagogique appropriés.

Rappelez-vous: il s’agit de lignes directrices , qui, en tant que telles, doivent être adoptées, adaptées ou supprimées en fonction des circonstances.

Méfiez-vous: si tout cela se déversait d'une équipe à la fois, cela risquerait fort d'échouer. Vous devriez essayer de choisir des éléments qui vous donneraient le meilleur pour la transpiration, et les introduire lentement, un à la fois.

Remarque: tout cela ne s'applique pas directement aux systèmes de programmation visuels tels que G2. Pour plus de détails sur la manière de traiter ces problèmes, voir la section Addenda à la fin.

Résumé pour l'impatient

• Définir une structure de projet rigide , avec:
  • modèles de projet ,
  • conventions de codage ,
  • systèmes de construction familiers ,
  • et des ensembles de directives d'utilisation pour votre infrastructure et vos outils.
• Installez un bon SCM et assurez-vous qu'ils savent l'utiliser.
• Dirigez-les vers les bons IDE pour leur technologie et assurez-vous qu'ils savent comment les utiliser.
• Implémentez des vérificateurs de qualité du code et des rapports automatiques dans le système de génération.
• Associez le système de compilation aux systèmes d' intégration et d'inspection continues .
• À l’aide de ce qui précède, identifiez les "points chauds" et le refactor de la qualité du code .

Maintenant pour la version longue ... Attention, préparez-vous!

La rigidité est (souvent) bonne

Cet avis est controversé, car la rigidité est souvent perçue comme une force contre vous. C'est vrai pour certaines phases de certains projets. Mais une fois que vous le considérez comme un support structurel, un cadre qui élimine les incertitudes, vous réduisez considérablement le temps et les efforts perdus. Faites-le travailler pour vous, pas contre vous.

Rigidité = Processus / Procédure .

Le développement de logiciels nécessite de bons processus et procédures pour exactement les mêmes raisons que les usines chimiques ont des manuels, des procédures, des exercices et des directives d'urgence: prévenir les mauvais résultats, accroître la prévisibilité, maximiser la productivité ...

La rigidité vient avec modération!

Rigidité de la structure du projet

Si chaque projet est doté de sa propre structure, vous (et les nouveaux venus) êtes perdus et devez reprendre à zéro chaque fois que vous les ouvrez. Vous ne le souhaitez pas dans un magasin de logiciels professionnel, ni dans un laboratoire.

Rigidité des systèmes de construction

Si chaque projet est différent, il y a de fortes chances qu'ils construisent également différemment . Une construction ne devrait pas nécessiter trop de recherche ou de travail de conjecture. Vous voulez être en mesure de faire la chose canonique et pas besoin de se soucier des détails: configure; make install, ant, mvn install, etc ...

Réutiliser le même système de compilation et le faire évoluer au fil du temps assure également un niveau de qualité constant.

Vous avez besoin d'un rapide READMEpour indiquer les détails du projet et guider avec élégance l'utilisateur / développeur / chercheur, le cas échéant.

Cela facilite également grandement d'autres parties de votre infrastructure de construction, à savoir:

• intégration continue ,
• inspection continue .

Alors gardez votre build (comme vos projets) à jour, mais renforcez-le au fil du temps et signalez plus efficacement les violations et les mauvaises pratiques.

Ne réinventez pas la roue et réutilisez ce que vous avez déjà fait.

Lecture recommandée:

• Intégration continue: améliorer la qualité des logiciels et réduire les risques (Duval, Matyas, Glover, 2007)
• Livraison continue: publication des versions de logiciels via l'automatisation de la construction, des tests et du déploiement (Humble, Farley, 2010)

Rigidité dans le choix des langages de programmation

Vous ne pouvez pas vous attendre, en particulier dans un environnement de recherche, à ce que toutes les équipes (et encore moins tous les développeurs) utilisent le même langage et la même technologie. Cependant, vous pouvez identifier un ensemble d'outils "officiellement supportés" et encourager leur utilisation. Le reste, sans justification, ne devrait pas être autorisé (au-delà du prototypage).

Gardez votre pile de technologies simple, et maintenez au minimum les compétences requises ainsi qu'un éventail de compétences: un noyau fort.

Rigidité des conventions et directives de codage

Les conventions et directives de codage vous permettent de développer à la fois une identité d'équipe et un jargon partagé . Vous ne voulez pas vous tromper dans terra incognita à chaque fois que vous ouvrez un fichier source.

Des règles insensées qui rendent la vie plus difficile ou interdisent les actions de manière explicite dans la mesure où les commits sont refusés sur la base de simples violations simples constituent un fardeau. Pourtant:

• un ensemble de règles de base bien pensé élimine beaucoup de gémissements et de réflexions: personne ne devrait rompre en aucune circonstance;

• et un ensemble de règles recommandées fournissent des indications supplémentaires.

Approche personnelle: Je suis agressif en ce qui concerne les conventions de codage, certains disent même nazi , parce que je crois en une lingua franca , un style reconnaissable pour mon équipe. Lorsque le code merdique est enregistré, il se démarque comme une plaie froide sur le visage d'une star hollywoodienne: il déclenche automatiquement une révision et une action. En fait, j'ai parfois été jusqu'à préconiser l'utilisation de points d'ancrage pré-commit pour rejeter les commits non conformes. Comme mentionné, cela ne devrait pas être excessivement fou et entraver la productivité: cela devrait la conduire. Introduisez-les lentement, surtout au début. Mais il est bien préférable de passer autant de temps à réparer un code défectueux que vous ne pouvez pas travailler sur de vrais problèmes.

Certaines langues l'appliquent même de par leur conception:

• Java était destiné à réduire la quantité de merde terne que vous pouvez écrire avec elle (bien que beaucoup réussissent à le faire).

• La structure de bloc de Python par indentation est une autre idée en ce sens.

• Go, avec son gofmtoutil, qui enlève complètement tout débat et effort ( et ego !! ) inhérents au style: courez gofmtavant de vous engager.

Assurez-vous que le code ne pourrit pas. Les conventions de code , l'intégration continue et l'inspection continue , la programmation par paires et la révision de code sont votre arsenal contre ce démon.

De plus, comme vous le verrez ci-dessous, le code est de la documentation et c'est un autre domaine dans lequel les conventions encouragent la lisibilité et la clarté.

Rigidité de la documentation

La documentation va de pair avec le code. Le code lui-même est une documentation. Mais il doit y avoir des instructions claires sur la façon de construire, d’utiliser et de maintenir les choses.

Utiliser un seul point de contrôle pour la documentation (comme un wiki ou un DMS) est une bonne chose. Créez des espaces pour les projets, des espaces pour des plaisanteries et des expériences plus aléatoires. Demandez à tous les espaces de réutiliser les règles et conventions communes. Essayez de faire partie de l'esprit d'équipe.

La plupart des conseils concernant le code et les outils s’appliquent également à la documentation.

Rigidité dans les commentaires de code

Les commentaires de code, comme mentionné ci-dessus, sont également une documentation Les développeurs aiment exprimer leurs sentiments sur leur code (principalement fierté et frustration, si vous me le demandez). Il n’est donc pas inhabituel qu’ils expriment ces choses en termes non équivoques (ou même de code), alors qu’un texte plus formel aurait pu véhiculer le même sens avec moins de fictions ou de drames. C’est acceptable de laisser passer quelques-uns pour des raisons historiques et amusantes: cela fait également partie du développement d’une culture d’équipe . Mais il est très important que tout le monde sache ce qui est acceptable et ce qui ne l’est pas, et ce bruit de commentaire n’est que cela: du bruit .

Rigidité dans les journaux de validation

Les journaux de validation ne sont pas une "étape" ennuyeuse et inutile du cycle de vie de votre SCM: vous ne le sautez PAS pour arriver à la maison à temps ou pour continuer la tâche suivante, ou pour rattraper les amis qui sont partis pour le déjeuner. Ils sont importants et, comme le meilleur vin, plus le temps passe, plus ils ont de la valeur. Alors faites-les bien. Je suis sidérée quand je vois des collègues écrire des phrases uniques pour des commits géants ou des piratages non évidents.

Les commits sont effectués pour une raison, et cette raison N'EST PAS toujours clairement exprimée par votre code et la ligne de journal de validation que vous avez entrée. Il y a plus que ça.

Chaque ligne de code a une histoire et une histoire . Les diffs peuvent raconter son histoire, mais vous devez écrire son histoire.

Pourquoi ai-je mis à jour cette ligne? -> Parce que l'interface a changé.

Pourquoi l'interface a-t-elle changé? -> Parce que la bibliothèque L1 la définissant a été mise à jour.

Pourquoi la bibliothèque a-t-elle été mise à jour? -> Parce que la bibliothèque L2, dont nous avons besoin pour la fonctionnalité F, dépendait de la bibliothèque L1.

Et quelle est la fonctionnalité X? -> Voir la tâche 3456 dans le suivi des problèmes.

Ce n'est pas mon choix de SCM, et peut-être pas le meilleur pour votre laboratoire non plus; mais réussit Gitet essaie de vous forcer à écrire de bons journaux plus que la plupart des autres systèmes SCM, en utilisant short logset long logs. Liez l'ID de la tâche (oui, vous en avez besoin) et laissez un résumé générique pour le shortlog, et développez-le dans le long journal: écrivez le récit de l'ensemble de modifications .

C'est un journal: il est ici pour garder trace et enregistrer les mises à jour.

Règle de base: Si vous cherchiez quelque chose à propos de ce changement plus tard, votre journal est-il susceptible de répondre à votre question?

Les projets, la documentation et le code sont VIVANTS

Gardez-les synchronisés, sinon ils ne formeront plus cette entité symbiotique. Cela fonctionne à merveille quand vous avez:

• effacez les journaux de validations dans votre GDS, avec des liens vers les ID de tâches dans votre suivi des problèmes,
• où les tickets de ce traqueur sont eux-mêmes liés aux changesets de votre SCM (et éventuellement aux builds de votre système de CI),
• et un système de documentation qui relie à tous ceux-ci.

Le code et la documentation doivent être cohérents .

Rigidité à l'essai

Règles de base:

• Tout nouveau code doit comporter (au moins) des tests unitaires.
• Tout code hérité remanié doit être accompagné de tests unitaires.

Bien sûr, ceux-ci ont besoin de:

• pour réellement tester quelque chose de précieux (ou ils sont une perte de temps et d'énergie),
• être bien écrit et commenté (comme tout autre code que vous archivez).

Ils constituent également de la documentation et aident à définir le contrat de votre code. Surtout si vous utilisez TDD . Même si vous ne le faites pas, vous en avez besoin pour votre tranquillité d'esprit. Ils constituent votre filet de sécurité lorsque vous intégrez un nouveau code (maintenance ou fonctionnalité) et votre tour de guet pour vous prémunir contre la pourriture du code et les défaillances environnementales.

Bien sûr, vous devriez aller plus loin et avoir des tests d'intégration et des tests de régression pour chaque bogue reproductible que vous corrigez.

Rigidité dans l'utilisation des outils

Les développeurs / scientifiques occasionnels ont la possibilité d'essayer un nouveau vérificateur statique sur la source, de générer un graphique ou un modèle à l'aide d'un autre, ou de mettre en œuvre un nouveau module à l'aide d'un DSL. Mais il est préférable de disposer d’un ensemble d’outils canoniques que tous les membres de l’équipe devraient connaître et utiliser.

Au-delà, laissez les membres utiliser ce qu'ils veulent, pourvu qu'ils soient TOUS:

• productif ,
• PAS régulièrement besoin d'aide
• PAS de vous adapter régulièrement à votre infrastructure générale ,
• NE PAS perturber votre infrastructure (en modifiant des zones communes telles que le code, le système de construction, la documentation, etc.),
• N'affectant pas le travail des autres ,
• POUVOIR exécuter en temps voulu toute tâche demandée .

Si ce n'est pas le cas, veillez à ce qu'ils retombent sur les valeurs par défaut.

Rigidité vs polyvalence, adaptabilité, prototypage et urgences

La flexibilité peut être bonne. Laisser quelqu'un utiliser occasionnellement un hack, une approche rapide ou un outil favori de votre animal de compagnie pour faire le travail, c'est bien. Ne laissez JAMAIS cela devenir une habitude et JAMAIS ce code ne devienne la base de code à prendre en charge.

L'esprit d'équipe, ça compte

Développer un sentiment de fierté dans votre base de code

• Développer un sentiment de fierté dans le code
  • Utilisez des panneaux muraux
    • tableau des leaders pour un jeu d'intégration continue
    • panneaux muraux pour la gestion des problèmes et le comptage des défauts
  • Utiliser un tracker problème / bug tracker

Évitez les jeux de blâme

• Utilisez les jeux d’Intégration Continue / d’Inspection Continue: cela favorise une concurrence rude et productive .
• FAITES ATTENTION aux défauts: c'est juste un bon ménage.
• DO identifier les causes profondes : il est juste processus futur épreuvage.
• MAIS N'AFFUSEZ PAS DE RESPONSABLE : c'est contre-productif.

Il s’agit du code, pas des développeurs

Rendre les développeurs conscients de la qualité de leur code, MAIS leur faire voir le code comme une entité isolée et non comme une extension d'eux-mêmes, qui ne peut être critiquée.

C'est un paradoxe: vous devez encourager les programmes sans ego pour un lieu de travail sain, mais compter sur l'ego à des fins de motivation.

De scientifique à programmeur

Les personnes qui n'apprécient pas et ne sont pas fières du code ne le produisent pas. Pour que cette propriété émerge, ils doivent découvrir à quel point il peut être amusant et précieux. Le professionnalisme et le désir de faire du bien ne suffisent pas: il faut de la passion. Vous devez donc transformer vos scientifiques en programmeurs (au sens large).

Quelqu'un a affirmé dans ses commentaires qu'après 10 à 20 ans d'expérience d'un projet et de son code, tout le monde aurait un sentiment d'attachement. Je me trompe peut-être mais je suppose qu'ils sont fiers des résultats du code, du travail et de son héritage, et non du code lui-même ou de l'acte de l'écrire.

Par expérience, la plupart des chercheurs considèrent le codage comme une nécessité ou, au mieux, comme une distraction amusante. Ils veulent juste que ça marche. Ceux qui y sont déjà très familiarisés et qui s'intéressent à la programmation sont beaucoup plus faciles à persuader d'adopter les meilleures pratiques et les technologies de commutation. Vous devez les obtenir à mi-chemin.

La maintenance du code fait partie des travaux de recherche

Personne ne lit les documents de recherche de merde. C'est pourquoi ils sont examinés par des pairs, relus, corrigés, affinés, réécrits et approuvés à maintes reprises jusqu'à ce qu'ils soient prêts à être publiés. La même chose s'applique à une thèse et à une base de code!

Expliquez clairement que la refactorisation et l'actualisation constantes d'une base de code empêchent la pourriture du code, réduisent la dette technique et facilitent la réutilisation et l'adaptation futures du travail à d'autres projets.

Pourquoi tout ça??!

Pourquoi nous occupons-nous de tout ce qui précède? Pour la qualité du code . Ou est-ce un code de qualité ...?

Ces directives visent à guider votre équipe vers cet objectif. Certains aspects le font simplement en leur montrant le chemin à suivre et en le laissant faire (ce qui est beaucoup mieux) et d'autres le prennent par la main (mais c'est comme cela que vous éduquez et développez des habitudes).

Comment savez-vous que l'objectif est à portée de main?

La qualité est mesurable

Pas toujours quantitativement, mais c'est mesurable . Comme mentionné précédemment, vous devez développer un sentiment de fierté au sein de votre équipe. Il est essentiel de montrer des progrès et d'obtenir de bons résultats. Mesurez la qualité du code régulièrement et montrez les progrès réalisés entre les intervalles et leur importance. Faites des rétrospectives pour réfléchir à ce qui a été fait et à la manière dont cela a amélioré ou aggravé la situation.

Il existe d'excellents outils d' inspection continue . Sonar est populaire dans le monde Java, mais il peut s'adapter à toutes les technologies. Et il y en a beaucoup d'autres. Gardez votre code sous le microscope et recherchez ces insectes et microbes agaçants.

Mais que se passe-t-il si mon code est déjà de la merde?

Tout ce qui précède est amusant et mignon, comme un voyage à Never Land, mais ce n’est pas si facile à faire si vous avez déjà du code de merde (une pile de fumées et de mauvaises odeurs) et une équipe peu disposée à changer.

Voici le secret: vous devez commencer quelque part .

Anecdote personnelle: Dans un projet, nous avons travaillé avec une base de code pesant à l'origine plus de 650 000 Java LOC, plus de 200 000 lignes de JSP, plus de 40 000 JavaScript LOC et plus de 400 Mo de dépendances binaires.

Après environ 18 mois, nous avons 500 000 Java LOC (MOSTLY CLEAN) , 150 000 lignes de JSP et 38 000 JavaScript LOC, avec des dépendances pouvant atteindre à peine 100 Mo (et celles-ci ne font plus partie de notre SCM!).

Comment avons-nous fait ça? Nous venons de faire tout ce qui précède. Ou essayé fort.

C'est un effort d'équipe, mais nous introduisons lentement dans notre processus des réglementations et des outils pour surveiller le rythme cardiaque de notre produit, tout en réduisant à la hâte le "gras": code de merde, dépendances inutiles ... Nous n'avons pas arrêté tout développement Pour ce faire, nous avons parfois des périodes de calme relatif où nous sommes libres de devenir fous sur le code et de le déchirer, mais la plupart du temps, nous le faisons tous en passant par défaut au mode "révision et refactorisation" à chaque fois que nous en avons l'occasion. : pendant les builds, pendant le déjeuner, pendant les sprints de corrections de bugs, le vendredi après-midi ...

Il y avait de gros "travaux" ... Passer de notre système de build géant Ant à plus de 8500 XML à un multi-module Maven était l'un d'entre eux. Nous avons ensuite eu:

• des modules clairs (ou du moins c'était déjà beaucoup mieux, et nous avons encore de grands projets pour l'avenir),
• gestion automatique des dépendances (pour une maintenance et des mises à jour faciles, et pour supprimer les dépôts inutiles),
• des constructions plus rapides, plus faciles et reproductibles,
• rapports quotidiens sur la qualité.

Un autre exemple est l’injection de «ceintures d’outils utilitaires», alors même que nous essayions de réduire les dépendances: Google Guava et Apache Commons affinent votre code et réduisent beaucoup la surface pour les bogues dans votre code.

Nous avons également persuadé notre service informatique que peut-être utiliser nos nouveaux outils (JIRA, Fisheye, Crucible, Confluence, Jenkins) était meilleur que ceux en place. Nous avions encore besoin de traiter certains problèmes que nous méprisions (QC, Sharepoint et SupportWorks ...), mais l'expérience a été globalement améliorée, avec encore de la place.

Et chaque jour, il y a maintenant un filet entre une à plusieurs dizaines d’engagements qui ne traitent que de la réparation et de la refactorisation. Nous cassons parfois des choses (vous avez besoin de tests unitaires, et vous feriez mieux de les écrire avant de les refactoriser), mais globalement, le bénéfice pour notre moral ET pour le produit a été énorme. Nous obtenons une fraction d'un pourcentage de qualité de code à la fois. Et c'est amusant de le voir augmenter !!!

Remarque: Encore une fois, la rigidité doit être secouée pour faire place à de nouvelles et meilleures choses. Dans mon anecdote, notre service informatique a en partie raison d'essayer de nous imposer certaines choses et d'injustice pour d'autres. Ou peut-être qu'ils avaient raison . Les choses changent. Prouvez que ce sont de meilleurs moyens d'augmenter votre productivité. Des essais et des prototypes sont là pour ça.

Le cycle de refactoring incrémentiel de code spaghetti super secret pour une qualité exceptionnelle

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

Une fois que vous avez des outils de qualité au niveau de votre toolbelt:

1. Analysez votre code avec des vérificateurs de qualité de code.

   Des linters, des analyseurs statiques ou ce que vous avez.

2. Identifiez vos points critiques critiques ET des fruits à portée de main .

   Les violations ont des niveaux de gravité, et les grandes classes avec un grand nombre de classes très graves sont un gros drapeau rouge: en tant que telles, elles apparaissent comme des "points chauds" sur les types de vues radiateur / carte thermique.

3. Fixez les points chauds en premier.

   Il optimise votre impact dans un court laps de temps car ils ont la plus grande valeur commerciale. Idéalement, les violations critiques devraient être traitées dès leur apparition, car elles constituent des vulnérabilités de sécurité potentielles ou des causes d'accidents, et présentent un risque élevé d'induire un passif (et dans votre cas, de mauvaises performances pour le laboratoire).

4. Nettoyez les violations de bas niveau avec des balayages automatisés de la base de code .

   Il améliore le rapport signal sur bruit afin que vous puissiez voir les violations importantes sur votre radar à mesure qu'elles apparaissent. Au début, il y a souvent une importante armée de violations mineures si elles ne sont jamais traitées et que votre base de code est laissée à l’état sauvage. Ils ne présentent pas de "risque" réel, mais ils compromettent la lisibilité et la maintenabilité du code. Corrigez-les lorsque vous les rencontrez lorsque vous travaillez sur une tâche, ou par de grandes quêtes de nettoyage avec des balayages de code automatisés, si possible. Faites attention avec les grands balayages automatiques si vous ne disposez pas d'une suite de tests et d'un système d'intégration corrects. Assurez-vous de convenir avec vos collègues du bon moment pour les exécuter afin de minimiser les ennuis.

5. Répétez jusqu'à ce que vous soyez satisfait.

   Ce qui, idéalement, ne devrait jamais être, s’il s’agit toujours d’un produit actif: il continuera à évoluer.

Conseils rapides pour bien garder la maison

• En mode correctif , en fonction d'une demande de support client:

  • Il est généralement préférable de NE PAS régler d'autres problèmes, car vous pourriez en introduire de nouveaux à contrecœur.
  • Allez -y dans le style SEAL: entrez, supprimez le bogue, sortez et envoyez votre patch. C'est une frappe chirurgicale et tactique.

• Mais dans tous les autres cas , si vous ouvrez un fichier, vous devez:

  • définitivement: relisez- le (prenez des notes, rédigez des rapports de problèmes),
  • peut-être: nettoyez- le (nettoyage de styles et violations mineures),
  • idéalement: le refactoriser (réorganiser les grandes sections et leurs voisins).

Il suffit de ne pas perdre de temps à passer une semaine de fichier à fichier et à se retrouver avec un énorme ensemble de modifications de milliers de correctifs couvrant plusieurs fonctionnalités et modules - cela rend le suivi futur difficile. Un problème en code = un ticket dans votre traqueur. Parfois, un changeset peut avoir un impact sur plusieurs tickets. mais si cela arrive trop souvent, alors vous faites probablement quelque chose de mal.

Addendum: Gestion des environnements de programmation visuels

Les jardins murés des systèmes de programmation sur mesure

Les systèmes de programmation multiples, tels que le G2 de l'OP, sont différents ...

• Pas de code "source"

  Souvent, ils ne vous donnent pas accès à une représentation textuelle de votre "code" source: il peut être stocké dans un format propriétaire binaire, ou peut-être stocke-t-il des éléments au format texte, mais les cache loin de vous. Les systèmes de programmation graphique sur mesure ne sont en fait pas rares dans les laboratoires de recherche, car ils simplifient l'automatisation des processus de traitement de données répétitifs.

• Aucun outillage

  Mis à part leur propre, c'est. Vous êtes souvent limité par leur environnement de programmation, leur propre débogueur, leur propre interpréteur, leurs propres outils et formats de documentation. Ce sont des jardins murés , sauf s’ils attirent éventuellement l’intérêt d’une personne suffisamment motivée pour procéder à une ingénierie inverse de leurs formats et créer des outils externes, si la licence le permet.

• Manque de documentation

  Très souvent, il s’agit de systèmes de programmation de niche, utilisés dans des environnements relativement fermés. Les personnes qui les utilisent signent souvent des NDA et ne parlent jamais de ce qu’elles font. Les communautés de programmation pour eux sont rares. Donc, les ressources sont rares. Vous êtes coincé avec votre référence officielle, et c'est tout.

Ce qui est ironique (et souvent frustrant), c'est que tout ce que ces systèmes font peut évidemment être réalisé en utilisant des langages de programmation grand public et généraux, et probablement plus efficacement. Mais cela nécessite une connaissance plus approfondie de la programmation, alors que vous ne pouvez pas vous attendre à ce que votre biologiste, chimiste ou physicien (pour n'en nommer que quelques-uns) en sache assez sur la programmation, et encore moins d'avoir le temps (et le désir) de mettre en œuvre (et de le maintenir) systèmes complexes, qui peuvent être ou ne pas vivre longtemps. Pour la même raison, nous utilisons des DSL, nous avons ces systèmes de programmation sur mesure.

Anecdote personnelle 2:En fait, j'ai travaillé sur l'un d'eux moi-même. Je n'ai pas fait le lien avec la demande du PO, mais mon projet consistait en un ensemble de gros logiciels interconnectés de logiciels de traitement et de stockage de données (principalement pour la recherche en bioinformatique, la santé et les cosmétiques, mais aussi pour les entreprises). intelligence, ou tout domaine impliquant le suivi de grands volumes de données de recherche, quelle que soit leur nature, et la préparation de workflows de traitement de données et d'ETL). L’une de ces applications était tout simplement un IDE visuel qui utilisait les fonctions habituelles: interfaces de glisser-déposer, espaces de travail de projets versionnés (utilisant des fichiers texte et XML pour le stockage de métadonnées), de nombreux pilotes enfichables pour des sources de données hétérogènes et une interface visuelle. canevas pour concevoir des pipelines pour traiter les données de N sources de données et finalement générer M sorties transformées, visualisations brillantes possibles et rapports en ligne complexes (et interactifs). Votre système de programmation visuelle sur mesure typique, souffrant d'un peu du syndrome des NIH sous prétexte de concevoir un système adapté aux besoins des utilisateurs.

Et, comme on peut s’y attendre, c’est un bon système, assez flexible pour ses besoins, bien qu’il soit parfois un peu exagéré, de sorte que vous vous demandez «pourquoi ne pas utiliser des outils de ligne de commande?», Et, malheureusement, toujours en tête des moyennes entreprises. des équipes travaillant sur de grands projets à de nombreuses personnes différentes, utilisant différentes "meilleures" pratiques.

Génial, nous sommes condamnés! - Que faisons-nous à propos de cela?

Eh bien, à la fin, tout ce qui précède est toujours valable. Si vous ne pouvez pas extraire la majeure partie de la programmation de ce système pour utiliser davantage d'outils et de langages grand public, il vous suffit "de" l'adapter aux contraintes de votre système.

À propos de la gestion des versions et du stockage

En fin de compte, vous pouvez presque toujours faire la même version , même dans l’environnement le plus contraint et le plus confiné. Le plus souvent, ces systèmes ont toujours leur propre versioning (qui est malheureusement souvent assez basique et propose simplement de revenir aux versions précédentes sans beaucoup de visibilité, en ne conservant que les instantanés précédents). Il n'utilise pas exactement les changesets différentiels, contrairement à votre choix de SCM, et il n'est probablement pas adapté à plusieurs utilisateurs soumettant des modifications simultanément.

Néanmoins, s’ils offrent une telle fonctionnalité, votre solution consiste peut-être à suivre nos très chères directives standard, et à les transposer dans ce système de programmation!

Si le système de stockage est une base de données, il expose probablement les fonctionnalités d'exportation ou peut être sauvegardé au niveau du système de fichiers. S'il utilise un format binaire personnalisé, vous pouvez peut-être simplement essayer de le mettre en version avec un VCS prenant en charge les données binaires. Vous n'aurez pas de contrôle précis, mais au moins, votre dos sera protégé contre les catastrophes et aurez une certaine conformité en matière de récupération après sinistre.

À propos des tests

Implémentez vos tests au sein même de la plate-forme et utilisez des outils externes et des tâches en arrière-plan pour configurer des sauvegardes régulières. Très probablement, vous lancez ces tests de la même manière que vous lanceriez les programmes développés avec ce système de programmation.

Bien sûr, c'est un travail de hack et certainement pas à la hauteur de ce qui est commun pour la programmation "normale", mais l'idée est de s'adapter au système tout en essayant de maintenir un semblant de processus de développement logiciel professionnel.

La route est longue et raide ...

Comme toujours avec des environnements de niche et des systèmes de programmation sur mesure, et comme nous l’avons exposé ci-dessus, vous traitez avec des formats étranges, seulement un ensemble limité (ou totalement inexistant) d’outils éventuellement maladroits et un vide à la place d’une communauté.

La recommandation: essayez de mettre en œuvre les directives ci-dessus en dehors de votre système de programmation sur mesure, autant que possible. Cela garantit que vous pouvez compter sur des outils "communs", bénéficiant d'un soutien approprié et d'un dynamisme communautaire.

La solution de contournement: lorsque ce n'est pas une option, essayez de mettre à niveau ce cadre global dans votre "boîte". L'idée est de superposer ce schéma directeur des meilleures pratiques standard de l'industrie à votre système de programmation et d'en tirer le meilleur parti. Les conseils sont toujours valables: définissez la structure et les meilleures pratiques, encouragez la conformité.

Malheureusement, cela implique que vous devrez peut-être plonger et faire un travail considérable sur les jambes. Alors...

Derniers mots célèbres, et demandes humbles:

• Documentez tout ce que vous faites.
• Partagez votre expérience.
• Open Source n’importe quel outil que vous écrivez.

En faisant tout cela, vous allez:

• non seulement augmenter vos chances d'obtenir le soutien de personnes dans des situations similaires,
• mais aussi aider d'autres personnes et favoriser la discussion autour de votre pile technologique.

Qui sait, vous pourriez être au début d'une nouvelle communauté dynamique de langue Obscure X . S'il n'y en a pas, commencez-en un!

• Posez des questions sur le dépassement de pile ,
• Peut-être même rédigez-vous une proposition pour un nouveau site StackExchange dans la zone 51 .

C’est peut-être beau à l’intérieur , mais personne n’a encore la moindre idée , aidez-nous donc à abattre ce mur affreux et à laisser les autres jeter un coup d’œil!

La toute première étape serait l’ introduction d’un système de contrôle de version (SVN, Git, Mercurial, TFS, etc.). C'est indispensable pour un projet qui aura à être revitalisé.

Edit: à propos de VSC - Chaque package de contrôle de code source peut gérer les fichiers binaires, avec certaines limitations. La plupart des outils disponibles sur le marché ont la possibilité d’utiliser un afficheur et un éditeur de différences personnalisés. Les fichiers source binaires ne sont pas une excuse pour ne pas utiliser le contrôle de version.

Il y a un article similaire sur la façon de traiter le code hérité , cela pourrait être une bonne référence à suivre - Conseils sur l'utilisation du code hérité

Lorsque je dois travailler avec du code spaghetti, la première chose sur laquelle je travaille est la modularisation . Trouvez des endroits où vous pouvez dessiner des lignes et extraire (plus ou moins) des parties indépendantes de la base de code. Elles ne seront probablement pas très petites, en raison du degré élevé d’interconnexion et de couplage, mais certaines lignes de modules apparaîtront si vous les recherchez.

Une fois que vous avez des modules, vous n'êtes plus confronté à la lourde tâche de nettoyer tout un programme en désordre. Maintenant, à la place, vous avez plusieurs modules indépendants plus petits et malpropres à nettoyer. Maintenant, choisissez un module et recommencez à une plus petite échelle. Trouvez des endroits où vous pouvez extraire de grandes fonctions en fonctions plus petites ou même en classes (si G2 les prend en charge).

Tout cela est beaucoup plus facile si le langage a un système de frappe suffisamment fort, car vous pouvez demander au compilateur de faire beaucoup de travail pour vous. Vous apportez une modification quelque part qui rompra (intentionnellement) la compatibilité, puis tentez de compiler. Les erreurs de compilation vous mèneront directement aux endroits à changer, et lorsque vous cessez de les obtenir, vous avez tout trouvé. Ensuite, lancez le programme et testez tout! Des tests continus sont d'une importance cruciale lors de la refactorisation.

Je ne sais pas si c'est une option pour vous, mais je commencerais par essayer de les convaincre d' embaucher davantage de développeurs professionnels . De cette façon, ils pourraient se concentrer sur les problèmes de domaine (je suis sûr qu’ils en ont assez).

Je pense que ce sont des personnes très intelligentes, mais devenir un bon développeur demande beaucoup de temps. Sont-ils prêts à consacrer autant de temps à une activité qui n'est pas leur activité principale? IMHO, ce n'est pas le moyen d'obtenir les meilleurs résultats.

Sensationnel. On dirait que vous avez un très gros défi devant vous! Je ferais quelque chose dans le sens suivant:

• Tout d'abord: prioriser . Que voulez-vous réaliser en premier? Quel est le plus important pour l'état actuel du projet? Qu'est-ce que vous obtiendrez le plus de vs combien de temps il faudra pour y arriver.
• Assurez-vous de disposer d'un système de contrôle de version . Git ou Mercurial par exemple.
• Installez un système d’ intégration continue (par exemple, Jenkins ).
• Obtenez un système de suivi des bogues opérationnel. Mantis est assez sympa à mon avis.
• Regardez dans l'analyse de code statique (si quelque chose est disponible pour la langue dans laquelle vous travaillez actuellement).
• Essayez de parvenir à autant de cohérence dans tous les domaines, de la désignation des variables aux conventions générales du code et aux instructions de la base de code.
• Obtenez le système sous test . Ceci est extrêmement important pour un grand système hérité comme celui-ci à mon avis. Utilisez des cas de test pour documenter le comportement existant , peu importe si le comportement vous semble étrange ou non (en général, il existe une raison pour laquelle le code a une apparence, il peut être bon ou mauvais, ou les deux; P). Michael Feathers Travailler efficacement avec Legacy Code est une excellente ressource pour cela.

Ils disent que la première étape de la résolution d'un problème consiste à admettre que vous en avez un. Dans cet esprit, vous pouvez commencer par générer un graphique de dépendance illustrant le vaste enchevêtrement qui constitue votre base de code actuelle. Bon outil pour générer un diagramme de dépendance? a quelques années mais contient quelques indications sur des outils pouvant aider à créer de tels graphiques. Je choisirais un graphique très grand et très laid qui montre le plus possible le sens du retour. Parlez de problèmes qui résultent de trop nombreuses interdépendances et insérez peut-être une phrase de Buckaroo Banzai :

Vous pouvez vérifier votre anatomie tout ce que vous voulez, et même s’il peut y avoir une variation normale, même au fond, c’est pareil. Non, non, non, ne tirez pas dessus. Vous ne savez jamais à quoi il pourrait être attaché.

À partir de là, présentez un plan pour commencer à redresser la situation. Divisez le code en modules aussi autonomes que possible. Soyez ouvert aux suggestions quant à la façon de le faire - les personnes à qui vous parlez connaissent l'histoire et les fonctionnalités du code mieux que vous. Cependant, l’objectif est de prendre un gros problème et de le transformer en un certain nombre de problèmes plus petits que vous pouvez ensuite hiérarchiser et commencer à nettoyer.

Quelques points sur lesquels se concentrer:

• Créez des interfaces propres entre les modules et commencez à les utiliser. L'ancien code peut, par nécessité, continuer à ne plus utiliser ces nouvelles interfaces pendant un moment - c'est le problème que vous commencez à résoudre. Mais faites en sorte que tout le monde accepte d'utiliser uniquement les nouvelles interfaces. Si quelque chose dont ils ont besoin n'est pas dans les interfaces, corrigez-les, ne les contournez pas.

• Recherchez les cas où la même fonctionnalité a été répétée. Travailler à l'unification.

• Rappelez à tout le monde de temps en temps que ces changements ont pour but de faciliter la vie, pas plus difficile. La transition peut être pénible, mais c'est dans un bon but, et plus tout le monde est à bord, plus vite les avantages en découleront.

Après avoir examiné Gensym G2 un peu, il semble que la façon d’aborder ce problème dépendra beaucoup de la taille de la base de code suivante:

ou ca:

par rapport à cela, courtoisie de 99 bouteilles de bière :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

Dans ce dernier cas, vous travaillez avec un code source qui est en réalité une quantité connue et certaines des autres réponses offrent un conseil très sage pour le gérer.

Si la majeure partie de la base de code est celle-ci, ou même si un morceau important l'est, vous allez rencontrer le problème intéressant d'avoir du code qui ne peut probablement pas être refactorisé en raison de son extrême spécialisation, ou pire, quelque chose qui ressemble à il peut être amovible, mais à moins qu'il ne soit correctement documenté, vous ne savez pas si vous supprimez du code critique (pensez, par exemple, une opération scram ), qui ne semble pas l'être à première vue.

Bien évidemment, votre première priorité sera de mettre en place une sorte de contrôle de version en ligne, comme l'a souligné ElYusubov , et il semble que le contrôle de version ait été pris en charge depuis la version 8.3 . Étant donné que G2 est une combinaison de plusieurs méthodologies de langage, il serait probablement plus efficace d’utiliser le contrôle de version fourni avec celui-ci plutôt que d’essayer de trouver quelque chose d’autre et de le faire fonctionner.

Ensuite, bien que certains préconisent probablement de commencer à refactoriser, je suis un fervent défenseur de mon intention de bien comprendre le système sur lequel vous travaillez avant de commencer à toucher au code, en particulier lorsqu'il s'agit de codes et de diagrammes visuels développés par Développeurs sans formation formelle (ou expérience) en méthodologies de génie logiciel. Le raisonnement à cet égard est multiple, mais la raison la plus évidente est que vous travaillez avec une application comportant potentiellement plus de 100 années-personnes de travail et que vous devez vraiment vous assurer de savoir ce qu’elle fait et combien. la documentation qu'il y a dedans. Comme vous ne l'avez pas indiqué dans quel secteur le système est déployé, D'après ce que j'ai lu au sujet de G2, il semble raisonnable de supposer qu'il s'agit probablement d'une application essentielle à la mission qui pourrait même avoir un impact potentiel sur la sécurité des personnes. Par conséquent, il est très important de comprendre exactement ce que vous faites. Il existe un code non documenté qui fonctionne avec les autres membres de l’équipe pour s’assurer que la documentation est mise en place afin de s’assurer que les personnes peuvent déterminer l’utilisation du code.

Ensuite, commencez à encapsuler les tests unitaires autour de la base de code et des diagrammes visuels que vous pouvez. Je dois admettre que je ne sais pas trop comment faire cela avec G2, mais il serait peut-être intéressant de créer votre propre cadre de test pour le mettre en place. C’est également le moment idéal pour commencer à présenter les autres membres de l’équipe et à les familiariser avec les pratiques d’ingénierie les plus rigoureuses en matière de qualité du code (c’est-à-dire que tout code doit comporter des tests unitaires et une documentation).

Une fois que vous avez mis en place des tests unitaires sur une bonne partie du code, vous pouvez commencer à procéder à une refactorisation de la manière proposée par haylem . Cependant, n'oubliez pas de garder à l'esprit que vous traitez avec quelque chose qui est destiné à développer des systèmes experts et que le refactoriser pourrait être une bataille ardue. C'est en fait un environnement où il y a quelque chose à dire pour ne pas écrire de code extrêmement générique parfois.

Enfin, assurez-vous de porter une attention particulière aux propos des autres membres de l'équipe, le simple fait que la qualité du code et du diagramme ne soit pas la meilleure ne reflète pas nécessairement leur mécontentement. En fin de compte, pour le moment, ils en sauront probablement davantage sur ce que fait l'application, ce qui explique pourquoi il est d'autant plus important pour vous de vous asseoir et de bien comprendre ce qu'elle fait avant de procéder également à des changements radicaux.

Habituellement, les plaintes que vous entendez dès le départ n'ont rien à voir avec les problèmes importants. Après tout, il est tout à fait normal d'entendre parler de ces plaintes dans les projets de logiciels.

Difficile de comprendre le code? Vérifier. Base de code massive? Vérifier.

Le vrai problème est que les gens partent, et lorsque la nouvelle personne entre dans l'organisation, il y a une désorientation typique. En outre, il existe un problème d'attentes irréalistes et de problèmes de qualité du code.

Voici ce que je voudrais aborder, dans l'ordre:

1. Sauvegardes, version serveur et version locale
2. Configurer le traqueur de bogues
3. Configurer le système de gestion de versions
4. Configurer FAQ / Wiki
5. Premier débriefing de tous les scientifiques / programmeurs
   • Rappelez-leur la règle des 80/20. 20% des bugs sont responsables de 80% des problèmes.
   • Concentrez-vous sur les problèmes les plus importants et limitez les demandes d’amélioration, etc.
   • Le but ici n'est pas de faire peur aux gens avec une grande liste, mais une liste de petites victoires réalisables. Après tout, vous devez également prouver votre valeur.
6. Configurer le système de construction
   • Commencez à travailler pour obtenir des versions fiables (cela peut prendre un certain temps)
   • identifier et nommer chaque projet
   • identifier les dépendances cycliques
   • s'il existe des fichiers binaires de certains projets open-source, essayez d'obtenir des sources
7. Identifier comment le code G2 peut être modularisé, par exemple, API, services
8. Identifiez comment le code G2 peut être testé et documenté.
9. Configurer le système de révision de code
10. Deuxième compte rendu
    • A quoi ressemble un module idéal?
    • Comment boucler l'ancien code
    • Comment envelopper un nouveau module autour d'un ancien code (voir le modèle d'étrangleur http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html )
11. Identifiez une équipe de programmeurs de meilleure qualité et travaillez avec eux pour envelopper leurs modules.
12. Les revues de code sont à ce stade pour améliorer la communication et la documentation. Gardez les choses faciles à ce stade. Réglez tous les problèmes de processus.
13. Déployez le système auprès d'autres programmeurs. Laissez les membres de l’équipe crack devenir des mentors pour les autres. Rappelez-vous que la mise à l'échelle est le problème ici. Vous êtes effectivement dans un rôle de gestion.

Des questions comme celles-ci sont la raison pour laquelle le projet de menuiserie logicielle existe.

Au cours des 14 dernières années, nous avons enseigné aux scientifiques et aux ingénieurs des compétences de base en développement de logiciels: contrôle de version, tests, modularisation du code, etc. Tous nos documents sont disponibles gratuitement sous une licence Creative Commons, et nous organisons chaque année une vingtaine d'ateliers gratuits de deux jours pour aider les gens à démarrer.

Sur cette base, je pense que le meilleur point de départ est probablement l'excellent ouvrage (court) de Robert Glass intitulé Facts and Fallacies of Software Engineering : son approche fondée sur des preuves est un bon moyen de convaincre les scientifiques que ce que nous leur disons au sujet des bonnes pratiques de programmation est: plus qu'un avis.
En ce qui concerne les pratiques spécifiques, les deux que les gens sont le plus disposés à adopter sont le contrôle de version et les tests unitaires; Une fois que ceux-ci sont en place, ils peuvent s’attaquer au type de refactoring systématique décrit par Michael Feathers dans Travailler efficacement avec Legacy Code .
Je ne recommande plus The Pragmatic Programmer (beaucoup d'exhortations, difficile à mettre en pratique par les novices), et je pense que McConnell's Code Complete C’est trop pour commencer (bien que ce soit une bonne chose de leur donner six mois ou un an après avoir maîtrisé les bases).

Je recommanderais également vivement l'excellent article de Paul Dubois intitulé "Maintenir la correction dans les programmes scientifiques" ( Informatique en Science et Ingénierie , mai-juin 2005), qui décrit une approche de "défense en profondeur" qui combine une douzaine de pratiques différentes de manière logique et cohérente. façon.

Je pense d'abord que vous devez effacer votre situation. Qu'est-ce qu'ils veulent de toi?

• Il est très peu probable qu'ils veuillent que vous appreniez une langue ancienne, car cela semble maintenant une impasse: les chances de trouver quelqu'un sachant ou désirant apprendre le G2 diminuant, la connaissance sera donc enterrée dans le tas de code en train de s'effondrer. les scientifiques actuels partent ou le code entièrement corrigé échoue de plus en plus souvent.
• Les scientifiques (ou certains d’entre eux) sont-ils prêts à apprendre un nouveau langage et de nombreux paradigmes de programmation? Ou veulent-ils séparer la programmation de l'activité scientifique à long terme et peut-être avoir plus de programmeurs si nécessaire? Cela semble une séparation rationnelle et plus efficace des compétences.

Je pense que la condition essentielle ici est de "sauvegarder les connaissances dans le système", il faut donc aller les fouiller!

La première tâche consiste à rédiger une documentation.

Analysez la structure et les exigences comme s'il s'agissait d'une nouvelle tâche, mais à l'aide d'un système existant. Ils seront contents parce que vous demandez plutôt que d’ENSEIGNER - et vous en obtiendrez rapidement une connaissance de base suffisante, mais mieux organisée, du point de vue du programmeur: "que se passe-t-il ici?" Les documents (structure statique du système, flux de travail, composants, problèmes) leur seront immédiatement utiles et leur montreront peut-être des informations plus pertinentes que vous (certains des gars peuvent avoir «AHA!» Et commencent à corriger certains codes immédiatement ) ...

Vous devriez alors commencer à demander où ils veulent aller?

S'ils sont prêts à s'éloigner de G2, quel système veulent-ils voir (plate-forme, langue, interface, structure générale)? Vous pouvez commencer à écrire un wrapper externe autour du système, dans la mesure du possible, avec la structure cible, mais en conservant les composants d'origine, démarrant ainsi lentement une sorte de cadre permettant l'implémentation de nouveaux composants dans cet environnement cible. Vous devez trouver les services de base (connexions de données persistantes et "boîtes à outils": calcul de base, dessin, ... bibliothèques) et leur fournir ainsi un environnement familier dans une nouvelle plate-forme et un nouveau langage, ce qui permet la transition par vous-même ou par vous-même. eux: prenez les anciens codes un par un, réimplémentez-les (et CLEAN!) dans le nouvel environnement. Quand cela est prêt, ils connaissent la nouvelle langue. et la couche de service (principalement créée par vous, désolé) est prête à héberger les nouveaux composants.

S'ils ne bougent pas , vous devez apprendre G2 et créer le cadre modulaire dans lequel vous devez déplacer les composants (avec nettoyage). Quoi qu'il en soit, le langage est juste une sérialisation de données et d'arborescence d'algorithmes ...

Tout en analysant et en rédigeant la documentation, lisez, utilisez et publiez les modèles de conception GoF! :-)

... mes 2 cents

Je viens de terminer une série d'exposés sur les principes SOLID de Robert Martin à l'intention de mes collègues. Je ne sais pas si ces principes se traduisent bien dans G2, mais comme vous recherchez 5 à 7 fondamentaux, cela semble être un ensemble bien établi pour commencer. Si vous voulez arrondir à 7, vous pouvez commencer par DRY et ajouter Fail-Fast.

Le seul problème de production ressemble à un problème de gestion du changement. Si tel est le cas et que le logiciel l'exécute autrement, le premier conseil que je donnerais est de résister à l'envie de faire trop, trop vite.

Le contrôle à la source, la refactorisation, des développeurs plus expérimentés sont de bonnes suggestions, mais si c'est la première fois que vous devez faire face à ce type de problème, vous évoluez lentement et vous ne pouvez pas insister suffisamment sur les modifications maîtrisées.

L'envie de détruire le désordre sera parfois bonne, mais jusqu'à ce que vous ayez suffisamment d'ingénierie inverse pour savoir que vous pouvez tester votre version de remplacement de manière adéquate, vous devez faire très attention.

Les principes les plus importants pour travailler dans une telle situation sont les suivants:

1. Sois patient. Un trou qui a pris 20 ans à creuser ne sera pas comblé dans quelques semaines.

2. Sois positif. Résistez à la tentation de vous plaindre et de vous plaindre.

3. Soyez pragmatique. Regardez un changement positif que vous pouvez accomplir en un jour et faites-le aujourd'hui. Vous avez encore un système de contrôle de version? Appliquez-le et formez les gens. Ensuite, regardez si vous pouvez automatiser les tests (tests unitaires ou similaires). Rincer. Répéter.

4. Soyez un modèle. Montrez (ne vous contentez pas de dire aux gens) comment fonctionne l'agilité en agissant. Les trois premiers points ci-dessus sont les clés pour être un bon gars, qui est le prédécesseur d'un gars efficace et agile. À mon avis, les développeurs admirables ne sont pas seulement intelligents, ils sont également bons, employés modèles et collègues.

5. Cartographiez votre territoire. J'ai une technique pour cartographier des bases de code héritées gigantesques. Je clone le référentiel, fais une copie de travail, puis j'essaie de changer quelque chose et de voir ce qui ne fonctionne pas. En recherchant le couplage (via un état global, des API cassées, ou un manque d'API cohérente ou d'abstractions ou d'interfaces contre lesquelles programmer), et en lisant le code qui se rompt lorsque je change, je découvre le cruel, je pose des questions points de vue du reste de l'équipe (Oh, nous avons ajouté que, parce que Boss X l'exigeait il y a 5 ans, cela n'a jamais fonctionné!). Au fil du temps, vous obtiendrez une carte mentale du territoire. Une fois que vous saurez à quel point c'est grand, vous en saurez assez pour faire votre carte et rentrer chez vous. Encouragez les autres à cartographier le territoire de votre base de code géante et à renforcer les connaissances techniques de l'équipe. Certaines personnes rechignent à la "documentation" parce que ce n'est pas agile. Peu importe. Je travaille aussi dans des environnements scientifiques, et la documentation est mon roi, les programmes agiles soient maudits.

6. Construire de petites applications. Lorsque je travaille avec une base de code héritée, je constate que je suis réduit à néant. Je retrouve mon esprit en construisant de petites applications d'aide. Peut-être que ces applications vont vous aider à lire, à comprendre et à modifier cette base de code géante G2. Vous pouvez peut-être créer un mini-outil IDE ou un outil d'analyse qui vous aidera à travailler dans votre environnement. Dans de nombreux cas, la méta-programmation et la construction d'outils vous aideront non seulement à sortir des impasses géantes imposées par les bases de code héritées, mais également à donner à votre cerveau la possibilité de voler sans vous entraver avec votre langage G2. Ecrivez vos outils et vos aides dans la langue de votre choix, le plus rapidement possible. Pour moi, ces langages incluent Python et Delphi. Si vous êtes un gars de Perl ou si vous aimez réellement programmer en C ++ ou en C #, écrivez vos outils d’aide dans ce langage.

1. Contrôle des révisions : montrez aux experts du domaine l’avantage de pouvoir revenir en arrière, voyez qui a changé quoi, etc. (C’est plus difficile avec des fichiers entièrement binaires, mais si le contenu est bien du code, il y a sûrement une sorte de G2 à convertisseur de texte qui peut activer les diffs.)

2. Intégration et test continus : impliquez les experts de domaine dans la création de tests de bout en bout (plus facile, car ils doivent déjà disposer des entrées et des résultats attendus quelque part) et de petits tests unitaires (plus difficiles, car le code spaghetti implique probablement beaucoup de variables globales) qui couvrir presque toutes les fonctionnalités et les cas d'utilisation.

3. Refacturer le code commun en routines et composants réutilisables. Les personnes non-logicielles sans contrôle de révision copient et collent probablement des centaines de lignes à la fois pour créer des routines. Trouvez-les et refactorisez-les, en montrant que tous les tests sont réussis et que le code est devenu plus court. Cela vous aidera également à apprendre son architecture. Si vous avez de la chance au moment où vous devez commencer à prendre des décisions architecturales difficiles, vous pourriez être réduit à 100KLOC.

Politiquement , si vous rencontrez des réticences de la part des anciens dans ce processus, engagez un consultant et faites un exposé sur la bonne méthodologie logicielle. Assurez-vous de trouver le bon correspondant avec lequel vous êtes d'accord et demandez à la direction de bien comprendre la nécessité du consultant, même si les experts du domaine ne le savent pas. (Ils devraient être d'accord. Après tout, ils vous ont embauché. Ils réalisent donc manifestement qu'ils ont besoin d'une expertise en ingénierie logicielle.) C'est un truc qui gaspille de l'argent, bien sûr, mais la raison en est que si vous, le nouveau programmeur de jeu très populaire, dites-le ils ont besoin de faire quelque chose, ils peuvent l'ignorer. Mais si la direction paie 5000 dollars à un consultant pour lui dire ce qu'il doit faire, il y fera plus confiance. Points bonus: demandez au consultant de conseiller deux fois plus de changements que vous le souhaitez vraiment, vous pourrez alors être le "bon gars" et être du côté des experts du domaine, en ne vous contentant de changer que la moitié de ce que le consultant a suggéré.

"Le programme lui-même est un modèle physique d'une usine de traitement chimique complexe ..."

"Puisque G2 n'est pas du code, mais du code automatisé écrit par une interface graphique ..." - Erik Reppen

En supposant que l'objectif principal de votre logiciel soit de simuler (peut-être d'optimiser, d'exécuter des estimations de paramètres) une usine chimique complexe , ou des parties d'une usine chimique ... alors j'aimerais émettre une suggestion plutôt différente:

Vous feriez bien d’envisager d’utiliser un langage de modélisation mathématique de haut niveau pour extraire l’essence, les modèles mathématiques de base, des logiciels codés à la main.

Ce qu’un langage de modélisation fait, c’est découpler la description du problème des algorithmes utilisés pour le résoudre. Ces algorithmes sont généralement applicables à la plupart des simulations / optimisations d'une classe donnée (par exemple, des processus chimiques). Dans ce cas, ils ne doivent en réalité pas être réinventés ni maintenus en interne.

Trois packages commerciaux largement utilisés dans votre secteur sont: gPROMS, Aspen Custom Modeller et (si vos modèles n'incluent pas les phénomènes distribués sur des domaines spatiaux), il existe des packages logiciels basés sur Modelica, tels que Dymola.

Tous ces packages prennent en charge les "extensions" d'une manière ou d'une autre. Ainsi, si vous avez des parties de vos modèles qui nécessitent une programmation personnalisée, elles peuvent être encapsulées dans un objet (par exemple, un fichier .DLL) pouvant être référencé par les équations du système. modèle. Pendant ce temps, le gros de votre modèle reste succinct, décrit sous une forme facilement lisible par les scientifiques. Il s'agit d'un moyen bien plus efficace de capturer les connaissances et la propriété intellectuelle de votre entreprise.

La plupart de ces programmes devraient également vous permettre de "démarrer" de petites et porter de petites parties (sous-modèles) de votre code monolithique dans leur format, en les appelant de l'extérieur. Cela peut être un bon moyen de maintenir un système en fonctionnement et de le valider pièce par pièce.

Clause de non-responsabilité: J'ai travaillé comme ingénieur logiciel pour la société derrière gPROMS pendant 8 ans. Au cours de cette période, j’ai vu (et parfois incorporé) des exemples de logiciels personnalisés (par exemple issus du monde universitaire) qui avaient démarré petit et bien rangé, implémentant une solution ou un algorithme intelligent, puis explosé au fil des ans avec des extensions et des modifications - sans les conseils utiles de un ingénieur logiciel pour le garder propre. (Je suis un grand fan des équipes multidisciplinaires.)

Je peux donc affirmer avec une certaine expérience que certains choix clés mal faits au tout début du développement d’un logiciel (comme un langage ou une bibliothèque de clés) ont tendance à rester en place et à causer des souffrances depuis longtemps ... Ils ont déjà "façonné" le logiciel autour d'eux. Il me semble que vous pourriez être confronté à de nombreuses années de nettoyage de code pur ici. (Je suis hésitant à utiliser des chiffres, mais je pense à plus de 10 années-personnes, peut-être beaucoup plus si vous ne pouvez pas transférer le code de G2 vers quelque chose qui prend en charge de bons outils de refactoring automatisés tels que Eclipse / Java quick-smart.)

Alors que mon statut par défaut est de "refactoriser et de garder un système en fonctionnement", je pense aussi qu'une fois qu'un problème devient "trop ​​gros", un changement / réécriture plus radical devient plus rapide dans l'ensemble. (Et peut-être apporte des avantages supplémentaires, tels que le passage à une technologie plus moderne.) Je le dis avec une certaine expérience de portage sur une nouvelle plate-forme logicielle, mais d'après ce que je suppose, c'est encore plus spectaculaire avec un portage vers un package de modélisation mathématique.

Pour vous donner une idée, vous serez peut-être surpris de la réduction de taille. Par exemple, les 200 000 LdC pourraient en fait être représentées dans quelque chose comme 5 000 lignes d'équations (OK, je suppose, mais je pourrais essayer de vous obtenir un témoignage réel d'amis de l'entreprise); plus quelques modules de fonction relativement petits écrits en C (par exemple, les calculs de propriétés physiques - bien que, de nouveau, des packages prêts à l'emploi puissent exister en fonction de votre processus chimique). En effet, vous jetez littéralement le code de la solution algorithmique et laissez une «pile» polyvalente de solveurs mathématiques faire le gros du travail. Une fois que vous avez exécuté des simulations, vous pouvez en faire beaucoup plus, comme optimiser le processus, sans modifier une ligne de code.

Enfin, je dirais: si le code lui-même est la seule documentation fiable des différents modèles mathématiques (et des algorithmes), vous aurez besoin de l'aide des scientifiques et des auteurs originaux pour extraire ces modèles, dès que possible, et non des années plus tard. certains d'entre eux ont peut-être évolué. Ils devraient trouver qu’un langage de modélisation mathématique est un moyen très naturel de capturer ces modèles - ils peuvent même (choquer l’horreur) en profiter (ré) écrire.

Enfin, ma réponse étant peut-être erronée, j'aimerais simplement ajouter un livre de plus à la liste des bons livres déjà référencés ici: Clean Code de Robert Martin. Plein de conseils simples (et justifiés) faciles à apprendre et à appliquer, mais qui pourraient faire toute la différence pour les personnes qui développent un nouveau code dans votre entreprise.

Je voudrais jeter le texte suivant:

1. Il y a un programmeur ici. Politique de vis. Ils connaissent leur métier. Vous connaissez le vôtre. Marquez ce territoire même si vous devez pisser dessus. Ce sont des scientifiques. Ils peuvent respecter ce genre de chose ou devraient le faire puisqu'ils font presque toujours la même chose eux-mêmes. Par tous les moyens possibles, marquez les limites maintenant. C'est ce que je vais réparer. C'est ce que je ne peux pas être responsable.

2. Les scientifiques écrivent / testent les algorithmes. Les scientifiques qui le souhaitent peuvent écrire leurs propres algorithmes dans 1 à 3 langues sur lesquelles tout le monde peut s’accorder pour vous convertir au code principal. Cela met leurs trucs à l’essai. Au-delà de cela, ils vont devoir vous aider à isoler l'essentiel de la science par rapport au bon dieu sait ce qu'ils ont fait pour l'architecture. Le code base est arrosé. Il reste encore beaucoup à faire. Donnez-leur des options pour vous remettre des versions de travail qui utilisent ce qu'ils savent le mieux afin que vous puissiez faire ce que vous faites le mieux. Collez leurs connaissances dans une boîte dont ils sont responsables mais avec laquelle vous pouvez travailler.

3. Utilisez un langage adapté aux événements avec des fonctions de première classe si vous le pouvez. Lorsque tout échoue, le déclenchement d'un événement ou le rappel à un objet doté d'une interface et d'un mécanisme d'état qui ont un sens peut s'avérer un gain de temps considérable lorsque vous êtes plongé au fond d'un code qui n'a aucun sens et peut-être jamais volonté. Les scientifiques semblent aimer Python. Il n’est pas difficile de coller du contenu C bas niveau intensif en mathématiques avec cela. Juste dire

4. Recherchez quelqu'un qui a résolu ce problème ou un problème similaire. Passez du temps sérieux à la recherche. Ces gars-là ont entendu parler de G2 par quelqu'un.

5. Modèles de conception. Adaptateurs. Utilisez-les. Utilisez-les beaucoup dans des situations comme celle-ci.

6. Apprenez ce que vous pouvez de la science. Plus vous en savez, mieux vous pourrez déterminer l'intention dans le code.

Faites l'analyse en premier.

Je ferais une analyse avant de décider quoi enseigner. Déterminez où sont les points les plus douloureux. Utilisez-les pour donner la priorité aux pratiques à suivre.

Introduisez seulement quelques changements à la fois (dans une situation similaire, je faisais 2 à 3 séances toutes les 2 semaines) .

Je limiterais les pratiques à environ 3 en fonction du niveau de changement, en fonction de leur style de programmation SDLC; jusqu'à ce qu'ils commencent à être à l'aise avec eux (j'insisterais pour introduire 1 nouveau changement toutes les semaines ou toutes les semaines, à mesure qu'ils se familiariseront avec l'idée d'apprendre de nouvelles approches). C'est aussi une bonne idée d'identifier les critères de réussite. Ce que la pratique devrait accomplir (même s’il s’agit d’un objectif délicat comme le moral de l’équipe). De cette façon, vous pouvez montrer si c'est efficace ou non.

• Pourquoi limiter le nombre de modifications?

Même si vous supposez que ces personnes veulent être de meilleurs programmeurs et sont ouvertes à l'apprentissage, il y a des limites à la quantité et à la rapidité avec lesquelles les gens peuvent apprendre de nouveaux concepts et les appliquer; surtout s'ils n'ont pas la fondation CS ou ont déjà participé à un cycle de vie de développement logiciel.

Ajoutez une réunion de synthèse hebdomadaire pour discuter de la manière dont les pratiques les ont affectés.

La réunion devrait être utilisée pour discuter de ce qui a bien fonctionné et de ce qui doit être travaillé. Permettez-leur d’avoir une voix et de collaborer. Discutez et préparez des plans pour résoudre les problèmes qu’ils rencontrent et pour prévisualiser les prochaines modifications. Gardez la réunion axée sur les pratiques et leur application. Évangélisez un peu les avantages qu’ils devraient commencer à voir en appliquant les pratiques.

Certaines pratiques ont préséance.

L'utilisation appropriée d'un système de contrôle de version (IMO) l'emporte sur tout le reste. Viennent ensuite des leçons de modularisation, de couplage / cohésion et de suivi des tickets de fonctionnalité / bogue.

Supprimer les pratiques qui ne fonctionnent pas.

N'ayez pas peur de vous débarrasser de pratiques qui ne fonctionnent pas. S'il y a un coût élevé et peu ou pas d'avantages, supprimez cette pratique.

L'amélioration est un processus.

Communiquer que l'amélioration continue et constante est un processus. Identifiez les points les plus douloureux, appliquez une solution, attendez / entraînez, puis recommencez. Au début, il se sentira terriblement lent jusqu'à ce que vous obteniez un certain élan. Gardez tout le monde concentré sur les améliorations à venir et les améliorations déjà réussies.

On dirait que la première étape consiste à convaincre l’équipe d’investir dans une nouvelle méthodologie logicielle. Selon votre déclaration, il n’ya pas de consensus au sein de l’équipe et vous en aurez besoin pour pouvoir avancer avec une lente "mise à jour" du code.

Si possible, je prendrais personnellement les dures leçons apprises et présenterais chacun des concepts clés que vous souhaitez résoudre comme solution au problème rencontré dans l'industrie du logiciel.

Par exemple, deux développeurs ont eu des copies différentes et ont fini par déployer une version hybride non testée -> Introduire le contrôle de version, la création de branches et les tests.

Quelqu'un a supprimé quelques lignes de code qu'ils ne comprenaient pas et a provoqué une panne -> introduire DDD.

Si les dures leçons ne sont pas partagées avec vous de manière suffisamment détaillée, montrez simplement vos propres exemples de la façon dont les choses se sont mal passées lorsque cette discipline n'a pas été respectée.

Le contrôle du code source est l’étape 1, comme cela a déjà été mentionné à maintes reprises. Les personnes avec lesquelles vous travaillez ne sont peut-être pas des développeurs professionnels et ne répondent pas à beaucoup d'entreprises ou de sociétés démodées agiles. Ce ne sont pas non plus des singes de code bas niveau et essayer de les traiter comme ça en les forçant à faire les choses «à leur manière» ne s'envolera pas.

Vous devez examiner ce qui se passe. S'ils n'ont pas utilisé le contrôle de code source, il suffit alors d'identifier les bonnes versions du code (si possible) et de définir tous les produits livrables possibles. Ensuite, vous devrez enseigner à vos collègues comment utiliser le contrôle de code source et les convaincre que cela vaut la peine. Commencez avec les avantages!

Pendant que vous faites cela, trouvez d’autres solutions simples et résolvez ces problèmes.

Par-dessus tout, écoutez ce qu'ils ont à dire et travaillez à améliorer leur situation. Ne craignez pas d'essayer de mettre votre empreinte sur ce qu'ils font.

Bonne chance!