Où mon équipe devrait-elle commencer à devenir "moderne"?
Je suis un développeur relativement nouveau, fraîchement sorti de l'université. Pendant mes études universitaires et lors de ma recherche d'emploi, j'ai réalisé qu'il y avait beaucoup de méthodologies de développement de logiciels "modernes" qui manquaient à mes études: tests unitaires, journalisation, normalisation de base de données, développement agile (par rapport aux concepts agiles génériques), style de codage guides, refactoring, revues de code, pas de méthodes de documentation standardisé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 sur le tas. Ensuite, j'ai obtenu mon premier emploi (développement web full stack) dans une grande entreprise et j'ai réalisé que nous ne faisons aucun de ces choses. En fait, c'est moi, le moins expérimenté de l'équipe, qui suis le fer de lance des tentatives pour mettre mon équipe au courant des techniques de programmation "modernes" - car je crains que ne pas le faire soit un suicide professionnel sur la route.
J'ai d'abord commencé par un logiciel de journalisation (log4J), mais j'ai ensuite rapidement écrit mon propre guide de style, puis je l'ai abandonné pour le guide de style Google - puis j'ai réalisé que notre Java développement Web utilisait la main contrôleurs frontaux écrits, alors j'ai poussé pour notre adoption de Spring - mais j'ai réalisé que nous n'avions pas non plus de tests unitaires, mais j'apprenais déjà Spring ... et comme vous pouvez le voir, cela devient écrasant trop rapidement, surtout quand En outre, il m'est difficile de devenir suffisamment "expert" dans ces méthodologies pour enseigner à quelqu'un d'autre sans consacrer trop de temps à une seule d'entre elles, et encore moins à toutes.
De toutes ces techniques, que je considère comme "attendues" dans le monde du développement logiciel d'aujourd'hui, comment les intégrer dans une équipe en tant que nouveau joueur sans me submerger moi-même et l'équipe?
Comment puis-je influencer mon équipe à devenir plus agile? est lié, 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 le cheval.
Quel est le problème majeur auquel votre équipe est confrontée et quelles technologies pourraient aider à le résoudre?
Par exemple, s'il y a beaucoup de bogues, en particulier des bogues de type régression, les tests unitaires peuvent être un point de départ. Si votre équipe manque de temps, un cadre peut peut-être vous aider (à moyen ou long terme). Si les gens ont du mal à lire le code des autres, le style peut être utile.
N'oubliez pas que le but de l'entreprise pour laquelle vous travaillez est de gagner de l'argent, pas de faire du code.
Java? Moderne?! Vous avez échoué au premier obstacle. Si vous voulez être vraiment moderne et éviter le "suicide professionnel", vous devez écrire Rust code. Bien sûr, la semaine prochaine, tout changera et vous devrez même apprendre quelque chose plus récent pour suivre!
Ou, vous pouvez accepter qu'aucune quantité de technologies, de méthodologies ou de cadres de mots à la mode ou de tout autre du jour ne changera le fait que vous souhaitez créer des produits de qualité qui fonctionnent. Peu importe si vous n'utilisez pas Agile si vous réussissez à produire la bonne sortie. Bien sûr, si vous ne l'êtes pas, vous voudrez peut-être changer les choses, mais il est probable qu'aucune pratique particulière ne résoudra les problèmes. Ils resteront 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 besoin d'aucune des choses que vous avez mentionnées. Les gens continueront à trouver de nouvelles façons de faire l'ancien travail et vous serez toujours à la hauteur. Ou vous pouvez simplement utiliser les techniques utilisées par votre entreprise actuelle. Lorsque vous changez d'entreprise, vous apprenez et utilisez simplement les techniques qu'ils utilisent.
Trop d'enfants sont accrochés à tous les nouveaux outils qu'ils pourraient utiliser, oubliant que ces outils ne valent rien entre les mains d'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 intéressantes", mais d'ici là, vous aurez réalisé, espérons-le, qu'elles ne sont pas aussi importantes que vous le pensez actuellement, et à n'utiliser que lorsqu'ils sont vraiment nécessaires.
De nombreuses entreprises sont bloquées comme ça; vous pourriez même être surpris de constater que certains de vos collègues développeurs sont autodidactes et sont devenus des développeurs sans aucun bagage formel. Ces développeurs sont souvent meilleurs dans leur travail, car ce sont eux qui seront amené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 peuvent ne pas être conscients des avantages de ces pratiques. Le fait est que ce sont les meilleures pratiques , pas les pratiques courantes . Les meilleurs les utilisent, mais ce ne sont pas du tout des conditions pour réussir, ce sont simplement des outils pour faciliter le succès.
Vous avez tout à fait raison, ce sera écrasant d'essayer de tout mettre en œuvre en même temps. Vous vous épuiserez probablement (et peut-être votre équipe) en essayant de le faire, ce qui va démotiver les futures poussées à adopter de nouvelles méthodologies/technologies. La meilleure chose à faire dans une situation comme celle-ci est de choisir ne chose (la journalisation est probablement un bon début, car vous avez probablement du mal à trouver des bogues sans vous connecter, et il y aura certainement bugs) et en parler à l'équipe. Vous n'avez pas à implémenter cela seul; vous ferez beaucoup mieux de discuter des avantages et des inconvénients avec l'équipe (et votre patron, qui DOIT absolument être à bord avec quelque chose comme ça) et proposer un plan pour le mettre en œuvre. Cela devra être aussi indolore que possible (rappelez-vous, vous dites aux gens qu'ils doivent maintenant écrire du code supplémentaire en plus de ce qu'ils ont déjà faire).
Et permettez-moi de répéter, assurez-vous que votre patron achète . C'est crucial; vous constaterez probablement que la vitesse des correctifs/versions ralentit lorsque vous implémentez de nouvelles choses. Le fait est que vous payez d'avance pour économiser sur toute la ligne; ils DOIVENT comprendre cela et être de votre côté. Si vous ne les embarquez pas, vous livrez au mieux une bataille perdue et, au pire, ils peuvent vous considérer comme sabotant activement l'équipe (demandez-moi comment je le sais).
Une fois que vous avez apporté ces éléments à la table, discutez-en avec l'équipe, planifiez comment les mettre en œuvre et suivez-les, les deuxième, troisième, huitième, etc. seront plus faciles. Non seulement cela, il y a un potentiel pour l'équipe et votre patron de gagner le respect pour vous lorsque vos suggestions sont mises en œuvre et reconnues comme une valeur ajoutée. Génial! Assurez-vous simplement de rester flexible: vous poussez contre l'inertie ici, et le changement n'est pas facile. soyez prêt à lentement apporter de petites modifications , et assurez-vous que vous pouvez suivre les progrès et la valeur gagnée. Si vous implémentez la journalisation dans un nouveau processus et que cela vous aide à gagner des heures à trouver 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 faisant ce qu'il faut à l'avance. D'un autre côté, si vous obtenez un 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 faire, 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 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. Ce serait un suicide professionnel.
Le premier problème est que vous essayez d'enseigner des technologies et des méthodes que même vous n'avez pas d'expérience à un groupe de programmeurs qui, peut-être sont un peu dépassés, mais qui font le travail "fait". 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 comme "fer de lance". Sincèrement, n'utilisez pas ce mot.
Comme problème secondaire à ce qui précède, vérifiez que vous faites du travail. Je travaille en tant que programmeur autonome et autodidacte depuis beaucoup de temps, et je sais combien il est facile de mettre de côté le travail réel afin d'explorer des cadres, des technologies et autres prometteurs. Assurez-vous que vos performances respectent les paramètres attendus (non, personne ne se soucie que vous passiez 20 heures à rechercher Spring si ce rapport qu'ils vous ont demandé n'est pas fait).
De tout ce qui précède, évitez d'être l'enseignant (à moins qu'il ne soit lié à un domaine/technologie dans lequel vous avez en fait suffisamment d'expérience). Une présentation plus neutre indiquerait les avantages, par exemple, des tests automatisés, et laisser la direction choisir qui ils veulent 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 c'est suffisant.
- 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 senior de l'équipe, il est peu probable qu'ils vous accordent une attention particulière. 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 ne travaillent pas ici donc ils ne savent pas vraiment ce qui est bon pour cette boutique informatique "). Ils ont leurs méthodes, routines, procédures et choses "plus ou moins" qui fonctionnent, alors pourquoi prendre l'effort et les risques de changer?
Pour que la deuxième approche fonctionne, il faut la prise de conscience qu'un problème existe . Donc:
- n'allez pas pousser jour et nuit pour des tests automatiques. Attendez qu'une mise à jour casse certaines fonctionnalités, et l'équipe doit faire des heures supplémentaires pour la réparer, puis proposer de construire un système de test automatisé.
- ne demandez pas de revues de code. Attendez que Joe soit en congé prolongé et il est nécessaire de modifier ce module que seul Joe connaît, et montrez à votre patron combien de temps a été perdu en essayant de comprendre le code de Joe.
Bien sûr, le changement sera lent et progressif (plus encore dans une grande entreprise). Si vous arrivez à introduire la révision de code et les tests automatisés dans cinq ans, vous devriez vous féliciter pour le travail bien fait. Mais, à moins qu'il n'y ait une réécriture complète due à des causes externes, oubliez tout fantasme selon lequel ils changeraient le cœur IS pour, disons, Spring ( Joel a expliqué cela mieux que moi) jamais pu, même avant ta naissance1 ); pendant ce temps, vous pourriez, tout au plus, obtenir 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
1: Ok, peut-être que j'exagère un peu, mais pas trop.
Vous devriez commencer par le livre Working Effectively with Legacy Code de Michael Feathers. De l'introduction du livre, "Il s'agit de prendre un système enchevêtré, opaque et alambiqué et lentement, progressivement, morceau par morceau, étape par étape, en le transformant en un système simple, bien structuré et bien conçu." Il commence principalement 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 mettre du code difficile sous test automatisé. 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 de quelles autres technologies modernes votre projet pourrait vraiment bénéficier - mais ne supposez pas que vous en avez besoin.
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 ne l'avez pas mentionné, je l'espère parce qu'il est déjà en place, mais, dans le cas contraire, commencez par là.
Le contrôle des sources a le meilleur rapport qualité-prix, sauf dans de rares circonstances ayant besoin pathologiquement d'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, juste pour vous donner des conseils directement pertinents, voici un ordre approximatif de le meilleur pratiques que je suggérerais à votre équipe (ou à tout autre équipe) adopter (premier):
- Contrôle de source
- Suivi des problèmes (gestion des projets et des tâches)
- Constructions automatisées1
- Déploiements automatisés
1Une pratique très connexe consiste à automatiser, ou au moins document, 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 car vous (espérons-le) faites cela 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 devraient être adoptées progressivement et progressivement . Aucun d'entre eux n'a besoin d'être adopté d'un seul coup et vous ferez probablement mieux de les adopter du tout en les adoptant avec soin et attention.
Les quatre pratiques que j'ai énumérées ci-dessus rendront également l'adoption et l'expérimentation de nouvelles pratiques aussi faciles que possible. 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, ... révisions de code, ... méthodes de documentation normalisées" et cadres (par exemple Spring) - sont vraiment facultatives ou d'une valeur douteuse. Et cela est vrai pour beaucoup (la plupart?) Des pratiques possibles que vous découvrirez ou rencontrerez.
Le développement agile n'est pas évidemment supérieur à toute autre méthodologie utilisée. Et beaucoup de gens (y compris moi-même) ont eu horrible expériences avec ça. Mais beaucoup de gens l'aiment vraiment (ou l'aiment) aussi. Essayez!
Les guides de style de codage peuvent être utiles, en particulier pour les grands projets ou dans de grandes équipes, mais c'est aussi beaucoup de travail pour appliquer ces directives et ce n'est peut-être pas la meilleure utilisation du temps de qui que ce soit le fait.
Les révisions 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 l'êtes, c'est probablement quelque chose qui vaut la peine d'être fait. Cependant, si votre logiciel est utilisé par un petit groupe de personnes, vous n'aurez peut-être pas besoin de documentation any. (Ou vous pouvez directement intégrer 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 entretenue pour une fonctionnalité non essentielle de votre logiciel est excellente ... jusqu'à ce qu'elle ne le soit pas. Je ne sais pas exactement ce que sont les "contrôleurs frontaux écrits à la main", mais il n'y a pas d'explication évidente pour expliquer pourquoi ils sont inférieurs au code qui exploite Spring. Avez-vous pensé à encapsuler la logique commune de tous ces contrôleurs dans votre propre infrastructure interne? L'adoption de Spring et la réécriture de tout votre code existant pourraient être un immense projet de refactoring (ou, plus probablement, de réécriture) et ce ne serait peut-être pas le meilleur changement que vous pourriez apporter à votre code . Bien sûr vous ne devriez pas écrire tous les logiciels que vous utilisez - les frameworks (et bibliothèques) sont super! Mais peut-être vous n'avez pas besoin d'utiliser Spring (ou une alternative) pour écrire de superbes (ou bonnes) applications Web.
Trouvez un défaut. Correction d'un défaut. Montrez le correctif.
Prenons d'abord la normalisation *. Et en effet, je vous suggère de le prendre en premier, car un manque de normalisation entraînera probablement des données de bogue réelles qui ne pourraient pas exister autrement, tandis que les autres sont des cas où les meilleures pratiques pourraient probablement aider, mais il est plus difficile de dire "Bogue A a été causé par le non-respect de la stratégie X ". Si vous avez une base de données qui n'est pas normalisée, alors vous avez un endroit où les données peuvent être incohérentes.
Il y a fort à parier que vous pourrez trouver un cas réel de données incohérentes. Vous avez maintenant trouvé deux choses:
Un bug dans vos données.
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 aussi quelque chose qui cause un vrai problème, pas quelque chose qui pourrait 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 de buggy n'est pas toujours facile, mais vous aurez trouvé un bug réel.
(Sachez cependant qu'il y a des raisons pour lesquelles on peut parfois dénormaliser certaines données à dessein. Ne confondez pas la violation de la règle et l'ignorance de la règle; si vous normalisez une table délibérément dénormalisée pour accélérer la recherche, vous avez gagné Même ici, dénormaliser la lourdeur 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 y a encore des progrès à faire).
Pour le reste, présentez-les lorsqu'ils vous aident à court terme, pour ensuite les développer à long terme. Par exemple. si vous disposez d'un petit morceau de code à construire, écrivez un test unitaire pour celui-ci. Mieux encore, si vous recevez un bogue à corriger, é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 disant qu'il est corrigé). , ou peu importe).
* Soit dit en passant, pas très moderne. La raison pour laquelle on l'appelle normalisation et non normalisation ou autre chose, c'est qu'à l'époque c'était une blague d'actualité à coller - - ization sur le fin des choses pour se moquer du nom de la politique Vietnamisation de Richard Nixon.
Regardez autour de l'équipe dont vous faites partie. Pouvez-vous voir des preuves que le développement piloté par les tests ou la normalisation des bases de données amélioreront la qualité du logiciel que vous écrivez ou rendront les gens plus productifs?
Avez-vous essayé d'en parler à l'un des superviseurs du développement ou au responsable du développement? Un chat vraiment informel serait un bon début. Qu'est-ce qui vous fait penser que les personnes ci-dessus n'ont pas eu les mêmes idées mais ne peuvent pas/ne les mettront pas en œuvre parce que l'entreprise ne le permettra pas?
Je trouve que montrer l'exemple est une bonne façon de procéder. 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'adhésion du patron est plus important que vous ne le pensez probablement.
Je vais aller à contre-courant et dire: trouver un nouvel emploi après avoir passé un peu de temps à celui-ci pour construire un peu votre CV. Visez un an environ. Bien que beaucoup de choses soient des "mots à la mode", des problèmes comme un manque total de tests unitaires sont insolubles pour un seul développeur, et il est probable que si les programmeurs qui y travaillent n'ont aucun désir de tester, vous n'obtiendrez jamais d'achat et pourrez même compromettre votre position à l'entreprise en faisant en sorte que les gens vous considèrent comme un coup dur. Vous devez être dans un endroit où vous pouvez obtenir du mentorat, pas essayer de pousser la culture vers les compétences de base.
Il y a eu beaucoup de propositions pour améliorer le paradigme de programmation . Les mots à la mode les plus en vogue semblent désormais être une programmation agile et orientée objet. Ou sont-ils? Les deux se sont nettement estompés par rapport à ce qu'ils étaient il y a seulement cinq ans.
Vous pouvez être assez confiant que, quelle que soit la méthodologie mise en place, elle 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é controversé dans les années 1960: programmation structurée : n'utilisez que des constructions "de haut niveau" comme while, for, repeat , if/then/else, switch/case instructions au lieu de l'instruction goto très utilisée qui avait accepté par défaut. Il y a toujours débats pour savoir si goto a une utilisation légitime.
J'accepte que minimiser l'utilisation de goto est une bonne chose, mais comme toutes les bonnes choses, il est possible d'aller trop loin.
Vous mentionnez agile les méthodologies comme quelque chose de positif. J'ai été dans une équipe de développement pendant environ six mois qui a intentionnellement suivi un régime agile prescrit. J'ai trouvé que c'était comme les méthodologies de gestion de projet éclairées 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, quelqu'un gagne sa vie et les entreprises peuvent se sentir bien à "voir" les nouveaux vêtements de l'empereur .
La leçon la plus précieuse d'Agile, connue depuis longtemps, est que la flexibilité pour trouver un meilleur chemin vers le produit fini est une bonne chose et la capacité de trouver ce chemin peut venir de n'importe qui, pas seulement de la haute direction.
D'après un écrit du chef anti-goto Edsger Dijkstra:
L'art de la programmation est l'art d'organiser la complexité, de maîtriser la multitude et d'éviter son chaos bâtard le plus efficacement possible.
—Dijkstra, dans: Dahl, Dijkstra & Hoare 1972, p. 6. (voir page 6 ici .)