Par où mon équipe doit-elle commencer par devenir «moderne»? [fermé]


106

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.


92
"moderne"? Supprimez ce mot à la mode "agile" de votre liste et je ne peux voir que des choses avec un âge supérieur à 20 ans.
Doc Brown

10
Peut-être "moderne" en ce sens que leur adoption généralisée est moderne, pas la genèse des idées, alors? Je ne suis pas un expert sur ce sujet non plus, c'est juste mon impression.
WannabeCoder

41
Je vous assure que les tests unitaires, la journalisation, la normalisation de la base de données, les guides de style de codage, les inspections de code (= révisions) ont tous plus de 30 ans. Le terme "refactoring" a au moins 15 ans (Fowler a écrit son livre en 2000). Et ne pas avoir de documentation officielle ou d'exigences écrites n'est pas "une technique moderne", ce n'est pas même une "technique" à mon humble avis.
Doc Brown

69
@DocBrown, admettez-le, vous venez de renvoyer Marty dans le temps pour créer toutes ces choses avant de faire votre commentaire.
null

17
Je suis plus préoccupé par le fait que son collège n'enseigne pas ces matières à l'avance - j'ai été absent de l'école pendant plus de 15 ans et la plupart de ces choses ont été couvertes assez tôt. (Minus les mots à la mode, bien sûr).
Allen Gould

Réponses:


165

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.


35
Plutôt. En partie du point de vue pragmatique de devoir commencer quelque part et en partie du point de vue de la réputation, si vous pouvez résoudre un problème pour l'équipe, elle sera peut-être plus disposée à écouter les autres suggestions. N'oubliez pas non plus que cette société gagnait de l'argent avant votre arrivée avec ses méthodes existantes, donc ce que vous mettez en place doit augmenter la capacité de cette entreprise à rapporter de l'argent.
Jaydee

6
Accepter cela, mais j'apprécierais un suivi pour faire face aux risques de ce métier (par exemple, "mon CV aurait plus de contenu, mais mon ancien travail
n'encadrerait

4
@WannabeCoder - Vous devez commencer à l'utiliser avant de devenir compétent. Vous pouvez toujours mettre du code en production. Parfois, coder, c'est comme être un médecin. Nous pratiquons tous encore.
JeffO

5
Très bonne réponse. Vous ne devriez implémenter ces choses que pour résoudre des problèmes, pas pour créer des problèmes.
Kik

5
@WannabeCoder Il est important de réaliser qu'aucune de ces méthodologies n'a été créée en vase clos. Ils se répandent parce qu'ils aident à résoudre des problèmes . Si vous essayez de les mettre en œuvre et que cela ne vous aide pas à résoudre les problèmes auxquels votre équipe est confrontée, vous n'avez rien accompli et avez peut-être complètement mal compris et abusé des pratiques. En tant que développeur, votre objectif doit être de résoudre les problèmes dans chaque action que vous entreprenez. Cherchez des petites victoires où la mise en place de ces pratiques un peu plus améliorera la situation. Cela aide à construire un cas pour les développer.
jpmc26

77

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.


4
Très belle réponse (+1), surtout le dernier paragraphe. Un livre très moderne (moderne au sens où je le trouve très pertinent aujourd'hui) que je lis récemment est SICP.
Giorgio

1
+1 pour la rapidité avec laquelle ces mots à la mode et les langues populaires changent. Un bon développeur qui met un bon code surpasse toute méthodologie. Faites ce qui fonctionne et fonctionne bien!
WeRelic

2
Bien que vous ayez raison de dire qu’ils doivent être utilisés correctement, je ne partage pas l’idée selon laquelle "ils ne sont pas aussi importants que vous le pensez actuellement". Bien sûr, cela peut être vrai de certaines pratiques (je suis un peu sceptique quant aux tests unitaires.), Mais d’autres sont extrêmement utiles. J'ai eu la chance de commencer à faire beaucoup de CI, d'automatisation et de bon usage du contrôle de source, et maintenant, travaillant sur un projet où ils ne sont pas présents, je vois tous les problèmes que nous voulions résoudre en action: erreurs, incohérences. , personne ne sait quel code est où, les travaux. Ces pratiques font une énorme différence.
jpmc26

6
Personne ne dit "ne résout pas les problèmes", le problème est lorsque des solutions sont introduites à la recherche de problèmes à résoudre. Ils ne sont pas aussi importants que beaucoup le pensent, les défenseurs du fret pensent que les outils sont la partie importante, alors qu’ils ne sont en réalité que des outils. C'est le praticien qui compte et quels que soient les outils qui fonctionnent aux bons endroits sont ceux à choisir. mon propos est de ne jamais choisir un outil simplement parce que c'est dans la boîte à outils.
gbjbaanb

2
Un imbécile avec un outil est toujours un imbécile.
Pete Becker

40

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).


6
Je doute que vous vouliez vraiment dire ce que je voulais dire par là, mais je suis un peu gêné par les développeurs comme moi sans une formation universitaire compsci. Mon expérience a (malheureusement malheureusement) montré que l’enseignement universitaire avait peu de corrélation avec la qualité du développeur. Et jusqu’à présent dans ma carrière, j’ai été l’un de ceux qui ont préconisé et mis en œuvre les meilleures pratiques. Votre conseil est bon cependant.
djeikyb

