Comment conciliez-vous entre «faites-le bien» et «faites-le dès que possible» dans votre travail quotidien? [fermé]


180

Je me retrouve à réfléchir à cette question de temps en temps, encore et encore. Je veux faire les choses correctement: écrire un code propre, compréhensible et correct facile à gérer. Cependant, ce que je finis par faire, c’est écrire un correctif sur un correctif; juste parce qu'il n'y a pas de temps à perdre, les clients attendent, un bogue doit être corrigé du jour au lendemain, la société perd de l'argent à cause de ce problème, un responsable insiste fort, etc., etc.

Je sais parfaitement que, à long terme, je perds plus de temps sur ces correctifs, mais comme ce temps dure plusieurs mois de travail, personne ne s'en soucie. En outre, comme l'un de mes responsables le disait souvent: "nous ne savons pas s'il y aura un long terme si nous ne le réparons pas maintenant".

Je suis sûr que je ne suis pas le seul à être pris au piège de ces cycles de choix sans fin entre réel et idéal. Alors, comment vous, mes collègues programmeurs, gérez-vous cela?

MISE À JOUR: Merci à tous pour cette discussion intéressante. Il est regrettable que tant de personnes doivent choisir quotidiennement entre une quantité et une qualité de leur code. Pourtant, de manière surprenante, beaucoup de gens pensent qu’il est possible de gagner cette bataille, alors merci à tous pour ces encouragements.


12
Simple: faire droit et le faire rapidement
ren

158
@ren: Eh bien, je suppose que vous n'êtes pas un programmeur, vous êtes un manager :-)
Flot2011

44
Obligatoire. xkcd.com/844
MikeTheLiar

5
Faites-le dès que possible. Ensuite, si vous avez encore le temps, faites-le bien.
Laurent Couvidou

8
Comme le dit Oncle Bob: Le chemin lent est le chemin le plus rapide. Prenez le temps nécessaire pour écrire ces tests unitaires et écrivez bien votre code. Cela pourrait nécessiter plus de temps pour la mise en œuvre de la fonctionnalité, mais cela gagnerait du temps à long terme, car il serait plus facile pour d'autres de modifier et de corriger les bugs dans.
mardi

Réponses:


106

En fait, c'est une question très difficile car il n'y a pas de réponse absolument juste. Dans notre organisation, nous avons mis en place de meilleurs processus pour produire un meilleur code. Nous avons mis à jour nos normes de codage afin de refléter la manière dont nous écrivons en tant que groupe. Nous avons mis en place une boucle très forte de test / refactorisation / conception / code. Nous livrons continuellement ou du moins essayons de. À tout le moins, nous avons quelque chose à montrer aux parties prenantes toutes les deux semaines. Nous sentons que nous sommes des artisans du logiciel et le moral est bon. Mais malgré tous ces freins et contrepoids, nous avons le même problème que vous.

En fin de compte, nous livrons un produit à un client payant. Ce client a des besoins et des attentes, réalistes ou non. Souvent, l'équipe des ventes nous pose des problèmes simplement pour obtenir une commission. Parfois, le client a des attentes irréalistes ou une demande qui change, même si nous avons un contrat en vigueur. Les échéances arrivent. La prise de force et les jours perdus lors d'un sprint peuvent arriver. Toutes sortes de petites choses peuvent aboutir à une situation dans laquelle nous sommes forcés de faire comme si de rien n'était. «Fais-le bien» ou «Fais-le dès que possible». Presque toujours, nous sommes obligés de "le faire dès que possible".

En tant qu’artisans logiciels, développeurs, programmeurs, personnes qui codent pour un travail, c’est notre tendance naturelle à «faire les choses correctement». "Faites-le dès que possible" est ce qui se passe lorsque nous travaillons pour survivre, comme le font la plupart d'entre nous. La balance est dure.

Je commence toujours par contacter la direction (je suis directrice du développement logiciel et développeur actif dans ce groupe) pour défendre le calendrier, l’équipe et le travail en cours. Habituellement, à ce moment-là, on me dit que le client doit l'avoir maintenant et que cela doit fonctionner. Quand je sais qu'il n'y a pas de place pour la négociation ou pour donner, je retourne en arrière et travaille avec l'équipe pour voir quels coins peuvent être coupés. Je ne sacrifierai pas la qualité dans la fonctionnalité qui incite le client à l'obtenir dès que possible, mais quelque chose se passera et sera poussé à un autre sprint. C'est presque toujours OK.

