Je suis un développeur relativement nouveau, fraîchement sorti du collège. Pendant mes études et au cours de mes recherches d’emploi, j’ai réalisé qu’il me manquait beaucoup de méthodologies de développement de logiciels "modernes": tests unitaires, journalisation, normalisation de bases de données, développement agile (par opposition aux concepts génériques agiles), style de codage guides, refactoring, revues de code, pas de méthodes de documentation normalisées (ni même d’exigences), etc.

Dans l'ensemble, je n'ai pas vu que c'était un problème. Je m'attendais à ce que mon premier emploi embrasse toutes ces idées et me les enseigne au travail. Ensuite, j'ai eu mon premier emploi (développement web full stack) dans une grande entreprise et j'ai réalisé que nous ne faisons rien de tout cela. En fait, moi-même, le moins expérimenté de l'équipe, je suis celui qui mène de front pour essayer de familiariser mon équipe avec les techniques de programmation "modernes" - car je crains que ne le fassent pas, c'est un suicide professionnel.

J'ai d'abord commencé avec le logiciel de journalisation (log4J), puis je me suis rapidement mis à écrire mon propre guide de style, puis à l'abandonner pour le guide de style de Google. Puis, j'ai réalisé que notre développement Web Java utilisait des contrôleurs frontaux écrits à la main. notre adoption du printemps - mais ensuite, j'ai réalisé que nous n'avions pas non plus de tests unitaires, mais j'apprenais déjà le printemps ... et comme vous pouvez le constater, cela devient vite trop pénible, surtout quand il est associé à un travail de développement normal. En outre, il m'est difficile de devenir suffisamment "expert" dans ces méthodologies pour enseigner à quiconque en cela sans consacrer trop de temps à une seule d'entre elles, encore moins à toutes.

Parmi toutes ces techniques, que je considère comme "attendues" dans le monde actuel du développement logiciel, comment puis-je les intégrer dans une équipe en tant que nouveau joueur sans se décourager, ni à soi-même ni à l'équipe?

Comment puis-je influencer mon équipe pour qu'elle devienne plus agile? est liée, mais je ne suis pas un développeur Agile comme le demandeur ici, et je regarde un ensemble de méthodologies beaucoup plus large que Agile.

Il me semble que vous mettez la charrue avant les bœufs.

Quel est le principal problème de votre équipe et quelles technologies aideraient à le résoudre?

Par exemple, s'il y a beaucoup de bogues, en particulier de type de régression, les tests unitaires peuvent être un point de départ. Si votre équipe manque de temps, peut-être qu'un cadre pourrait vous aider (moyen à long terme). Si les gens ont de la difficulté à lire le code de chacun, le style peut être utile.

N'oubliez pas que le but de votre activité est de gagner de l'argent, pas du code.

Java? Moderne?! Vous avez échoué au premier obstacle. Si vous voulez être vraiment moderne et éviter le "suicide professionnel", alors vous devez écrire le code Rust. Bien sûr, tout va changer la semaine prochaine et vous devrez apprendre quelque chose d'encore plus récent pour suivre le rythme!

Ou bien , vous pouvez accepter qu'aucune quantité de technologies de mot à la mode ou des méthodes ou des cadres ou tout autre du jour changera le fait que vous voulez construire des produits de qualité qui fonctionnent. Peu importe que vous n'utilisiez pas agile si vous produisez correctement le bon résultat. Bien sûr, si vous ne l'êtes pas, vous voudrez peut-être changer les choses, mais il est peu probable qu'une pratique particulière résolve les problèmes. Ils resteront des problèmes humains qui peuvent être résolus de différentes manières.

En ce qui concerne le suicide professionnel, si vous savez ce que vous faites et êtes flexible, vous n’avez pas besoin de ce que vous avez mentionné. Les gens vont continuer à trouver de nouvelles façons de faire le travail ancien et vous serez toujours en train de rattraper. Ou vous pouvez simplement utiliser les techniques que votre entreprise actuelle utilise, peu importe. Lorsque vous changez d'entreprise, vous devez simplement apprendre et utiliser les techniques utilisées.

