J'ai rejoint un projet Rails en tant qu'entrepreneur. Le projet allait depuis plus d'un an. Le code est écrit d'environ 10 développeurs différents et la plupart d'entre eux sont également des entrepreneurs. Ils ont un style de code différent. Certains d'entre eux sont venus de Java. Le code a des scores horribles avec Metric_fu. De nombreuses fonctions sont très longues (100 à 300 lignes). Certaines fonctions ont une quantité insensée de branches logiques, de boucles et de récursions. Chaque demande génère une tonne de requêtes SQL. La performance est très mauvaise. Beaucoup de code obsolète qui ne sont jamais utilisés mais n'ont jamais eu la chance d'être nettoyés. L'architecture principale est fausse ou ingénielle. La couverture de code n'est qu'environ 25%. Les vues et les partiels sont chaotiques et terribles à lire et à comprendre.
Le gestionnaire est en mesure d'essayer de satisfaire le PDG en ajoutant continuellement de nouvelles fonctionnalités, mais les fonctionnalités plus récentes sont de plus en plus difficiles à mettre en œuvre correctement sans casser autre chose. Il sait que le code est mauvais, mais ne veut pas mettre trop d'efforts pour les résoudre car le refactoring prendra trop de temps.
En tant qu'entrepreneur / développeur, qu'est-ce qui est un bon moyen d'effacer cette situation et de la commodité du gestionnaire ou du directeur général pour partitionner un peu de temps pour refactoring?
questions connexes
10 Réponses :
J'ai été dans une situation similaire. Il n'y a essentiellement que deux options:
Je viens de répondre dans une autre question, mon histoire d'horreur:
J'ai travaillé sur un projet où des astuces sales étaient le principal principe de conduite du développement. Aiguilles à dire, après un certain temps, ces astuces ont commencé à entrer en conflit. Dans une composante analytique, nous avons dû mettre en œuvre l'autre astuce très sale - pour cacher ces valeurs calculées qui, en raison des astuces contradictoires, n'étaient pas calculées correctement. Ensuite, les trucs de deuxième niveau ont commencé à entrer en conflit et nous avons dû créer des tours pour gérer ceux-ci. Depuis que, même la mention de ce composant me fait sentir l'horreur que je pourrais avoir à travailler dessus à nouveau.
C'est exactement la deuxième situation où le refactoring est le seul moyen de sortir.
En général, de nombreux gestionnaires sans antécédents techniques (en fait, ceux qui proviennent de mauvais programmeurs également) ni ne comprennent ni ne comprennent la valeur du code de qualité et de la bonne architecture. Vous ne pouvez pas les faire écouter tant que quelque chose interrompt leurs plans, comme un coup de fonctionnalités «non implémentées», augmenter et récolter des bogues, les demandes des clients qui ne peuvent pas être satisfaites et ainsi de suite. Ce n'est que la compréhension des problèmes de code peut venir pour la première fois. Habituellement, il est trop tard à ce moment-là.
Je prendrais une petite partie de l'application et le refoulé et l'a optimisé jusqu'à ce qu'elle brille (et je le ferais dans mon temps personnel afin de ne pas gêner mon manager). Ensuite, vous pourrez afficher votre responsable / PDG sur les bons résultats des optimisations de refactoring et SQL.
Non, vous ne devriez pas travailler gratuitement.
S'il y a besoin de refracteur, le code parlera de lui-même. Le refactoring mineur peut continuer pendant le développement. Si vous ne pouvez pas convaincre le responsable, vous devriez probablement repenser si c'est nécessaire du tout.
Cependant, s'il est absolument nécessaire, la construction de mesures d'activités de développement et les avantages doivent convaincre le gestionnaire.
dans mon experience limitée:
Il est impossible de convaincre un gestionnaire qu'il est nécessaire de mettre de côté du temps au refacteur. Vous pouvez lui faire prendre conscience et renforcer le point chaque fois que vous rencontrez une question en raison du mauvais code. Puis passe juste sur. Espérons que votre patron va le comprendre.
Il est assez courant d'entrer dans un projet en cours d'exécution et de penser que "c'est une indemnité totale". Donnez-lui un peu de temps. Vous pourriez commencer à voir un motif dans la folie.
Un d. 2 - Cela me passe à chaque fois, lorsque je rejointe un projet. +1
Aussi ad 2: Cela me passe presque chaque fois que je reprends travailler sur des parties de mon propre code, je n'ai pas touché un moment ;-)
À moins que vous ne fassiez quelque chose de drastique et de non recensuré comme un danger physique menaçant, c'est ce que vous allez obtenir. Vous devrez manipuler la situation pour refacturer les modules et les convaincre un peu de gestion de vous donner suffisamment de pouvoir pour faire vos gros changements.
environ # 2, le mauvais code est facile à écrire et bien sûr que la copie et la pâte évoluent dans un motif
Je pense que l'une des options serait de mettre en évidence le gestionnaire comment réorganiser la base du code permettra de gagner du temps (c'est-à-dire de l'argent) à long terme. Si le projet s'attend à courir à long terme, la modification vous permettra de sauvegarder clairement et d'autres développeurs à l'avenir.
Il est préférable d'utiliser un exemple d'une fonctionnalité que vous avez travaillé sur l'estimation du temps qu'il aurait été pris si vous aviez le code de nettoyage à travailler de la première place. Bonne chance!
Un délicat, j'ai récemment travaillé dans une telle entreprise ... ils poussaient toujours de nouvelles choses, ils savaient que c'était mauvais, mais peu importe la difficulté que je l'ai poussée - j'ai même eu des consultants externes pour vérifier mes conclusions - ils l'ont vu comme une perte de temps.
Finalement, ils ont vu la lumière ... Cela n'a pris que plusieurs accidents de serveur et à un moment donné, près d'un 8 jours d'absence de site Web pour les convaincre.
Même à cela, ils ont insisté "Doit" être le service d'hébergement.
La clé consiste à essayer de quantifier la durée de vie de leur site avant de se crousser et d'obtenir une vérification externe pour vous soutenir - «Ils font toujours confiance à des étrangers qui ne connaissent rien de votre application! Essayez également - si vous pouvez - donner un plan qui implique un remplacement progressif au pire, et un plan pendant combien de temps il faudrait pour faire de cette façon. En outre, un plan pour si 1 ou 2 corps travaillaient sur une réécriture complète HWO, il pourrait prendre - mais être réaliste aussi ou cela vous morda-t-il dans le bum! Si vous allez cet itinéraire (ce que nous avons fait), vous pouvez toujours avoir du travail sur le site existant tant que vous l'incorporez dans le nouveau.
Je suggérerais que vous mettriez concentré sur les choses qu'ils peuvent voir pour eux-mêmes, c'est-à-dire qu'ils remarqueront sûrement que la demande est lente dans certaines fonctionnalités, alors prenez-en une d'elles et dites quelque chose comme "Je peux réduire" Je peux réduire le Le temps d'attente ici, puis-je prendre du temps pour améliorer cette chose spécifique? " (Plus bien dit, mais vous avez eu le point: p).
considère également que 10 développeurs avant de ne pas avoir refactorisent la base de code, cela peut signifier qu'elle est une tâche de Monstruos, susceptible de rendre la situation pire, dans cette situation si quelque chose va mal après le refactoring, ce sera votre faute Si le programme ne fonctionne plus correctement. Juste une chose cependant, mais la peine d'être considérée.
Je suis dans la même position en ce moment, mais avec un accord avec le gestionnaire qui, lorsque la nouvelle fonctionnalité doit être mise en œuvre dans un module existant pour reporter le module également (si elle nécessite une ré-factorisation), nous nous débatons. Maintenant, avec le code créé il y a 4 à 5 ans et je découvre définitivement que la ré-adapter le code de quelqu'un d'autre n'est pas triviale ni amusante de faire, mais très utile pour la nouvelle réutilisation.
Tout le monde manque un point ici:
refactoring fait partie du cycle de vie du développement logiciel.
Ce n'est pas seulement un projet ROR ou tout projet spécifique, mais tout autre projet de développement logiciel.
Si vous pouvez convaincre votre pm Pourquoi il est important de refactoriser La base de code existante avant d'ajouter une nouvelle fonctionnalité, vous avez terminé. Vous devriez clairement indiquer à votre PM que tout autre ajout de nouvelle fonctionnalité sans aucun refactoring ne prendra plus de temps que nécessaire. Et même si la fonctionnalité est ajoutée, d'une manière ou d'une autre, les sessions de résolution des bugs prendront encore plus de temps car le code est très fluctué et stimulaire.
Je ne comprends vraiment pas pourquoi les gens oublient le principe d'optimiser plus tard. L'optimisation ultérieure comprend également le refacteur plus tard IMHO.
Une dernière chose, lors de la prise de décisions de conception, vous devez dire aux conséquences, bonne ou mauvaise, à votre PM très clairement.
Vous pouvez créer une branche différente (je suppose que vous utilisez GIT) pour refactoring et commencer à ajouter une nouvelle fonctionnalité dans une autre branche si votre PM insiste sur l'ajout de nouvelles fonctionnalités avec refactoring.
Le code de refactoring qui suce fait partie du codage, vous n'avez donc pas besoin d'obtenir l'approbation de personne Busting Up Les méthodes en méthodes plus petites et les méthodes de suppression non utilisées font partie de votre travail. Réduire les appels de DB, dans le code que vous appelez, est également nécessaire pour que votre code ne suce pas. Encore une fois, pas vraiment refactoring, juste codage normal.
Convaincre que votre responsable dépend d'autres facteurs, y compris (mais non limité) de leur volonté d'être convaincus et de votre capacité à convaincre.
Quoi qu'il en soit, qu'est-ce que le refactoring massif de ROR? Même si «l'architecture principale est tout simplement fausse», il peut généralement être redressé un peu à la fois. Assurez-vous de le casser en morceaux / utilisez des branches afin que vous ne brisez rien pendant votre préparation.
Si cela est impossible, alors vous revenez à la question sociale de la façon de convaincre votre responsable. C'est une question simple de comprendre ce que sont ses boutons et les pousser sans se faire tirer ni arrêté. Shaming, retenir de la nourriture, donner des prix, être un ami, une menace d'enlèvement anonyme où vous entrez et sauvez la journée ... c'est assez simple, vraiment: la créativité est la clé!