Lorsque vous ne parvenez pas à livrer car il y a tant de bugs, que la qualité du code est mauvaise et qu'elle empire et que les délais sont de plus en plus courts, vous vous retrouvez dans une situation différente de celle que je décris. Dans ce cas, une mauvaise gestion actuelle ou passée, de mauvaises pratiques de développement qui ont conduit à une mauvaise qualité de code, ou d’autres facteurs peuvent vous mener à la mort.

Mon avis est de faire de votre mieux pour défendre le code et les bonnes pratiques afin que votre entreprise sorte de la tranchée. S'il n'y a pas un seul collègue prêt à écouter ou à défendre le groupe contre la direction, alors il serait peut-être temps de commencer à chercher un nouvel emploi.

En fin de compte, la vraie vie prime sur tous. Si vous travaillez pour une entreprise qui a besoin de vendre ce que vous développez, vous rencontrerez ce compromis quotidiennement. Ce n'est qu'en m'efforçant d'obtenir de bons principes de développement dès le début que j'ai réussi à rester en tête de la courbe de qualité du code.

Le va-et-vient entre développeurs et vendeurs me fait penser à une blague. "Quelle est la différence entre un vendeur de voitures d'occasion et un vendeur de logiciels? Au moins, le vendeur de voitures d'occasion sait qu'il ment." Gardez la tête haute et essayez de "faire ce qui est bien" au fur et à mesure.


14
"Souvent, l'équipe des ventes nous pose des problèmes simplement pour obtenir une commission" - À quel moment considéreriez-vous que les ventes devraient être tenues pour responsables de la vente de produits que l'entreprise ne peut pas livrer - en supposant qu'il y en ait une? Avez-vous des exemples où ils ont franchi la ligne de démarcation entre marketing agressif et survente?
Tom W

8
@TomW J'ai plusieurs exemples internes, des détails que je ne pouvais pas publier ici, mais lorsque cela se produit, cela se produit presque toujours lorsque nous avons besoin d'un compte de référence ou vers la fin du trimestre. Nous avons de très bons vendeurs et des moins bons. Récemment, il y a eu un grand changement dans les maisons de nettoyage une fois qu'il a été déterminé que le développement n'était pas le problème et que la structure de vente entière a changé pour le mieux. Les choses se passent merveilleusement bien depuis. J'aimerais être plus précis mais je ne peux pas.
Akira71

9
+1 - "Je ne sacrifierai pas la qualité dans la fonctionnalité qui motive les clients à l'obtenir dès que possible, mais quelque chose ira" ... c'était fantastique.
Joel B

59
@TomW - J'aime toujours signaler que l'architecte naval en chef du Titanic, qui avait mis en garde contre une réduction des coûts (Thomas Andrews), s'est évanoui, tandis que le responsable des ventes et du marketing, qui a préconisé une réduction des coûts et des mesures concrètes (Bruce Ismay) s'est échappé dans un canot de sauvetage.
Jfrankcarr

4
J'aurais bien aimé avoir le temps de taper une réponse comme celle-ci, mais j'ai un client qui parle à mon patron au téléphone. "Souvent, l'équipe des ventes nous crée des problèmes simplement pour obtenir une commission." Pareil ici ... mais ils reçoivent quand même ces bonus!
Kenzo

62

Une chose que j’ai réalisée au cours de ma carrière, c’est qu’il est toujours temps de bien faire les choses. Oui, votre manager pourrait pousser. Le client peut être énervé. Mais ils ne savent pas combien de temps cela prend. Si vous (votre équipe de développement) ne le faites pas, cela ne se fait pas; vous détenez tous les effets de levier.

Parce que vous savez ce qui va réellement pousser votre responsable à vous pousser, vous ou votre client, à vous en vouloir? Mauvaise qualité .


43
Bien qu'il y ait généralement du temps pour faire un bon travail, ce n'est généralement pas le cas pour le faire parfaitement. Il y a un monde de différence entre les deux.
Donal Fellows

2
@DonalFellows bien sûr. 'Right' signifie toujours "suivre les meilleures pratiques, en utilisant au mieux notre compréhension du problème à ce stade, au mieux de nos capacités". Les gens font des fautes. Les exigences changent. Les meilleures pratiques changent. Ne pas couper les coins ronds et refactoriser lorsque des choses se produisent.
Telastyn