Trop d'enfants sont accrochés à tous les nouveaux outils qu'ils pourraient utiliser, oubliant qu'ils ne valent rien à un novice. Apprenez d'abord la pratique. Une fois que vous êtes un développeur expérimenté, vous pouvez commencer à "corriger" les pratiques de développement avec "de nouvelles choses cool", mais d'ici là vous espérez avoir réalisé qu'elles ne sont pas aussi importantes que vous le pensez actuellement. seulement pour être utilisé quand ils sont vraiment nécessaires.

Beaucoup d'entreprises sont bloquées comme ça; vous pourriez même être surpris de constater que certains de vos collègues développeurs sont des autodidactes qui sont devenus des développeurs sans aucune formation officielle. Ces développeurs ont souvent de meilleurs résultats, car ce sont eux qui sont motivés à acquérir de nouvelles compétences et à réussir au lieu de simplement faire le travail. Malheureusement, cela peut également signifier que, même s'ils sont excellents en programmation, ils pourraient ne pas être conscients des avantages de ces pratiques. Le fait est ce sont les meilleures pratiques, non communes pratiques. Les meilleurs les utilisent, mais ils ne sont pas du tout des exigences pour réussir, ce sont simplement des outils pour aider à rendre le succès plus facile.

Vous avez absolument raison, il va être difficile d'essayer de tout mettre en œuvre en même temps. Vous serez probablement fatigué (et peut-être par votre équipe) d'essayer de le faire, ce qui va démotiver les pressions futures pour adopter de nouvelles méthodologies / technologies. La meilleure chose à faire dans une situation comme celle-ci est de choisir unchose (la journalisation est probablement un bon début, car vous avez probablement une route difficile à parcourir avant de trouver des bogues sans vous connecter, et il est certain qu’il y aura des bugs) et parlez-en à l’équipe. Vous n'êtes pas obligé de mettre en œuvre cela seul; vous ferez beaucoup mieux de discuter des avantages et des inconvénients avec l'équipe (et votre patron, qui DOIT être absolument de la partie) et de préparer un plan pour la mettre en œuvre. Cela devra être aussi simple que possible (rappelez-vous que vous dites aux gens qu'ils doivent maintenant écrire du code supplémentaire en plus de ce qu'ils font déjà).

Et permettez-moi de répéter, assurez-vous que votre patron intervient . C'est crucial. vous constaterez probablement que la vitesse des correctifs / versions ralentit à mesure que vous implémentez de nouvelles choses. Le fait est que vous payez immédiatement pour économiser en bout de ligne; ils DOIVENT comprendre cela et être de votre côté. Si vous ne les impliquez pas, vous menez au mieux une bataille perdue, et au pire, ils pourraient vous considérer comme sabotant activement l'équipe (demandez-moi comment je le sais).

Une fois que vous apportez ces éléments à la table, discutez-en avec l'équipe, planifiez la manière de les mettre en œuvre et suivez les étapes suivantes, les deuxième, troisième, huitième, etc. seront plus faciles. De plus, l'équipe et votre patron ont le potentiel de vous respecter lorsque vos suggestions sont mises en œuvre et reconnues comme une valeur ajoutée. Génial! Assurez-vous simplement de rester flexible: vous appuyez ici contre l'inertie, et le changement n'est pas facile. être prêt à lentement faire petitmodifications et assurez-vous de pouvoir suivre les progrès et la valeur acquise. Si vous implémentez la journalisation dans un nouveau processus et que cela vous aide à gagner du temps en trouvant un bogue en trois semaines, faites-en une grosse affaire! Assurez-vous que tout le monde sait que l'entreprise vient d'économiser XXX $ en prenant les mesures qui s'imposent à l'avance. D'un autre côté, si vous avez du recul ou si vous avez un délai serré, n'essayez pas de forcer le problème. Laissez le nouveau changement glisser pour le moment, et revenez en arrière. Vous ne gagnerez jamais en essayant de forcer l’équipe à faire quelque chose qu’elle ne veut pas, et vous pouvez être sûr que la première chose qu’elle suggérera d’abandonner est le nouveau travail «supplémentaire» (comme écrire de la journalisation ou suivre un guide de style au lieu de simplement le faire fonctionner).

