suggérant des changements importants / une réécriture en tant que stagiaire [fermé]

Le contexte:

• c'est un projet interne (que je ne pense pas que beaucoup de gens utilisent)
• c'est vieux
• nous le mettons à jour

Les problèmes:

1. il abuse du framework mvc (pas d'utilisation de modèles, logique métier dans les vues, etc.)
2. ce qu'on nous demande de faire est petit, mais en raison de la faible cohésion, nous avons deux options:
   1. continuer à bâcler les choses
   2. déplacer de gros morceaux de code ou réécrire la chose

Les solutions (je vois):

1. continuer à travailler avec elle, ignorer les meilleures pratiques en faveur d'une exécution rapide et ne pas introduire de nouveaux bogues en refactorisant / réécrivant
2. refactoriser / réécrire

Je suppose que ma question est vraiment: si je veux apporter de grands changements à ce projet, comment puis-je le proposer sans insulter personne? Ou serait-il préférable pour moi de simplement suivre le courant même si cela signifie parfois du ruban adhésif (métaphorique)?

OK, c'est parti.

Vous pensez que l'application est mal structurée et mal écrite.

Le client pense qu'il fait le travail.

Vous ne voulez le réécrire que pour améliorer sa "beauté intérieure".

Vous demandez donc au client de dépenser de l'argent pour que l'application fasse exactement ce qu'elle fait maintenant - seules les parties que l'utilisateur ne voit ou ne comprend pas seront en quelque sorte "meilleures".

La principale objection au code mal écrit et mal structuré est qu'il est difficile à comprendre.

Le code est difficile à comprendre et possède des fonctionnalités et des fonctionnalités qui ne peuvent être facilement implémentées que dans une application mal structurée. Donc, à moins que vous ne soyez très très bon dans ce domaine, la nouvelle application ne fera pas exactement ce que fait l'application actuelle, et, parce que vous n'avez pas complètement compris ce que faisait le code d'origine, elle le fera probablement mal.

Votre client a donc dépensé beaucoup d'argent pour obtenir une application nettement pire que l'application d'origine. Tu ne vas pas être populaire!

Heureusement, vos collèges les plus expérimentés sont prêts à vous faire plaisir (probablement parce qu'ils ont fait la même erreur lors de leur démarrage et ont peut-être même eu le malheur d'obtenir l'approbation de la direction pour un projet aussi malheureux).

Donc, mon conseil serait de garder l'ancienne base de code en cours d'exécution et de garder le silence. Le client veut juste un système qui fonctionne, il s'en fiche vraiment si vous pensez que le code est moche.

Proposez vos modifications. Soyez clair sur l'analyse de rentabilisation de chacun: pourquoi le changement proposé aidera-t-il le système dans son ensemble? Si ce n'est pas le cas, attendez-vous à repousser. Pourquoi dépenser de l'argent pour réparer quelque chose qui n'est pas cassé? Des raisons telles que rendre le système plus extensible et les séparations de préoccupations peuvent être valables (selon la personne à qui vous parlez), mais 99% du temps, dire simplement "ce n'est pas implémenté correctement" ne vous mènera nulle part. Assurez-vous que vous ajoutez de la valeur au projet et ne proposez pas seulement de faire fonctionner (même si cela nettoie le code).

Malheureusement, dans le monde professionnel, ce n'est pas parce que quelque chose a été mal mis en œuvre qu'il est cassé, et donc pas besoin de le réparer. De plus, en le corrigeant, vous pouvez introduire des problèmes inattendus qui pourraient avoir un impact sur d'autres domaines du projet.

En lisant votre question, je suis sceptique quant au fait que la réécriture de l'application en vaut la peine. Peut-être que vous n'avez pas pris la peine de présenter le dossier complet dans votre question. Mais quelle est la probabilité que les avantages de la réécriture en valent le coût s'il s'agit d'une ancienne application interne rarement utilisée? Le coût d'une réécriture sera probablement supérieur à la somme de toutes les mises à jour et correctifs qu'il aura jamais.

Si vous pensez que ce n'est pas vrai, vous devrez en faire plus de cas que vous ne l'avez fait ici.

En ce qui concerne l'amélioration de l'application, vous pourriez avoir une chance pour un peu de refactoring qui se produit naturellement au cours de vos mises à jour.

Tu es stagiaire. Vraisemblablement, vous êtes tout nouveau. Ils vous soupçonnent probablement d'idiot.

Donc, pendant que vous faites des suggestions, avancez légèrement . Soyez humble et sans prétention. Laissez vos idées circuler de manière conversationnelle pendant que vous permettez à d'autres membres de discuter également de leurs propres idées sur la base de code et des pressions auxquelles ils peuvent être soumis (il pourrait y avoir de très bonnes raisons pour lesquelles aucun effort n'a été fait pour nettoyer les choses).

Vous voulez gagner leur confiance. Pour ce faire, écrivez du bon code pour les tâches qui vous sont confiées. Écrivez-le proprement, utilisez les meilleures pratiques que vous aimeriez voir mises en œuvre, mais uniquement sur ce que vous êtes chargé de faire. Ce seront probablement de petites choses, des choses que le reste de l'équipe pense probablement insignifiantes. Faites bien ces choses. Illuminez le coin où vous vous trouvez, et au fur et à mesure que l'équipe examinera votre code favorablement, vos idées prendront également de l'ampleur.

Finalement , au fur et à mesure que vous démontrez vos compétences et vos connaissances, vous pourrez peut-être faire une ou deux suggestions.

Je ferais totalement cette suggestion, mais seulement à un collègue développeur . Je n'en parlerais pas à la direction, car j'imagine que la direction verrait cela comme une sorte de dépassement des limites.

Après avoir fait la suggestion à un développeur avec lequel vous travaillez, ils auront probablement de bonnes raisons pour expliquer pourquoi la base de code est la raison. Les raisons peuvent aller de "non, en fait, le code est correct, vous ne comprenez tout simplement pas MVC (et c'est pourquoi vous êtes stagiaire)" à "c'est une excellente idée, architectons la nouvelle application ensemble!"

Gardez à l'esprit que la réponse à la refactorisation de cette application sera très probablement non; Je ne voudrais jamais qu'un stagiaire prenne en charge la réécriture d'une application interne (que se passe-t-il lorsque votre stage est terminé et que la réécriture n'est qu'à moitié terminée?) De plus, il y a probablement plus de choses importantes sur lesquelles vous pourriez travailler que de fouiller une application interne .

Mais cela ne fait jamais de mal de demander à vos pairs, et si vous le faites, vous apprendrez quelque chose. Et ça, 7983879342, c'est ça le stage.

Quoi qu'il arrive, j'espère que vous emporterez le message suivant. Comme certaines des réponses ci-dessus l'ont souligné parfois, une réécriture de code, pour le meilleur des raisons techniques, est parfois impossible pour des raisons commerciales / financières. Trop de programmeurs vivent dans la solution technique et refusent de considérer que leur quête personnelle d'élégance technique / lisibilité / meilleure pratique doit être équilibrée par les besoins de l'entreprise pour faire avancer les choses. D'après mon expérience personnelle, le gars qui n'atteint pas cet équilibre (dans les deux sens) est souvent considéré comme une responsabilité au sein de l'équipe.

N'arrêtez pas de remettre en question les choses, même si vous obtenez des renversements, c'est notre façon d'apprendre et de grandir.

D'autres réponses ont beaucoup parlé de la politique de votre situation, et j'ai tendance à être d'accord. À moins que vous ne puissiez présenter une analyse de rentabilité convaincante, une réécriture n'est probablement pas prévue.

Cependant, cela ne signifie pas que vous devez oublier la règle du boy-scout :

Laissez toujours le terrain de camping plus propre que vous ne l'avez trouvé.

Si, pendant que vous implémentez quelque chose sur cette base de code, vous pouvez trouver un moyen de nettoyer un aspect de la conception ou de l'implémentation, alors c'est quelque chose que vous devriez considérer. Vous n'avez probablement pas besoin de réécrire toute l'application pour mieux utiliser le modèle MVC, et si vous implémentez une nouvelle logique métier pour une vue particulière, vous pouvez envisager de déplacer la logique de l'ancienne vue dans le modèle et y ajouter votre nouvelle logique.

Comme d'autres l'ont dit, demandez à un autre développeur (un familier de cette application) de faire une présentation rapide afin que vous puissiez comprendre le comment / le pourquoi de l'implémentation. Expliquez que si vous pouvez comprendre les aspects technologiques, mais que vous voulez pouvoir relier les points aux exigences de l'entreprise (les exigences de l'entreprise l'emportent sur toutes).

Une fois que vous avez ces informations, vous pouvez alors faire votre évaluation. Si vous pensez personnellement qu'il devrait être réécrit, mais ne pensez pas que les autres le verront comme une bonne utilisation du temps, considérez-le comme un projet personnel. Même si c'est une heure ici / là où vous avez un temps d'arrêt, faites l'implémentation "correctement". Une fois que vous avez terminé, présentez-le aux autres développeurs en tant que "hé, je sentais que cela pourrait utiliser un peu de nettoyage, alors j'ai fait quelques travaux secondaires pendant mon temps d'arrêt. Qu'en pensez-vous?" N'insistez pas sur le changement - offrez-le-leur simplement comme un "hé, vous aimez ça?" et partez de là.

La plupart des changements se produisent progressivement, en règle générale.

Quelques choses à garder à l'esprit;

• Quel est l'historique de l'application?
• Pourquoi est-ce moche aujourd'hui?
• Quel est l'avantage des changements architecturaux?

Une bonne stratégie consiste à travailler sur les petites choses et à poser une tonne de questions sur des choses (des questions que vous ne pouvez pas apprendre de Google ou de la source, ne perdez pas de temps). Une fois que vous vous sentez à l'aise avec la base de code et les développeurs, vous devriez avoir une bonne idée de la raison pour laquelle le code est tel qu'il est. Parfois, c'est juste: "Oui, nous avons dû pirater quelque chose ensemble et le pousser par la porte". Si vous pouvez proposer de légères modifications à de petites parties du système qui se produisent au cours de votre travail normal, cela obtiendra plus de traction que des réécritures radicales.

Il n'y a pas de mal à suggérer une réécriture si vous demandez gentiment et faites un cas logique (pas seulement un pressentiment ou c'est la meilleure façon de le faire). Il y a de fortes chances que la réécriture d'une application à faible utilisation soit abattue, et il y a de fortes chances que la personne qui a écrit le système à l'origine soit toujours là (et plus haut dans la hiérarchie que vous) et ne prenne pas gentiment les critiques.

Alors ne dites pas "Nous devons réécrire ce système horriblement conçu qui viole les principes de base de MVC", posez-le comme une question ouverte aux supérieurs appropriés (personnes directement au-dessus de vous). Quelque chose comme "Je me demande si la réécriture du système dans le modèle MVC pourrait économiser beaucoup de temps à long terme. Que pensez-vous? Je parie que nous pourrions réduire de moitié le temps de maintenance avec une réécriture majeure (disons 2 semaines) qui intègre le modèle MVC, TDD, etc. a été fait et qu'après deux mois de maintenance de routine, nous atteindrons l'équilibre ". La réponse peut être: non, nous ne pensons pas que cela soit nécessaire - je ne suis pas d'accord avec vos estimations de temps et la probabilité que le nouveau système soit un remplacement approprié. Ou la réponse pourrait être, allez-y, mais rappelez-vous si votre nouveau système ne fonctionne pas t fonctionner aussi bien / mieux que le nouveau système dans le laps de temps que vous avez proposé que les gens vous blâment. Et même si le système est peu utilisé; il peut ne pas être acceptable d'arrêter sa mise à jour avec des correctifs mineurs pendant la période de réécriture.