3
@DonalFellows - "L'ennemi de l'excellence est la perfection". Un programme écrit de manière maintenable, qui répond aux exigences du client et le fait avec des performances acceptables, est un programme "fait". Rien de la tour d'ivoire à ce sujet.
KeithS

1
@DonalFellows Personne n'a utilisé le mot parfait, une solution parfaite est une mauvaise solution, Telastyn parle d'une bonne solution. La bonne solution est celle qui répond aux exigences et qui ne posera probablement pas de problèmes à l'avenir, tout en étant facile à gérer le cas échéant. Les absolus ont toujours tort.
Jimmy Hoffa

7
+1 - Pour Telastyn, tous les clients veulent que leur travail soit terminé maintenant. BEAUCOUP PLUS les clients veulent que leur matériel fonctionne plus que de le faire maintenant. Il semble que tous ceux qui sont en désaccord avec Telastyn prétendent qu'ils vont perdre un client si cela ne se fait pas rapidement. C'est de loin l'exception et non la règle. La règle, à savoir que la plupart des gens qui ne sont pas d’accord, c’est qu’ils ignorent qu’ils vont perdre beaucoup plus de clients en livrant des produits de mauvaise qualité. L’affirmation selon laquelle le client le souhaite maintenant est l’excuse habituelle de la part des personnes indifférentes à la qualité. Je suis donc sceptique quant au risque allégué.
Dunk

21

Cela revient à ce que j'ai commencé à considérer comme "le conflit éternel" (entre les entreprises et l'ingénierie). Je n'ai pas la solution car c'est un problème qui ne disparaît jamais, mais vous pouvez faire des choses pour aider à atténuer les effets.

  • Communiquer la valeur

Ce que les gens ne réalisent pas souvent, c’est qu’en tant qu’ingénieurs, nous ne faisons que supposer que le problème des "entreprises prospères" est toujours acquis. Nous voulons que notre code soit agréable, net et facile à gérer, afin que nous puissions ajouter de nouvelles fonctionnalités et peaufiner celles qui existent déjà rapidement et avec un minimum de clients effectuant l'assurance qualité pour nous en découvrant d'étranges problèmes marginaux qui auraient été contrecarrés par un meilleur code. Garder les clients et conserver un avantage concurrentiel avec des fonctionnalités et une finesse que personne d'autre ne peut produire assez rapidement sont des avantages commerciaux qu'un code de qualité contribue directement et explique en grande partie la raison pour laquelle nous souhaitons un code de meilleure qualité.

Alors épelez-le. "Nous voulons utiliser X dans notre base de code parce que, sinon, cela aurait un impact négatif sur votre activité en raison de Y" ou "... car cela améliorera notre capacité à rester compétitif en améliorant notre capacité à appliquer plus rapidement les nouvelles améliorations et fonctionnalités." . "

Et faites de votre mieux pour essayer d’obtenir des preuves tangibles du bon fonctionnement des améliorations. Si l'amélioration d'un sous-ensemble d'une application entraîne une amélioration / fonctionnalité plus rapide, vérifiez quel outil d'arriéré que vous utilisez peut-être pour en apporter la preuve et signalez-le lors des réunions appropriées.

  • Obtenez l'équipe sur la même fichue page

Les égos sont souvent un problème. Une chose dont les équipes d’ingénierie ont vraiment besoin, c’est d’établir l’utilité d’une approche convenue pour résoudre certains types de problèmes, et ce, pour que chacun puisse faire sa propre tasse de Kool Aid d’jour, car ils savent mieux. Il est normal de croire que les préférences de l'autre homme sont pires que les vôtres, mais valorisez la cohérence plutôt que d'avoir plus raison si son approche est réalisable et qu'il s'agit d'un argument que vous ne pouvez pas gagner. Le compromis dans un souci de cohérence est la clé. Lorsque les choses sont cohérentes, il est plus difficile de les mal faire, car la méthode établie et cohérente sera généralement la méthode la plus rapide.

  • Choisissez les bons outils