J'espère que vous n'avez pas présenté les problèmes à vos collègues comme vous nous l'avez fait dans votre message. CELA serait un suicide professionnel.

Le premier problème est que vous essayez d’enseigner des technologies et des méthodes que vous n’avez même pas expérimentées à un groupe de programmeurs qui, peut-être, sont un peu dépassés, mais accomplissent leur travail "bien". Les possibilités de ce retour de flamme sont infinies et apporteront probablement beaucoup de joie à vos collègues. Il est intéressant et admirable que vous souhaitiez vous améliorer et améliorer votre service, mais évitez d'utiliser des termes tels que "fer de lance". Sincèrement, n'utilisez pas ce mot.

En plus de ce qui précède, vérifiez que vous faites du travail . Je travaille depuis très longtemps en tant que programmeur solitaire et auto-apprenant, et je sais qu’il est facile de mettre de côté le travail réel afin d’explorer des cadres, technologies, etc. prometteurs. Assurez-vous que votre performance est dans les paramètres attendus (non, personne ne se soucie que vous passiez 20 heures à faire des recherches sur Spring si le rapport qu'ils vous demandaient n'était pas fait).

De tout ce qui précède, évitez d’être l’enseignant (sauf s’il est lié à un domaine / une technologie dans lequel vous avez réellement assez d’expérience). Une présentation plus neutre montrerait les avantages, par exemple, des tests automatisés, et laisserait la direction choisir qui elle veut pour rechercher les avantages et les inconvénients de ces pratiques.

Maintenant, pour présenter ces "meilleures pratiques", il y a deux façons de les expliquer à votre équipe:

• Parce que je dis que ce sont les meilleures pratiques, et cela suffit.
• Parce qu'ils sont utiles et aident à résoudre le problème.

En utilisant le premier argument, à moins que vous ne soyez le patron ou un membre très expérimenté de l'équipe, il est peu probable qu'ils vous prêtent attention. Et "j'ai lu un livre de Knuth qui le dit" ou "les gars de la SE disent que" ne causera aucune impression, non plus ("ces gars-là ne travaillent pas ici, donc ils ne savent pas vraiment ce qui est bon pour ce magasin d'informatique "). Ils ont leurs méthodes, routines, procédures et autres choses qui fonctionnent "plus ou moins", alors pourquoi prendre l'effort et les risques de changer?

Pour que la deuxième approche fonctionne, il faut réaliser qu’un problème existe . Alors:

• n'allez pas pousser jour et nuit pour des tests automatiques. Attendez qu'une mise à jour casse certaines fonctionnalités et que l'équipe soit obligée de travailler plus de temps pour la réparer, puis proposez de créer un système de test automatisé.
• ne demandez pas de code. Attendez que Joe soit en congé prolongé et qu'il soit nécessaire de modifier ce module dont seul Joe est au courant, et montrez à votre patron combien de temps a été perdu pour essayer de comprendre le code de Joe.

Bien entendu, le changement sera lent et progressif (plus encore dans une grande entreprise). Si vous introduisez la révision du code et les tests automatisés dans cinq ans, félicitez-vous pour un travail bien fait. Mais, sauf en cas de réécriture complète due à des causes externes, oubliez tout fantasme selon lequel ils changeront le système d'information central pour, par exemple, Spring ( Joel a expliqué cela mieux que je n'aurais jamais pu le faire, même avant votre naissance ¹ ); pendant cette période, vous pourriez tout au plus avoir Spring dans la liste des plates-formes prises en charge pour écrire des systèmes non critiques.

