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 README
pour 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:
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:
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 gofmt
outil, qui enlève complètement tout débat et effort ( et ego !! ) inhérents au style: courez gofmt
avant 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 Git
et essaie de vous forcer à écrire de bons journaux plus que la plupart des autres systèmes SCM, en utilisant short logs
et
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:
Analysez votre code avec des vérificateurs de qualité de code.
Des linters, des analyseurs statiques ou ce que vous avez.
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.
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).
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.
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!