5
En fait, je le pensais autrement: le PO serait surpris par le nombre de bons développeurs qui n’ont pas d’éducation formelle. Au cours des 20/30 dernières années, de nombreux postes en technologie ont été pourvus par des personnes désireuses d’apprendre plutôt que par des enfants diplômés. Et mes conclusions reflètent les vôtres: l'expérience est toujours meilleure que l'éducation. C’est la raison pour laquelle le PO doit aller lentement. Pousser une équipe à adopter trop rapidement de nouvelles pratiques leur fera éprouver du ressentiment, et il n’aura pas l’expérience nécessaire pour tempérer ces attitudes. Il est également important de comprendre que certaines équipes n’utiliseront jamais ces outils; c'est à ce moment-là que vous obtenez un nouvel emploi.
DrewJordan

1
"De nombreuses entreprises sont bloquées de la sorte. Vous serez peut-être même surpris de constater que certains de vos collègues développeurs sont des autodidactes qui sont devenus des développeurs sans aucune formation officielle." Ceux-ci s'avèrent souvent être les développeurs les plus précieux en raison de leur expertise dans le domaine.
pmf

Oui, je suis totalement d'accord. Reformulé le premier paragraphe afin que cela semble moins condescendant. Je voulais juste m'assurer que OP savait qu'une bonne partie de la population active n'avait pas de formation officielle. Mauvais choix de mots de ma part.
DrewJordan

18

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 1 ); 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

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


1
Principalement en désaccord. Le seul moyen d'obtenir des changements dans une équipe est si quelqu'un est prêt à faire la recherche et à traîner le reste. Bien sûr, vous devez rester productif, mais si tout le monde garde la tête basse, vous vous retrouvez "un peu démodé, mais vous faites le travail". Et complètement épuisé par l'ennui.
clin d'oeil

@winkbrace Je ne prétends pas que vous ne devriez pas essayer de vous améliorer (en fait, je dis le contraire). Cependant, il peut s'avérer très difficile de faire avancer ces changements sans le soutien de la direction et sans les autoritas d'une certaine ancienneté, ce qui peut entraîner une certaine résistance. Ajoutez à cela que le PO n'est pas tout à fait un expert et peut avoir des problèmes avec la mise en œuvre réelle. Ce serait bien si le PO pouvait se porter volontaire auprès d'une équipe de recherche / prototypage pour introduire correctement les changements; mais sauf qu'il devrait être prudent dans le choix de la bonne approche pour les promouvoir et être patient.
SJuan76

@winkbrace pour l'ennui, cela dépend de votre personnalité et de ce que vous recherchez dans un emploi. Il est judicieux d'essayer de trouver un emploi qui vous convienne, plutôt que d'aller n'importe où et d'essayer de changer l'organisation selon vos goûts. Et généralement, les grandes entreprises (à l'exception des départements de R & D) ne sont pas l'endroit idéal pour ceux qui aiment tester une nouvelle technologie tous les quelques mois.
SJuan76

Il est un peu bousillé de dire "assurez-vous que vous travaillez réellement". Bien sûr, vous devriez faire le travail, mais vous devez aussi penser à long terme et chaque jour, vous devriez vous améliorer. Il m'a fallu 5 mois pour convaincre notre responsable de comprendre que les tests unitaires nous aident même lorsque nous essayons de coder "rapidement". Mais je devais prendre 10 minutes ici et là tous les quelques jours pour que cela se produise.
Rudolf Olah

@mouse Je ne faisais que signaler un risque qui m'est parfois arrivé lorsque je faisais des recherches. Certes, je ne vois pas ce risque dans la situation que vous décrivez, mais la forme sous laquelle le PO décrit ses recherches ("j'ai d'abord commencé avec ... puis je me suis rapidement déplacé ...") m'a fait ajouter cette prudence. Notez que je ne prétends pas que le PO ne fait pas correctement le travail qui lui est assigné (c’est quelque chose que je ne sais tout simplement pas, et c’est le travail de son patron), je le préviens simplement de s’assurer qu’il ne se laisse pas trop emporter .
SJuan76

12

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).


Je suis d'accord avec les rubriques de Travailler efficacement avec le code hérité, mais ce n'est pas très compact. Prenez-le comme une référence et jetez un coup d'œil sur les chapitres plutôt que de vous attendre à le lire comme un roman.
Lukas

10

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.


1
Le meilleur rapport qualité-prix est plus proche de quelques ASSERT aux bons endroits.
Peter Mortensen

@PeterMortensen C'est vrai, mais seulement si vous savez quels sont les bons endroits.
Emilio M Bumachar

Tu m'as battu à ça. Quelle que soit la direction prise par l'OP pour son équipe, y arriver avec Git sera beaucoup plus facile et plus productif que sans.
dotancohen

6

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 1
  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.


Je mettrais les tests de régression automatisés au plus haut niveau avec la construction et le déploiement automatisés. Cela présente également l’avantage de pouvoir travailler progressivement.
Sdenham

Les tests unitaires doivent être d’abord, commencez toujours par les exécuter manuellement localement (ou à chaque sortie), puis demandez au reste de l’équipe de participer aux tests de régression automatisés. Il existe vraiment des développeurs qui ont peur de faire des tests constamment pour une raison quelconque.
Rudolf Olah

5

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.


5

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.


4

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.


3
C'est exactement ce que j'ai fait. À une seule occasion (sur environ 5 tentatives à différents endroits), j'ai introduit avec succès de nouvelles "bonnes pratiques" ou apporté un changement significatif aux pratiques existantes. C’est à ce moment-là que l’équipe a repris ses activités et que nous avons démarré la plupart des projets à partir de rien. . Toutes les autres fois, les bonnes pratiques ont été introduites par le haut (chefs d’équipe) ou ont tout simplement échoué parce que personne n’y avait participé. Je crois que la capacité à forcer votre décision en tant que chef / patron est prise en compte.
scriptin


1

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 .)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.