Bienvenue dans le monde de l'informatique d'entreprise, mon garçon! :-p

¹ : Ok, peut-être que j'exagère un peu, mais pas trop.

Vous devriez commencer par le livre Travailler efficacement avec Legacy Code de Michael Feathers. Dans l'introduction du livre, "Il s'agit de prendre un système enchevêtré, opaque, alambiqué et lentement, progressivement, pièce par pièce, étape par étape, en le transformant en un système simple, bien structuré et bien conçu". Il commence généralement par des tests automatisés, afin que vous puissiez refactoriser en toute sécurité (vous saurez si vous cassez quelque chose), et il inclut de nombreuses stratégies pour intégrer du code difficile dans des tests automatisés. Ceci est utile pour tous les projets en cours de développement. Une fois que vous avez un ordre de base en place, vous pouvez voir quelles autres technologies modernes votre projet pourrait vraiment bénéficier - mais ne supposez pas que vous en avez besoin toutes.

Si vous souhaitez apprendre un nouveau cadre (ou quelque chose) pour des raisons professionnelles plutôt que parce que votre projet actuel en a réellement besoin, vous devez l’utiliser dans un projet personnel (à votre rythme).

Contrôle de source.

Vous n'en avez pas parlé, espérons-le, car il est déjà en place, mais dans le cas contraire, commencez par là.

Le contrôle de source a le meilleur rapport qualité-prix, sauf dans de rares circonstances pathologiques nécessitant autre chose.

Et vous pouvez commencer seul si personne n'achète initialement.

Une réponse directe

D'autres réponses constituent de bons «méta-points» sur l'adoption de meilleures pratiques, mais pour vous donner des conseils directement pertinents, voici un ordre approximatif des meilleures pratiques que je suggérerais à votre équipe (ou à toute équipe) d'adopter (en premier):

1. Contrôle de la source
2. Suivi des problèmes (gestion de projet et de tâches)
3. Constructions automatisées ¹
4. Déploiements automatisés

^{1 _{Une pratique très liée consiste à automatiser, ou du moins à documenter , la configuration de l'environnement de construction et de développement de chaque application ou projet logiciel que vous développez ou maintenez. C'est beaucoup moins utile parce que vous le faites (espérons-le) rarement ou rarement.}}

Tout le reste

Vous mentionnez plusieurs autres bonnes pratiques - "tests unitaires, journalisation, normalisation de la base de données, ... refactoring, ... documentation" - mais ce sont toutes des pratiques qui peuvent et doivent être adoptées progressivement et progressivement. Aucune d'entre elles n'a besoin d'être adoptée en une fois et vous ferez probablement mieux de les adopter du tout en les adoptant avec soin et conscience.

Les quatre pratiques que j'ai énumérées ci-dessus faciliteront également l'adoption et l'expérimentation de nouvelles pratiques. Par exemple, les tests unitaires peuvent être intégrés à vos versions automatisées et la documentation peut être publiée dans le cadre de vos déploiements automatisés.

Certaines des autres pratiques que vous mentionnez - "développement agile, ... guides de style de codage, ... revues de code, ... méthodes de documentation normalisées" et frameworks (par exemple, Spring) - sont vraiment optionnelles ou ont une valeur douteuse. Et c'est le cas de beaucoup (de la plupart?) Des pratiques possibles que vous découvrirez ou rencontrerez.