Il existe deux écoles de cadres / outils / bibliothèques / peu importe. "Définissez 99% de la somme pour moi, donc je dois savoir / faire très peu" contre "rester en dehors de mon chemin quand je ne veux pas de vous, mais aidez-moi à bricoler très rapidement et avec cohérence avec ce que je veux réellement à utiliser sur la carotte plutôt que le principe de bâton ". Favoriser le second. La flexibilité et le contrôle granulaire ne devraient jamais être sacrifiés à l'autel d'un redressement rapide, car, pour les entreprises, "nous ne pouvons pas le faire car nos propres outils ne nous laissent pas" n'est jamais une réponse acceptable et la question ne se posera jamais. ingénierie produit triviale / jetable. D'après mon expérience, les outils inflexibles sont presque toujours ouverts ou manipulés de manière peu élégante et créent un gâchis géant et incontrôlable. Plus souvent qu'autrement, les solutions flexibles / plus faciles à modifier sont aussi ou presque aussi rapides à court terme, peu importe. Rapide, flexible et maintenable sont possibles avec les bons outils.

  • FFS, si les ingénieurs ne décident pas, obtiennent au moins les commentaires des ingénieurs sur le choix des outils

J'ai l'impression qu'il s'agit d'une question du point de vue du développeur, mais je me suis trouvé dans beaucoup trop de situations où les décisions technologiques ont été prises sans aucune intervention de l'ingénieur. Qu'est-ce que c'est que ça? Oui, il faut bien que le dernier appel soit passé, mais si vous êtes un responsable non technique, obtenez des opinions nuancées, mais pas ce que certains vendeurs ou un site de démonstration disent de ses propres produits. Tout ce qui promet de vous faire économiser de l’argent parce que les gens n’ont pas besoin d’être aussi intelligents ou parce que cela protège les développeurs contre eux-mêmes est un mensonge sale et sale. Embauchez des talents en lesquels vous pouvez avoir confiance. Expliquez-leur ce que vous attendez d'une pile ou d'une autre solution technique et prenez leur contribution au sérieux avant de décider quel mouvement technologique adopter.

  • Mettre l'accent sur la conception plutôt que sur la mise en œuvre

Les outils sont destinés à la mise en œuvre et peuvent donc vous aider, mais la priorité absolue doit être l'architecture, quel que soit le jeu de jouets dont vous disposez pour construire cette architecture. À la fin de la journée, KISS et DRY et toutes les excellentes philosophies qui en découlent sont plus importantes que le fait de savoir s'il s'agit de .NET ou de Java ou de quelque chose qui est à la fois gratuit ET nul, c'est nul.

  • Connectez-vous à vos préoccupations

Lorsque le côté commercial insiste pour que vous le fassiez de la mauvaise façon, enregistrez cet e-mail, en particulier la partie où vous dites pourquoi cela vous coûterait. Lorsque toutes vos prévisions se réalisent et que de graves problèmes qui nuisent à votre entreprise en résultent, vous disposez de nombreux arguments pour prendre plus au sérieux les préoccupations des ingénieurs. Mais chronométrez les choses avec soin. Au milieu de l'enfer flamboyant, le moment est mal choisi pour un "Je te l'avais bien dit" après avoir suivi un code d'incendie. Eteignez le feu et apportez votre liste de problèmes précédemment ignorés à une réunion / conversation rétrospective, et essayez de garder le focus sur les problèmes d'ingénierie exprimés et ignorés et sur le raisonnement que vous avez compris, et non sur le nom des personnes. prendre la décision d'ignorer. Vous êtes un ingénieur. Restez sur les problèmes, pas les gens. " Nous avons exprimé notre inquiétude à propos de X parce que nous avions peur que cela pose des problèmes à Y. On nous a dit à Z et de remettre ça à plus tard. "


Très belle et détaillée réponse. Puis-je ajouter que j'ai déjà eu de la difficulté à choisir les bons outils , ce qui a entraîné une perte de temps considérable. Nous pourrions expédier le produit un mois plus tard, une fois la décision prise d'abandonner ce produit et d'utiliser quelque chose qui ne nous enfermerait pas.
Mhr

1
Je suis content de cette réponse, mais j’ai aussi trouvé mon premier emploi, où biz et dev ne sont pas constamment à la gorge et où l’impact est ravissant. Nous venons de faire avancer les choses. Pas toujours aussitôt que nous le souhaitons, mais nous tenons compte de l'avenir et cela se reflète à la fois dans le produit et dans notre capacité à le modifier en fonction des besoins. L'inévitable Big Ball of Mud est un mensonge, IMO.
Erik Reppen

19

