Dans un monde où la plupart des dates de navires sont dictées par des besoins professionnels, les programmeurs sont généralement expédiés le code qui fonctionne. Souvent, la structure et l'efficacité du code expédié deviennent discutées lorsque vous connaissez les travaux de code. Sauf si la qualité de la production n'est spécifiée (API à un algorithme par exemple), pour le code exécutant dans quelques centaines de lignes, le code expédiable est équipé du code qui fonctionne.
Ma question est la suivante: Donnez-vous une fonctionnalité d'ETA pour une fonctionnalité jusqu'à ce que fonctionnaire fonctionne et que vous soyez effectué? Ou seriez-vous au travail aussi rapidement que possible et refacteur pour la qualité de la libération?
Mon inclination est envers ce dernier bien que cela sonne comme plus de travail. Lorsque le code qui fonctionne est mis à part pour une efficacité et des modèles algorithmiques, c'est une expérience joyeuse qui le mettent tous ensemble. En outre, il obtient tout ce que cet amour non fonctionnel - moins de bugs, performants, extensibles, sécurisés .. Je ne pense pas que je suis bon pour écrire le meilleur code pour la première fois. Donc, cette approche fonctionne bien pour moi.
J'aimerais savoir lequel est préféré et pourquoi? Je ne cherche pas une approche à l'échelle de l'industrie, juste des propositions individuelles afin que je puisse jauger la ressemblance de la pensée.
7 Réponses :
Pour moi, le refactoring devrait être fait après l'expédition, garantissant que toutes les fonctionnalités fonctionnent et l'ont laissé à la prochaine itération du bâtiment de code. Si vous commencez à manipuler le code avant l'expédition, vous risquez de faire de petites optimisations et d'être enfin laissé avec code non valide.
Si vous faites du développement axé sur le test. Souvent, vous écrivez la chose la plus simple qui fonctionne d'abord, puis le refacteur en tant que fonctionnalité supplémentaire est ajouté (aka rouge, vert, refacteur).
Il y a évidemment une grande zone grise dans cette question cependant. Si vous expédiez un désordre singuisible, vous devriez peut-être examiner comment vous allez écrire du code en premier lieu. Le refactoring devrait être effectué à quelque fin que ce soit pour rendre le code plus flexible pour permettre un nouveau type de produit par exemple. Ne faites pas que refroidir parce que vous sentez que vous devriez.
Ainsi, après votre connaissance des travaux de fonctionnalité par spécification, ne prenez-vous pas un pas en arrière et recherchez des gains d'efficacité et de modèles? Je ne pense pas que je voulais dire refacteur toujours. Si vous regardez avant de vous expédier ou non.
Comme d'autres l'ont dit, cela dépend des contraintes commerciales. Je ne dis pas de ne pas refroidir. Je dis ne pas refroidir si cela va affecter vos échelles de temps. Je marque souvent des choses comme Todo: refacteur au motif X ou TODO: Cela devrait être encapsulé dans sa propre classe, etc.
Je préfère refactoring avant reporter tout refactoring jusqu'à ce que la libération sonne terriblement comme si vous n'êtes probablement pas jamais allez-y (plus souvent, quelque chose de plus critique de l'entreprise). Mais même si vous le faites avant l'expédition, ce n'est pas comme si votre code est parfait et que vous manquez de choses à améliorer. Donc, ensuite aussi (tant que le code est maintenu dans une certaine mesure).
Pour moi, refactoring le code dans quelque chose de plus simple et plus propre est une partie continue et naturelle de tout travail de développement logiciel.
EDIT: Évidemment, vous devez envisager des contraintes professionnelles lors de la décision Combien et pendant combien de temps vous refacteur à un moment donné.
Edit 2: Quant à la question "Comment convaincre mon responsable de refactoring" (voir commentaires), voici quelques ressources qui pourraient aider:
Je suis entièrement d'accord avec la notion de refactoring continu. Le problème est, à quelle fréquence pouvez-vous convaincre votre responsable que vous devez modifier le code car vous devez refracteur.
IMO, un gestionnaire devrait faire confiance aux développeurs dans de telles questions (et envisager de refactoriser comme faisant partie intégrante du développement qui n'est pas vraiment son entreprise). Bien sûr, les développeurs devraient également être dignes de confiance et ne pas casser une branche de tronc / production avec des modifications non testées ou non prévisibles.
Si votre responsable est fortement en microgestion, envisagez de trouver un meilleur gestionnaire et votre lieu de travail. Ils existent. :-)
Oui, mais je veux supporter mon sol et prouver la différence qu'il fait. Cela fait un an et un changement se produit. Une partie du problème pourrait être un système hérité personne ne voulait toucher.
@batta: Il dépend bien sûr du type de gestionnaire que vous avez, mais les ressources que j'ai éditées dans la réponse pourraient aider à le convaincre. Au fait, si vous avez affaire à une grosse base de code hérité, cela pourrait réellement faciliter la preuve de prouver que le refactoring fait d'abord des correctifs / améliorations plus vite .
Et si le responsable ne l'achètera tout simplement pas, eh bien, ne dis pas . Alors que Fowler le dit: "Un directeur axé sur le calendrier veut que je fasse des choses le moyen le plus rapide possible; comment je le fais est mon entreprise. Le moyen le plus rapide est de refacteur; donc je refacteur."
J'essaie d'écrire le meilleur code initialement, mais j'ai toujours constaté qu'une fois que cela se passe au refactoring de la production est inévitable. Le refactoring habituellement après la libération du code a été la norme en raison de la rétroaction des utilisateurs.
Les commentaires des utilisateurs n'ont rien à voir avec refactoring - refactoring change simplement la mise en œuvre, pas la fonctionnalité
Dans notre équipe, nous considérons le code non refactored comme non "fait". En d'autres termes, le "code a été refacturé" fait partie de notre définition de FAIT , c'est l'un de nos critères de code expédiable.
Je préférerais refacteur avant l'expédition. Vous avez raison, mon premier code n'est souvent pas le meilleur design. Mais si vous avez un test de passage pour le code, il devrait y avoir peu de risque pour refracteur directement après.
Et le problème avec le faire plus tard est simplement "après la sortie si avant la sortie". Dans mon expérience, il n'y a aucune raison d'espérer qu'il est temps de nettoyer après la libération.
problème est, si vous avez tendance à seulement refracteur après l'expédition, vous ne le ferez jamais;)
J'ai tendance à voir "fait" avec un code bien facturé.
Il existe des exceptions de cette règle, s'il existe un refactoring à très grande échelle qui implique des efforts élevés. Pour répondre à une date limite, vous pourriez appuyer sur la prochaine itération du développement.
Le principal problème des problèmes de fixation après l'expédition (dans la branche principale / maître) est qu'il est difficile de fusionner les correctifs de la branche de sortie.