Le développement agile n'est évidemment pas supérieur à toute autre méthodologie utilisée. Et beaucoup de gens (y compris moi-même) en ont fait des expériences horribles . Mais beaucoup de gens l'aiment vraiment (ou l'aiment) aussi. Essayez le!

Les guides de style de codage peuvent être utiles, en particulier pour les grands projets, ou dans les grandes équipes, mais il faut également beaucoup de travail pour appliquer ces directives et ce n'est peut-être pas la meilleure utilisation de son temps.

Les revues de code peuvent également être très utiles - avez-vous demandé à vos collègues de réviser votre code? Gardez à l'esprit que vous n'avez pas besoin d'un processus formel pour adopter de bonnes pratiques!

La documentation est excellente - en avez-vous? Si oui, tant mieux pour vous! Êtes-vous confronté à beaucoup de travail supplémentaire qui pourrait être évité en ayant une documentation (plus) "standardisée"? Si vous êtes, alors c'est probablement quelque chose qui vaut la peine d'être fait. Toutefois, si votre logiciel est utilisé par un petit groupe de personnes, vous n’avez peut-être pas besoin de documentation. (Ou vous pouvez directement incorporer la documentation dans votre logiciel. C'est toujours ma préférence.)

Les cadres sont ... une épée (très tranchante) à double tranchant. Une solution bien encapsulée et bien maintenue pour une fonctionnalité non essentielle de votre logiciel est excellente… tant qu'elle ne l'est pas. Je ne suis pas sûr de ce que sont exactement les "contrôleurs frontaux écrits à la main" mais il n'y a pas d' explication évidente de la raison pour laquelle ils sont inférieurs au code qui exploite Spring. Avez-vous envisagé d'intégrer la logique commune de tous ces contrôleurs dans votre propre cadre interne? L'adoption de Spring et la réécriture de tout votre code existant pourraient constituer un immense projet de refactoring (ou, plus probablement, de réécriture) et pourraient ne pas constituer le meilleur changement que vous puissiez apporter à votre code . Bien sûr, vous ne devriez pas écrire tous les logiciels que vous utilisez - les frameworks (et les bibliothèques) sont excellents!Mais peut-être n'avez - vous pas besoin d'utiliser Spring (ou une alternative) pour écrire de bonnes (ou bonnes) applications Web.

Regardez autour de vous l'équipe dont vous faites partie. Pouvez-vous voir des preuves que le développement piloté par les tests ou la normalisation de bases de données vont améliorer la qualité du logiciel que vous écrivez ou rendre les gens plus productifs?

Avez-vous essayé d'en parler à l'un des superviseurs du développement ou au responsable du développement? Une discussion vraiment informelle serait un bon début. Qu'est-ce qui vous fait penser que les personnes supérieures à vous n'ont pas eu les mêmes idées mais ne peuvent / ne veulent pas les mettre en œuvre parce que l'entreprise ne le permet pas?

Je trouve que prêcher par l'exemple est un bon moyen d'aller de l'avant. Les gens sont beaucoup moins résistants si quelqu'un d'autre a déjà fait le travail et peut leur montrer comment le reproduire. Introduisez TDD dans un projet sur lequel vous travaillez. Demandez à faire une présentation au reste de l'équipe, ou même à quelques autres, et montrez-leur ce que vous avez fait. Ce que @DrewJordan a dit à propos de l'obtention de l'adhésion du patron est plus important que vous ne le réalisez probablement.

Trouvez une faille. Correction d'un défaut. Afficher le correctif.

Prenons d'abord la normalisation *. Et en effet, je vous conseillerais de commencer par le prendre, car le manque de normalisation risque de générer des données de bogue qui ne pourraient pas exister autrement, alors que les autres sont des exemples de bonnes pratiques qui pourraient aider, mais il est plus difficile de dire "Bug A a été causé par le non-respect de la politique X ". Si votre base de données n'est pas normalisée, vous avez un endroit où les données peuvent être incohérentes.

Il est fort à parier que vous pourrez trouver un cas réel de données incohérentes. Vous avez maintenant trouvé deux choses:

1. Un bug dans vos données.

2. Un bug dans vos schémas de base de données.

En fait, vous connaissiez d’abord le deuxième bogue, mais le premier est plus facilement démontrable et pose également un problème réel, et non théoriquement.

Malheureusement, l’une des vraies raisons de résister à la normalisation de la base de données dénormalisée est que la question de savoir quoi faire avec de telles données boguées n’est pas toujours facile, mais vous aurez trouvé un bogue réel.

(Sachez cependant qu'il existe des raisons pour lesquelles on peut parfois dénormaliser certaines données volontairement. Ne confondez pas le non-respect de la règle avec la méconnaissance de la règle; si vous normalisez une table délibérément dénormalisée pour la vitesse de recherche, vous gagnez Même si ici, la dénormalisation étant lourde est quelque chose qui devrait être fait de manière procédurale, donc si la table dénormalisée n'est pas créée automatiquement en fonction du contenu des tables normalisées, il reste encore des progrès à faire).

Pour le reste, présentez-les lorsqu'ils vous aident à court terme, pour ensuite les utiliser à long terme. Par exemple, si vous devez construire un petit morceau de code, écrivez un test unitaire pour cela. Mieux encore, si un bogue à corriger vous est demandé, écrivez un test unitaire qui échoue à cause du bogue, puis lorsque vous avez corrigé le bogue, mentionnez le fait qu'il passe lorsque vous fermez les bogues (ou envoyez un e-mail lui indiquant qu'il est corrigé.) , ou peu importe).

* Incidemment, pas très moderne. La raison pour laquelle on l'appelle la normalisation et non normalisant ou autre chose, est que au moment où elle était une blague locale pour coller -ization sur la fin des choses à se moquer du nom de Richard Nixon vietnamisation politique.

Je vais aller à contre-courant et dire: trouvez un nouvel emploi après avoir passé du temps chez celui-ci pour construire un peu votre CV. But pour un an ou deux. Bien que beaucoup de choses soient des "mots à la mode", des problèmes tels que l'absence totale de tests unitaires sont insolubles pour un seul développeur, et il est probable que si les programmeurs qui y travaillent n'ont aucune envie de tester, vous ne serez jamais acheté et cela pourrait même compromettre votre position. à la société en faisant en sorte que les gens vous perçoivent comme un dur. Vous devez être dans un endroit où vous pouvez obtenir un mentorat, sans chercher à pousser la culture vers la compétence de base.

Il y a eu beaucoup de propositions pour améliorer le paradigme de la programmation . Les mots à la mode les plus recherchés semblent maintenant être une programmation agile et orientée objet. Ou sont-ils? Les deux ont considérablement diminué par rapport à ce qu'ils étaient il y a cinq ans.

Vous pouvez être assez confiant que la méthode mise en place tente d'atteindre le même résultat final: aider les ingénieurs à produire économiquement un produit final suffisamment bon.

Il y a un paradigme qui a été introduit de façon controversée dans les années 1960: la programmation structurée : utiliser uniquement « haut niveau » construit comme while, for, repeat, if/ then/ else, switch/ casedéclarations au lieu de la très utilisée gotodéclaration qui avait été acceptée par défaut. Il y a encore des débats pour savoir si gotoa un usage légitime du tout.

J'admets que minimiser l'utilisation de gotoest une bonne chose, mais comme toutes les bonnes choses, il est possible d'aller trop loin.

Vous mentionnez les agileméthodologies comme quelque chose de positif. J'ai fait partie d'une équipe de développement pendant environ six mois qui suivait intentionnellement un régime agile prescrit. J'ai trouvé que c'était juste comme des méthodologies éclairées de gestion de projet d'il y a des décennies, sauf que tout est renommé. Peut-être qu'en regroupant et en revendant des idées pour communiquer, on gagne sa vie et les entreprises peuvent se sentir bien de "voir" les nouveaux vêtements de l' empereur .

La leçon la plus précieuse d'Agile, connue de longue date, est que la flexibilité de trouver un meilleur chemin vers le produit fini est une bonne chose et que la capacité de trouver ce chemin peut venir de n'importe qui, pas seulement de la direction.

D'après un écrit de Edsger Dijkstra, chef de file anti-goto:

L'art de la programmation est l'art d'organiser la complexité, de maîtriser la multitude et d'éviter au mieux son chaos bâtard.

—Dijkstra, dans: Dahl, Dijkstra & Hoare 1972, pg. 6. (voir page 6 ici .)