Il n'y a qu'une seule solution. Réservez environ 10-20% du projet / temps de travail pour la refactorisation. S'il est difficile de convaincre la direction qu'il s'agit d'une tâche justifiable, donnez-lui le seul argument réel: sans refactorisation, le coût de la maintenance du code augmentera de manière exponentielle avec le temps. Il est bon d’avoir quelques métriques / articles / résultats de recherche pour étayer cette thèse lors de la réunion avec le responsable :)

Edit: il existe quelques bonnes ressources sur "le refactoring par rapport aux coûts croissants de la maintenance" mentionnées dans ce livre blanc: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf


12
Il existe une meilleure option: intégrer le refactoring à votre habitude de codage habituel. Tous les jours. Toutes les heures. Chaque fois que vous ajoutez ou modifiez une fonction. Donc, vous n'avez pas à réserver du temps supplémentaire pour cela, ni à "convaincre la direction".
Doc Brown

Ce n'est valable que si vous n'avez pas à traiter avec du code déjà écrit. Il est courant d'ajouter une nouvelle valeur à l'ancien code source / hérité / hérité. Mais lorsque vous examinez ce code, vous ne savez pas par où commencer et vous estimez qu'il est plus facile de l'écrire à nouveau que d'apprendre comment il fonctionne. Essayez de justifier ces estimations: deux jours pour ajouter une nouvelle valeur, six jours pour refactoriser l’ancien code afin de le rendre maintenable. C'est souvent pour entendre "ne pas refactoriser, ajoutez simplement la nouvelle valeur, nous verrons plus tard comment faire avec cet ancien code".
Andrzej Bobak

1
@ Flot2011 Ensuite, vous avez une seule solution. Laissez la refactorisation "au jour le jour" être votre tâche habituelle. Par exemple, chaque mardi, concentrez-vous uniquement sur l'amélioration de la qualité du code. Assurez-vous qu'il est respecté par la direction et assurez-vous qu'ils savent que la refactorisation n'est pas une perte de temps. Sans ces deux conditions réunies, tôt ou tard, ils abandonneront l'idée d'améliorer "quelque chose qui est déjà là et qui fonctionne".
Andrzej Bobak

1
@DocBrown Cela fonctionne lorsque vous parlez à la direction. Si vous parlez à un développeur senior et lui dites que vous allez ajouter deux champs au formulaire et que cela vous prendra 3 jours ... Eh bien bonne chance :).
Andrzej Bobak

2
Avoir à gonfler vos estimations pour obtenir du temps de maintenance est problématique pour un certain nombre de raisons. Parfois, une dette technique vaut la peine d’être contractée. Que se passe-t-il lorsque biz remarque soudainement que dans une situation d'urgence, il fallait 15 minutes pour frapper deux nouveaux champs alors que la dernière fois, cela prenait 8 jours. OMI, biz doit être conscient de la dette technologique et de son impact à long terme. Le problème doit être compris comme suit: soit vous payez maintenant, soit vous payez 5 fois plus tard, une fois que tout est dit.
Erik Reppen

14

Chaque fois que vous avez le temps de faire quelque chose de bien, utilisez-le - écrivez le meilleur code possible et améliorez-le régulièrement. Ne compliquez pas votre travail en faisant preuve de négligence et en contractant des dettes techniques là où il n’est pas nécessaire.

Les appels d'urgence pour réparer un bug grave ne sont pas des choses que vous pouvez contrôler par vous-même, quand ils se produisent, vous devez réagir aussitôt que possible, c'est la vie. Bien sûr, si vous avez l’impression que tout votre travail consiste en des appels d’urgence et que vous n’avez jamais assez de temps pour bien faire les choses, alors vous êtes sur le point d’être épuisé et vous devriez en parler à votre patron.

Si cela ne vous aide pas, il reste la "stratégie de Scotty" pour disposer de suffisamment de temps pour bien faire les choses: multipliez toutes vos estimations par un facteur de 4:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/


La stratégie de Scotty fonctionne. Ne laissez pas votre patron savoir que vous faites cela. Souvent, le temps que cela prend en réalité est double. C'est toujours mieux de finir tôt que tard.
Luke

11

Je considère que mon travail consiste à fournir le logiciel de la meilleure qualité possible dans les délais impartis pour le projet. Si je crains que le niveau de qualité ne soit bas, je ferai appel au propriétaire du projet. Je décris mes préoccupations et discute des risques potentiels liés au déploiement du logiciel dans cet état. Une des trois choses va se passer à ce stade:

  1. Le propriétaire du projet ne voudra pas accepter les risques et modifiera le calendrier pour nous permettre de consacrer plus de temps à la qualité du logiciel.

  2. Le porteur de projet ne voudra pas accepter les risques mais ne pourra pas revenir au calendrier. Si cela se produit, nous devons alors négocier les fonctionnalités à supprimer de la portée du projet afin de consacrer plus de temps à la qualité logicielle pour les principales parties de l’application.

  3. Le porteur de projet acceptera les risques et le logiciel de mauvaise qualité sortira comme prévu. Parfois, le risque commercial de ne rien déployer (ou de déployer tardivement) est beaucoup plus grand que le risque commercial de déployer un logiciel de qualité médiocre, et seul le propriétaire du projet peut prendre cette décision.

Les logiciels d’écriture ressemblent beaucoup à la peinture d’un portrait. Il est impossible de dire qu'un portrait est fait "correctement" ou "parfait". Parfait est l'ennemi du fait. Vous pourriez littéralement passer 1 mois à travailler sur une seule méthode et cela ne sera toujours pas considéré comme "parfait" par certains. Mon travail consiste à dresser un portrait qui satisfasse le client.


7

Cela ne fonctionnera pas dans tous les cas, mais j'ai eu un peu de chance en utilisant cette stratégie si le problème est un problème de production cassé qui doit être résolu de manière urgente. Estimez le temps nécessaire à la résolution rapide de la production et au temps nécessaire pour améliorer la qualité. Présentez les estimations à votre patron / client et obtenez l'heure approuvée pour les deux. Ensuite, vous faites le correctif rapide pour obtenir la production en cours et un correctif à long terme immédiatement après, lorsque la pression temporelle urgente est levée. Je trouve que si je le présente car j'ai besoin de ce temps pour faire le travail correctement, mais que je peux mettre en place un correctif temporaire jusqu'à ce que je puisse le faire, mes clients semblent aimer cette approche. Il remet en marche et répond au besoin à long terme.


7

L'équilibre optimal peut être de passer autant de temps supplémentaire à faire les choses correctement que de perdre à corriger les bugs que vous éliminez en les faisant bien. Évitez de plaquer la solution en plaqué or. Dans la plupart des cas, la solution proposée par Volkswagen est aussi valable que celle de Cadillac. Vous pouvez généralement effectuer une mise à niveau plus tard s'il est prouvé que vous avez besoin de la Cadillac.

La correction de code qui n'a pas suivi les meilleures pratiques prend souvent beaucoup plus de temps. Essayer de trouver l’origine de la valeur null lorsque l’appel ressemble à abcde () peut prendre beaucoup de temps.

L'application de DRY et la réutilisation du code existant sont généralement beaucoup plus rapides que le codage et le test d'une autre solution. Cela facilite également l'application des modifications lorsqu'elles se produisent. Il vous suffit de modifier et de tester un ensemble de codes, pas deux, trois ou vingt.

Viser un code de base solide. On peut perdre beaucoup de temps à essayer de le rendre parfait. Certaines pratiques recommandées conduisent à un code rapide, mais pas nécessairement le plus rapide possible. Au-delà de cela, essayer d'anticiper les goulots d'étranglement et d'optimiser le code au fur et à mesure de sa construction peut être une perte de temps. Pire encore, l'optimisation peut ralentir le code.

Dans la mesure du possible, fournissez la solution de travail minimale. J'ai vu des semaines de solutions de placage à l'or perdues. Soyez extrêmement prudent avec la portée.

J'ai passé quelque temps à travailler sur un projet qui aurait dû prendre six mois. Quand je suis arrivé, ça faisait un an et demi que ça marchait. Le responsable du projet avait posé au responsable de projet une question au début: "Voulez-vous que je le fasse correctement ou que je sois réactif?" En une semaine, une fonctionnalité a été implémentée les lundi, mercredi et vendredi; Mardi et jeudi, la fonctionnalité a été supprimée.

EDIT: Lorsque le code est terminé à un niveau satisfaisant, laissez-le. Ne retournez pas le réparer si vous trouvez une meilleure façon de le faire. Si vous devez vous faire une note. Si des modifications sont nécessaires, passez en revue votre idée et mettez-la en œuvre si elle a toujours du sens.

S'il existe des endroits où vous souhaitez implémenter des extensions pour les fonctionnalités à venir, ne les implémentez pas. Vous pouvez laisser un commentaire de repère pour vous rappeler où apporter les modifications.


À moins que DRY ne signifie une confusion, une illisibilité, mise en œuvre de schémas d’héritage massifs en cascade. Ne fais pas ça. Désolé, je le dis souvent, mais je déteste vraiment ça. En outre, +1 pour une solution de travail minimale dans la plupart des cas. Parfois, certaines caractéristiques architecturales prospectives peuvent être utiles à condition de ne pas en faire trop.
Erik Reppen

1
@ErikReppen Un code déroutant, illisible et une implémentation de schémas d'héritage en cascade massifs iraient à l'encontre de ma définition de DRY. Si vous devez comprendre le code chaque fois que vous l'utilisez, la conception échoue clairement sur DRY, même si la mise en œuvre est réussie.
BillThor

Cependant, cela peut impliquer beaucoup de réutilisation de code. La partie ennuyante est de grimper à un arbre de 18 classes ou prototypes pour trouver la définition réelle d’une méthode qui fait quelque chose d’ennuyeux, en particulier s’il existe des substitutions.
Erik Reppen

6

Faites-le fonctionner puis rendez-le parfait

Je peux tirer quelque chose pour cela - mais si le temps presse, alors votre priorité devrait être de le faire fonctionner, aussi simple que cela. Faites des commentaires approfondis sur les lacunes de votre code et notez ce que vous avez fait dans n'importe quel logiciel de gestion de projet / temps que vous utilisez.

Espérons que cela vous donnera plus de temps pour revenir sur ces problèmes et les rendre parfaits.

Évidemment, il n’ya pas de réponse absolument correcte à cette question, mais c’est une réponse que j’essaie de respecter. Cependant, il se peut que vous ne trouviez pas cela adapté à votre style de travail actuel. Ce qui m'amène à l'alternative ...

Il suffit de trouver une méthode qui fonctionne pour vous . et ensuite s'en tenir à cela. Chacun a sa propre façon de gérer les projets et il n’ya pas d’approche «taille unique». Trouvez une approche et personnalisez-la.


3
Quand la direction sait que ça marche. Ils le prennent comme fait et ne veulent pas que vous consacriez d'autres efforts à la refactorisation, etc.
Adronius

5

"Faire les choses correctement" signifie faire les bons compromis pour une situation donnée. Certains d'entre eux sont:

  1. Temps de développement et coût
  2. Facilité de lecture, de débogage et de mise à jour ultérieure du code (des noms de variables à l'architecture)
  3. Rigueur de la solution (cas extrêmes)
  4. Rapidité d'exécution

Évidemment, si un morceau de code doit être utilisé une fois et jeté, le n ° 2 peut être sacrifié pour n’importe lequel des autres. (Mais méfiez-vous: vous pouvez penser que vous allez le jeter, puis vous devez continuer à l'utiliser et à le conserver, à quel point il sera plus difficile de convaincre les gens de vous donner le temps d'améliorer quelque chose qui "fonctionne".)

Si vous et / ou votre équipe allez continuer à utiliser et à mettre à jour du code, prendre des raccourcis maintenant signifie simplement que vous vous ralentissez plus tard.

Si vous livrez actuellement du code buggy (faible sur # 4) et que vous prenez beaucoup de temps pour le faire (faible sur # 1), c'est parce que vous essayez de mettre à jour du code qui était faible sur # 2, eh bien, vous avez Vous avez un argument solide et pragmatique pour changer vos pratiques.


1
Je suggérerais: "Si PERSONNE ne conserve jamais un morceau de code ...": L'écriture de déchets, le dumping et l'exécution ne devraient pas être une option (pour toute personne ayant une conscience), mais cela arrive trop souvent; les entrepreneurs / consultants / gestionnaires s’assurant qu’ils sont à l’école juste avant que «cela» ne frappe le ventilateur.
Phill W.

@PhillW. - tout à fait d'accord. Edité en conséquence.
Nathan Long

4

Si c'est un bug, faites-le dès que possible, si c'est une nouvelle fonctionnalité, prenez votre temps.

Et si vous travaillez pour une entreprise qui ne respecte pas le travail de développeur, vous n’avez peut-être pas le choix que de le faire rapidement et de sacrifier la qualité.

J'ai travaillé pour un certain nombre d'entreprises qui ne feraient que passer d'un projet à l'autre et tout faire rapidement. En fin de compte, ils ont eu peu de succès dans tous les projets car la mise en œuvre (pas seulement la programmation) a été précipitée.

Les meilleures entreprises comprennent qu'un bon logiciel nécessite du temps et du travail manuel.


3

En cas d'urgence, créez la solution de correction. Créez un nouveau bogue dans le suivi des bogues en le mentionnant. Faites-le bien, chaque fois que vous en avez le temps.


5
Le problème est qu’il n’ya presque jamais de temps mort, c’est exactement le problème, et les bogues de ce type auront toujours la priorité la plus basse.
Flot2011

Je dirais que cela n’est vrai que si, par "urgence", vous entendez "quelque chose qui ne se produit pas plus d’une fois tous les six mois" et par "quand vous en avez le temps", vous voulez dire "dans une semaine ou à peu près". Sinon, votre question suivante devient "aide, le client a besoin de quelque chose dès que possible, mais le code que je dois changer est un désordre déroutant et il me faudra des semaines pour résoudre ce problème!"
Nathan Long

3

Je pense que je fais comme tout le monde qui est coincé dans cette industrie. Je le fais aussi vite que possible et si je dois laisser de côté certaines des choses intéressantes qui pourraient aider à prévenir les problèmes à l'avenir ou faciliter la résolution des problèmes à l'avenir, c'est ce que je fais. Ce n'est pas une situation optimale, mais lorsque vous vous retrouvez avec des échéances basées sur des estimations basées sur des estimations, basées sur de nombreuses variables inconnues, c'est quasiment tout ce que vous pouvez faire.


3

Voici un bon plan:

  1. Faites en sorte que votre plan "à la carte" prenne exactement le même temps que le "bricolage au plus vite".
  2. Optimisez votre temps pour le faire jusqu'à ce que votre environnement soit heureux; garder la qualité
  3. ???
  4. Succès

1

Je fais la plupart des choses de la manière habituelle, la première qui me vienne à l’esprit. C’est rapide, et j’aime penser que je suis un bon programmeur et que je fais la plupart des choses raisonnablement bien du premier coup.

De temps en temps (j'aimerais dire deux fois par jour, mais deux fois par semaine, c'est plus réaliste), surtout quand je trouve quelque chose d'extrêmement ennuyeux à faire de façon routinière, je pense "quelle serait une façon IMPRESSIONNANTE de le faire ? " et je passe plus de temps à trouver ou à inventer une meilleure façon de le faire.

Si je continue à le faire assez souvent, mon codage de routine continuera à s'améliorer, je pense.


1

Le logiciel est un truc bizarre et le processus de développement logiciel est plus étrange.

Contrairement à la plupart des choses dans la vie réelle, mais comme la plupart des choses à faire avec les ordinateurs

Plus rapide est plus fiable

Cela va à l’encontre de toutes les intuitions que votre vie jusqu’à présent vous a enseignées, les voitures très réglées tombent en panne plus souvent que les voitures standard, les maisons construites rapidement se défont plus rapidement, les devoirs faits à l’arrière de l’autobus scolaire n’ont pas de bonnes notes.

Mais les procédures méthodiques lentes ne produisent pas de meilleurs logiciels. Les gars qui passent des semaines à rédiger des documents d’exigences et des jours sur les diagrammes de classes avant d’écrire du code ne produisent pas de meilleurs logiciels. Le type qui répond aux exigences de base, clarifie quelques problèmes, dessine un diagramme de classes sur le tableau blanc et obtient le codage de son équipe produira presque toujours un logiciel plus fiable et de meilleure qualité, et le fera en quelques jours plutôt que plusieurs mois.


Je ne suis pas sûr d'être d'accord avec vous, mais c'est un point de vue intéressant, peu orthodoxe. +1 pour sortir des sentiers battus.
Flot2011

-1

Le travail ne vous convient pas.

Un code de qualité médiocre écrit "parce qu’il n’ya pas de temps à perdre, les clients attendent, un bogue doit être corrigé du jour au lendemain, la société perd de l’argent à cause de ce problème, un directeur insiste", est le symptôme d’une société mal gérée.

Si vous êtes prêt à être fier de votre travail et à écrire un code de haute qualité, la meilleure chose à faire est de trouver un employeur qui comprend cela et qui vous paiera pour le faire.

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.