Comment convaincre mon patron que la qualité est une bonne chose à avoir dans le code?
Mon patron est venu me voir aujourd'hui pour me demander si nous pouvions implémenter une certaine fonctionnalité en 1,5 jour. Je l'ai regardé et lui ai dit que 2 à 3 jours seraient plus réalistes. Il m'a alors demandé: "Et si on le faisait vite et sale?" Je lui ai demandé d'expliquer ce qu'il voulait dire par "rapide et sale".
Il se trouve, il veut que nous écrivions le code aussi rapidement que possible humainement (par exemple) en copiant des bits et des morceaux d'autres projets, en mettant tout le code dans le code derrière les pages WebForms, arrêtez de vous soucier de DRY et SOLID et en supposant que le code et les fonctionnalités n'auront jamais à être modifiés ou changés). Pire encore, il ne veut pas que nous le fassions pour cette seule fonctionnalité, mais pour tout le code que nous écrivons.
Nous pouvons faire plus de bénéfices lorsque nous faisons les choses rapidement et sale. Les clients ne veulent pas payer pour vous en tenant compte du fait que quelque chose pourrait changer à l'avenir. Les bénéfices pour nous résident dans la livraison de code aussi rapidement que possible. Tant que l'application fait ce qu'elle doit faire, la qualité du code n'a pas d'importance. Ils ne voient jamais le code.
J'ai essayé de le convaincre que c'était une mauvaise façon de penser en tant que directeur d'une société de logiciels, mais il ne voulait tout simplement pas écouter mes arguments:
- Motivation des développeurs: J'ai expliqué qu'il est difficile de garder les développeurs motivés lorsqu'ils sont constamment sous la pression de délais et d'un budget irréalistes pour écrire du code bâclé très rapidement.
- Lisibilité: Lorsqu'un projet est transmis à un autre développeur, un code plus propre et mieux structuré sera plus facile à lire et à comprendre.
- Maintenabilité: Il est plus facile, plus sûr et moins long d'adapter, d'étendre ou de modifier un code bien écrit.
- Testabilité: Il est généralement plus facile de tester et de trouver des bogues dans du code propre.
Mes collègues sont aussi déconcertés que moi par le point de vue de mon patron, mais nous n'arrivons pas à l'atteindre. Il continue de dire qu'en accélérant les choses, nous pouvons vendre plus de projets, leur demander un prix plus bas tout en réalisant un bénéfice plus important. Et au final, ces projets paient les salaires du développeur.
Que puis-je dire de plus pour lui faire voir qu'il a tort? Je veux lui acheter des exemplaires de Peopleware et The Mythical Man-Month, mais j'ai le sentiment qu'ils ne changeront pas d'avis non plus.
Beaucoup d'entre vous diront probablement quelque chose comme "Courez! Sortez de là maintenant !" ou "j'arrêterais!", mais ce n'est pas vraiment une option car les emplois de développement web .NET sont plutôt rares dans la région où j'habite ...
Mise à jour
Wow, je ne m'attendais pas à obtenir autant de réponses. Merci à tous pour vos contributions et vos opinions!
Comme le soulignent bon nombre de réponses et de commentaires, le type d'entreprise et le type de projets jouent un grand rôle dans ce sujet. J'ai expliqué certaines choses ici dans les commentaires sur certaines réponses, mais il est probablement préférable de l'ajouter ici également.
L'entreprise pour laquelle je travaille est plutôt petite. Nous avons 4 développeurs, 1 designer, 1 boss et 1 jack-of-all-non-technical-trades (la femme du boss). Les projets que nous réalisons peuvent être divisés en deux catégories:
- Petits sites Web construits avec notre propre CMS ou cadre de commerce électronique (65%)
- Applications Web de taille moyenne (35%)
Ainsi, alors que beaucoup de nos projets sont plutôt petits, ils sont construits sur le même système. Ce système a environ 4 ans et la base de code est en dessous de la moyenne pour le moins. Il est toujours redoutable d'ajouter de nouvelles fonctionnalités ou de modifier des fonctionnalités standard pour des clients spécifiques.
L'un des objectifs fixés par le patron est de commencer à nous concentrer sur le développement de produits. Cela signifie donc que nous développerons de plus grandes applications qui serviront de base à d'autres projets ou qui ressembleront à du SaaS.
Je suis tout à fait d'accord pour dire que faire les choses rapidement et en sale peut être la meilleure solution pour certains projets. Mais lorsque vous étendez un CMS existant qui sera utilisé par tous les sites que vous développerez au cours des prochaines années ou que vous construisez un produit SaaS à partir de zéro, il y a de meilleures approches, je pense.
Désolé de le dire mais,
Vous n'allez pas vouloir entendre cela, mais il n'a pas complètement tort .
Si vous travaillez en tant que consultant pour des entreprises externes et qu'elles sont disposées à accepter la chose la plus gênée que vous puissiez faire et à ne pas vous plaindre, et sont disposées à revenir encore et encore pour que vous fassiez plus de travail , votre patron a 100% raison de maximiser les profits de votre entreprise.
Ensuite, il y a YAGNI : si les projets sont des projets uniques qui ne vous coûteront rien à maintenir ou à réécrire et tout ce temps en maintenance et re -l'écriture est facturable, le faire c'est vrai la première fois, cela vous coûte encore plus d'argent. Ensuite, votre patron a de nouveau 100% raison.
Si vos clients ne se plaignent pas des coûts et du manque de qualité, alors la qualité n'est pas en cause pour satisfaire vos clients. On dirait que les clients sont satisfaits de la merde, donc leur vendre plus de merde n'est pas une décision commerciale difficile.
Tout ce que vous faites au-delà de ce dont le client est satisfait est un effort gaspillé sur toutes les parties: il ne l'appréciera pas. Votre patron a de nouveau raison à 100%.
N'oubliez pas que la qualité est dans l'œil du spectateur. S'il répond aux besoins des clients, ils ne se soucient pas du ruban adhésif et des cintres qui le font fonctionner.
Ce que vous appréciez a peu ou pas de valeur directe pour vos clients, car ils s'en moquent comment le logiciel fait ce qu'il fait, juste qu'il fait ce qu'il veut le plus souvent.
Chaque logiciel finit par dégénérer de l'entropie en Big Ball of Mud . Les applications GUI, en particulier celles pour Windows écrites dans une certaine saveur de l'entropie VB plus rapide en raison de la culture de l'ensemble d'outils.
Si cela vous fait vous sentir mieux, vous commencez juste un peu plus près de l'entropie maximale que les autres.
Personnellement, je ne créerais jamais de précédent avec des livrables de si faible qualité, mais là encore, je n'irais pas pour la course au niveau inférieur des clients de votre entreprise. essayant apparemment de répondre à.
Votre direction a décidé que ce sont les clients qu’ils veulent avoir et il n’est pas nécessaire d’essayer de vendre au client des logiciels plus chers et de meilleure qualité s’ils sont bien avec la façon dont les choses sont.
Vous n'allez pas faire changer la gestion, seuls vos clients le feront. Vous pouvez obtenir de meilleurs clients ou obtenir un meilleur emploi.
Cela ressemble à mon ancien travail
Cela arrivait tout le temps à mon ancien travail. Je suis d'accord que les ventes sont le moteur de tout. Le responsable de la boutique (Skill Set: 80% Sales 20% Graphics) sous-vendait constamment les fonctionnalités souhaitées par les clients. Un travail de 20 heures serait vendu à un prix de 10 heures parce que le client n'était pas disposé à payer plus ou (j'ai tendance à penser) que le directeur des ventes n'a pas suffisamment insisté The Value le client était obtenir.
Le directeur des ventes montrait souvent des fonctionnalités et des widgets potentiels que nous avions créés pour différents clients. Et bien sûr, il sous-vendrait cette fonctionnalité à la nouvelle perspective parce que nous n'avions pas vraiment à recoder la chose ... tout ce que nous avions à faire était de copier-coller le code d'un autre site Web et le placer dans ce site. Nous l'avions déjà construit.
Après plusieurs sessions d'avant en arrière de "Pourquoi ne pouvez-vous pas faire cela plus rapidement ... vous l'avez déjà fait pour le client x". et "Cela n'a pris que 10 heures pour le client y, comment se fait-il que cela prenne 16 heures pour le client z".
Nous avons demandé au vendeur quel était l'objectif? Il a dit de vendre autant de ces widgets que possible pour un prix aussi bon marché que possible.
Nous lui avons dit que nous sommes une boutique de qualité et que nous faisons un travail de qualité. Nous lui avons dit qu'en abaissant le prix, il diluait en fait la valeur de notre travail et, ce faisant, lorsque le client nous revient pour de nouvelles fonctionnalités qui n'avaient pas été développées auparavant (ce qui signifie que l'option de copier-coller à partir du site x n'était pas pas là), ils repousseraient les prix et le directeur des ventes se plierait sous la pression.
Nous avons décidé de tarifer nos widgets à un prix supérieur tel quel. Toute modification serait en sus. Nous avons convaincu la direction que si nous avions le temps de développer ces widgets afin de pouvoir les extraire de notre "Code Library" au lieu d'autres sites Web, nous pourrions les créer de manière plus générique afin de pouvoir littéralement plop les dans un site existant en 2 heures et être payé pour 10 heures.
Il a commencé à les vendre "tels quels" avec des frais supplémentaires pour les modifications et nous avons pu les déposer et les faire travailler en deux heures. Nous avons également commencé à ajouter ces widgets à "Notre site Web" et à cesser d'utiliser les sites Web d'autres clients comme outils de vente. Nous utiliserions uniquement les sites Web d'autres clients pour montrer comment le widget pourrait être personnalisé " pour une somme modique " pour agir comme ceci ou ça.
Afin de prouver notre concept, nous (les développeurs) sommes restés tard après le travail quelques nuits pour construire un widget générique le mettre dans notre bibliothèque de code. La vie s'est améliorée. Les discussions ont changé, pourquoi cela prend-il autant de temps à ... " Hé, pouvez-vous revendre ce widget que le client x veut? Si oui, quelles fonctionnalités voulez-vous que nous ajoutions au modèle de base pour vous aider à le vendre. "
J'ai vu des entreprises faire cela. Ils se retrouvent avec des clients en colère. Les clients ont l'habitude de revenir et de demander de nouvelles fonctionnalités dès que l'application commence à gagner de l'argent pour eux ou est intégrée dans leur flux d'affaires. Vous devrez bientôt dire à ces clients que vous ne pouvez pas ajouter de nouvelles fonctionnalités au désordre que vous avez créé, car vous ne pouvez plus gérer la base de code. Ou cela vous prendra beaucoup plus de temps.
Les clients (même en situation de concurrence les uns avec les autres) ont tendance à parler. Soit directement, par des salariés changeant d'entreprise, soit par des rencontres aléatoires lors d'événements typiques de leur métier (conférences, expositions). Vous aurez très vite du mal à acquérir de nouveaux clients si votre entreprise a mauvaise réputation.
De plus: un codage de faible qualité ne fonctionne (le cas échéant) que si vous limitez votre entreprise à de très petits projets. Tout ce qui est plus grand ou plus complexe perdra du temps (et cela pour de l'argent) instantanément, même pendant le premier cycle en direct du projet, simplement en passant plus de temps à déboguer que prévu.
Enseignez-lui la dette technique
Ce que vous devez faire, c'est lui faire prendre conscience des conséquences des choix qu'il fait. Rapide et sale peut parfois être correct car vous pouvez faire avancer les choses plus rapidement, mais cela a des conséquences à long terme.
Si par exemple le projet n'a jamais été conçu pour avoir une grande base de code, rapide et sale pourrait être la manière parfaitement correcte de gérer ce projet.
Ward Cunningham a proposé la brillante métaphore "Technical Debt". Tout comme vous pourriez contracter un prêt à la banque pour obtenir quelque chose plus rapidement (au lieu d'épargner), vous devez payer plus à long terme car vous devez payer des intérêts. Cela peut être une bonne chose, si la valeur d'obtenir votre "chose" plus rapidement l'emporte sur le coût de l'intérêt.
Les solutions rapides et sales sont comme un prêt en banque. Et encore une fois, si la valeur d'obtenir une fonctionnalité plus tôt l'emporte sur le coût du nettoyage par la suite, alors prendre le prêt pourrait être la bonne approche.
Mais si vous contractez de plus en plus de prêts à la banque, vous payez finalement tous vos revenus en intérêts. Il en va de même pour la dette technique. Si vous avez apporté trop de solutions rapides et sales, votre dette technique sera si élevée que vos progrès seront stoppés.
J'ai vu cela se produire. Dans un projet sur lequel j'ai travaillé, la dette technique était si grave que nous n'avions sérieusement aucun progrès pendant 3 mois, essayant simplement de corriger des bogues, ce qui introduisait de nouveaux bogues, etc.
Si vous pouvez lui faire bien comprendre le concept de dette technique, alors il devrait être capable de prendre les bonnes décisions (bonne chance, c'est un coriace). Notez que la bonne solution signifie parfois aussi rapide et sale.
Une dernière chose que vous pourriez signaler est que les développeurs sont plus productifs s'ils sont très motivés;)
Le coût de maintenance est souvent beaucoup plus élevé, et souvent la majorité du coût, d'un logiciel.
Si vous programmez rapidement et sale, la maintenance sera plus difficile à réaliser et le coût aussi.
Si vous construisez tous vos logiciels rapidement et de façon sale, cela va être merdique et bogué et vos clients vont le remarquer. À long terme, si vos produits continuent d'être merdiques et poussiéreux, vous les perdrez. Les clients voudront payer un peu plus votre concurrent pour un produit de bonne qualité que de subir vos bugs.
Votre patron ne comprend-il pas cela?
Dans tous les cas, sauf les plus rares, vous ne pouvez pas convaincre quelqu'un qui est incroyablement myope que plus c'est presque toujours mieux dans notre profession. Désolé, mais c'est la vérité; les personnes à courte vue vont tout sacrifier sur la route pour en récolter les bénéfices maintenant, et souffrent presque toujours à la fin.
Parfois, la bonne solution est pour changer de position en un endroit où les gens sont assez intelligents pour comprendre les avantages de la qualité et ne sont pas myopes.
Remarque: cette réponse prend une stratégie de communication d'entreprise qui essaie d'utiliser la raison pour s'assurer que chacun obtient ce qu'il veut. Si le problème est simplement que faire de l'ingénierie de mauvaise qualité sape votre volonté de vivre ou que votre patron est un conducteur d'esclaves et qu'il ne semble pas y avoir de fin en vue, il peut en fait être temps de changer de décor.
Vous ne parlez pas la langue de votre patron. Une partie de votre travail consiste à donner des informations à votre patron afin qu'il puisse prendre des décisions, et vous devez changer votre stratégie de communication d'informations. Vous parlez en ingénierie, et ce dont il a besoin d'entendre, c'est risque, coût, investissement et rendement. Vous devez également être un peu défensif et assurez-vous qu'il existe un bon dossier de ce que vous lui informez.
Il y a deux parties à cela:
Le premier est la communication de votre estimation et de l'idée qu'il ne s'agit pas d'un objectif ou d'un plan. Je pourrais écrire des volumes ici, mais ce serait essentiellement une copie de tout dans " Software Estimation: Demystifying the Black Art " de McConnell, un livre pour lequel vous devriez courir, pas marcher, jusqu'à votre librairie. Soyez prudent de faire la distinction entre les estimations, les objectifs et les engagements, et assurez-vous de faire une véritable estimation avant de vous engager à quoi que ce soit!
La seconde est la communication des risques réels qui pourraient intéresser votre patron. En termes simples, cela signifie que vous devez dire à votre patron que la mise en œuvre qui pourrait être achevée en 1,5 jour répondra aux exigences de base mais augmente considérablement le risque que les modifications et fonctionnalités futures nécessitent beaucoup plus de temps qu'il n'y paraît. S'il demande pourquoi, utilisez l'analogie construction de maison: si votre logiciel est une maison, chaque changement est un nouveau meuble et chaque fonctionnalité est un nouveau sol. Si vous n'avez pas une base solide et que vous remodelez/rénovez un peu chaque fois que vous faites quelque chose, vous finirez par être dans la situation où un remodelage majeur sera nécessaire juste pour supporter le poids et la taille d'un nouveau traitement de fenêtre, et toute la maison devra être reconstruite s'ils veulent supporter quatre nouveaux étages et une terrasse.
Cela remet la balle dans le camp de votre patron - vous lui avez donné des informations et il doit décider. Il devra se demander s'il y aura ou non des changements futurs et s'il veut ou non ignorer cette possibilité. À partir de là, s'il est décidé que la voie à suivre est rapide et de faible qualité, assurez-vous que votre chausse-pied rappelle (avec tact) cette décision dans pratiquement tous les éléments de communication et de documentation que vous pouvez. Envoyez un e-mail de suivi qui confirme la décision et les risques que vous avez communiqués, en vous engageant par écrit. Prenez note de la stratégie d'ingénierie et des risques de votre spécification.
Lorsque le jour vient où le client veut une piscine au 50e étage et que vous voyez que les 20 derniers étages ont été construits avec des bâtons et du sable, assurez-vous que la grosse estimation de graisse que vous produisez est techniquement justifiable et préparez-vous à déployez la trace papier des factures à bas prix pour illustrer pourquoi cela va coûter si cher.
Si vous avez vraiment fait tous ces arguments et qu'il encore les repousse, alors il est de votre devoir en tant que professionnel de porter cette préoccupation à un niveau supérieur. Oui, cela signifie aller au-dessus de sa tête. La raison en est simplement que votre patron est un danger pour l'entreprise.
D'après mon expérience avec ces gars, ils finiront par conduire votre organisation à l'échec ou au moins à la médiocrité. Votre produit sera nul et vos clients vous quitteront.
Pour mémoire: je suppose que le cœur de métier de l'organisation est le développement de logiciels et que le produit est important et pas quelque chose à jeter.
W. Edwards Deming est surtout connu pour son travail dans la reconstruction de la fabrication japonaise après la Seconde Guerre mondiale. Souvent négligé, le fait que son travail concerne davantage la gestion que la fabrication. En fait, une section importante de son livre Out of the Crisis porte sur l'amélioration de la qualité dans les organisations de services. Ses exemples d'organisations de services comprennent les logiciels, les services bancaires, les assurances et les églises.
Deming soutient - avec de nombreuses preuves du monde réel à l'appui - qu'une augmentation de la qualité augmente le profit.
Vous pouvez analyser le développement de logiciels en tant que processus métier. Comme la fabrication, elle produit des produits intentionnels, non intentionnels, directs et indirects.
Les produits directs intentionnels de fabrication et de programmation comprennent les robinets et le code source. Les produits indirects intentionnels comprennent la dette et les revenus.
Les produits non intentionnels des processus de fabrication comprennent les robinets présentant des défauts de fabrication, des incendies accidentels, des blessures, un roulement élevé du personnel et le vol d'employés. Les produits non intentionnels des processus de programmation incluent les bogues, les difficultés de maintenance, les difficultés d'évolutivité, les problèmes de sécurité, le roulement élevé du personnel et le vol des employés.
Chacun de ces "produits" est sujet à variation, à une analyse statistique et à l'amélioration des processus.
Dans votre cas, vous devrez probablement énumérer et quantifier les produits non intentionnels de vos processus de développement logiciel et de gestion de projet.
Deming est l'une des principales raisons pour lesquelles le Japon est une puissance mondiale dans le secteur manufacturier. Le prix Deming porte son nom.
Oui, nous pouvons pirater cela ensemble aujourd'hui.
Si nous le faisons de cette façon, il y aura plus de bugs que la moyenne et ralentira sérieusement le développement futur. Pirater cela ensemble est vraiment quelque chose que nous pouvons faire une ou deux fois. Considérez-le comme un gratte-ciel, nous pourrions déjà avoir une fondation Nice, et nous avons 10 étages qui sont vraiment sympas aussi, si vous voulez, nous pouvons rapidement claquer des tentes et des boîtes jusqu'au 11e étage, peut-être même construire un 12e étage hors des tentes et des boîtes, mais vous êtes foutu pour aller au-delà. Nous devons déplacer tout le monde hors de ces deux étages, les installer, tout recycler et tout reconstruire juste pour obtenir le 13e étage.
Si nous essayons de construire un 13e étage à partir de boîtes et de tentes, nous pourrions effondrer trois étages à tout moment aléatoire, et cela pourrait nous prendre des mois juste pour obtenir les blocs jenga et le duplo super-collé aux bons endroits.
Est-ce que cela vous convient?
Votre patron pourrait avoir raison. Je peux penser à des scénarios où ce type de codage est suffisant. Disons que vous écrivez des scripts jetables pour une sorte d'analyse de données ou des sites Web dinky où vous pouvez à peu près regarder quelques pages et avoir une idée de ce qui se passe. Ces types de choses n'ont pas besoin d'être sur-conçus, car il est peu probable qu'ils soient maintenus. Si c'est nous que veulent les clients, c'est ce que les clients vont obtenir.
Maintenant, il se pourrait aussi que votre patron se trompe et que les clients n'apprécient pas les produits qui fonctionnent mal. C'est le plus souvent le cas.
Il pourrait également être une option pour trouver une sorte de juste milieu. L'essentiel est que si quelque chose ne fonctionne pas, il doit changer. De toute évidence, votre patron n'est pas satisfait de la façon dont le processus de développement affecte l'entreprise en l'état. Le délai de mise sur le marché est tout aussi important que la qualité du produit. Ce que vous devez faire est de démontrer que votre équipe peut produire un produit de qualité dans un délai qui ne détruira pas la commercialisation du produit. Si les principes d'ingénierie sont utilisés correctement, cela ne devrait pas détruire la productivité d'une équipe. Si quoi que ce soit, l'utilisation de bonnes pratiques devrait accélérer le processus de développement ET augmenter la qualité.
Je ne pense pas que ce soit possible. Différentes entreprises ont des cultures différentes et si la culture de votre entreprise actuelle (rapide et sale) ne vous convient pas, je pense que vous devriez continuer. Certaines autres entreprises ont un point de vue opposé et là, vous travaillerez avec des gens qui pensent la même chose que vous.
Je ne veux pas vraiment entrer dans la discussion quel type de culture est le meilleur (voir les autres articles si vous êtes intéressé), tout ce que je dis, c'est que cela sera bénéfique pour votre santé mentale si vous travaillez dans une entreprise avec le même approche.
J'ai parcouru toutes les questions et je vois que personne n'est entré dans la perspective de la sécurité ...
Oui, d'autres ont mentionné le temps de débogage, mais dans ce cas, le débogage ne se fait qu'au niveau de "hé ça marche enfin"
Dans mes projets (petits et/ou grands) je garde un haut niveau d'attention aux exploits et aux failles de sécurité possibles.
En tenir compte et les tester prend beaucoup de temps, mais au moins de cette façon, ils ne m'accuseront pas de ne pas faire de mon mieux quand quelque chose de mauvais se produit.
Je parie que lorsque vous allez vite et sale, oubliez de désinfecter certaines variables, oubliez de faire quelques vérifications dans les fonctions et faites ainsi de votre projet un bon point de départ pour les pirates.
Lorsque mon patron me demande pourquoi quelque chose m'a pris autant de temps, je lui montre toutes les vérifications de sécurité et de fonction que j'ai intégrées pour empêcher des choses comme l'injection, l'inclusion, les boucles infinies et même les mesures de sécurité pour quand quelque chose est piraté, cela fait un minimum de dégâts
Cela peut sembler évident, mais je pense que vous devez trouver une voie médiane. Ne négligez pas l'attitude de votre patron. Votre opinion là-dessus lui est probablement aussi étrangère que la sienne.
L'un ou l'autre extrême n'est évidemment bon pour personne, alors essayez de négocier un terrain d'entente.
Jetez-lui des maths. Malheureusement, je n'ai pas les livres sous la main pour fournir des citations (j'espère que quelqu'un peut m'aider), mais l'un ou les deux de The Pragmatic Programmer et Code Complete 2 ont une section faisant référence à des études qui montrent l'impact sur les coûts de faire les choses rapidement 'n' dirty way, contre prendre le temps de le réparer plus tard. D'autres affiches ont fourni de nombreux arguments, mais selon le comportement de votre patron, il pourrait mieux répondre au soutien des études existantes. Il peut penser que vous vous contentez de vous débarrasser de votre temps et d'alléger votre propre charge de travail. Lui montrer que c'est un fait accepté par l'industrie, par opposition à votre simple opinion, pourrait être le ticket.
Je suis en quelque sorte dans une situation similaire à la vôtre. Je travaille pour une entreprise de services, j'écris donc des applications personnalisées pour différents clients. Les personnes chargées de fournir l'application (comme les chefs de projet, les chefs de projet, etc.) ne se soucient vraiment pas de la qualité du code (bien qu'ils le disent), tout ce qui leur importe, c'est de livrer les choses à temps afin de maximiser le profit. On me demande constamment d'écrire des fonctionnalités en peu de temps.
Une technique que j'ai utilisée pour maintenir la qualité du code tout en respectant la date limite est la refactorisation continue. Si on me demande d'écrire la fonctionnalité A en 1 jour, ce qui prendra en fait de 3 à 5 jours pour écrire avec une haute qualité, je ferai juste la manière rapide et sale et je livrerai. Mais tout en faisant de la manière rapide et sale, je garde des notes sur le domaine qui peut/devrait être amélioré. Plus tard dans le cycle de développement, je trouverai juste ici et là des fragments de temps pour refactoriser mon code dans la fonction A.
Au début, ce fut une expérience douloureuse de refactoriser mon code rapide et sale; Je me souviens de quelques cas où j'ai réécrit presque complètement une fonctionnalité pendant la refactorisation. Mais comme je refactorise de plus en plus, mon code rapide et sale a commencé à devenir moins sale. J'ai commencé à développer un meilleur sens naturel de la conception modulaire, de sorte que les codes que j'écris deviennent de plus en plus modulaires même si je suis en mode rapide et sale.
Il n'est pas faux de penser que la qualité du code n'a pas d'importance, car pour beaucoup de gens, cela n'a pas d'importance. Aimez-vous vraiment la qualité de conception du circuit à l'intérieur de votre téléviseur SONY tant qu'il affiche une belle image HD et fonctionne correctement pendant 5 à 10 ans?
En tant que développeur, vous devez vraiment vous soucier de la qualité du code, car vous en connaissez les avantages. Votre patron ne changera probablement pas d'avis sur la qualité du code, sauf s'il connaît des crises où la qualité du code lui fait gagner du temps ou lorsqu'il voit personnellement la corrélation entre le profit et la qualité du code.
Ce n'est pas parce que votre patron ne connaît pas la qualité du code que vous devez compromettre la qualité du code (cependant, c'est toujours une bonne idée de garder le canal de communication ouvert avec votre patron sur la qualité du code). Efforcez-vous de trouver le point d'équilibre entre la qualité du code et le calendrier de développement. Vous ne pouvez pas écrire du code de bonne qualité pour le calendrier actuel ne signifie pas que vous ne pouvez pas améliorer la qualité dans les futurs calendriers, n'est-ce pas?
Faire des choses rapides et sales peut vous ralentir avant même le déjeuner. Très souvent, cela commencera à faire mal avant même que vous ne soyez suffisamment complet pour essayer de le faire accepter par un client.
Vous pouvez peut-être essayer la métaphore de la dette technique, le fardeau des paiements d'intérêts sera plus important que le revenu après un certain point.
Piloter vers une réécriture est aussi l'occasion pour vos clients d'essayer une société de développement différente (si nous partons de zéro, ils le pourraient aussi).
Si vous n'avez pas d'employeurs alternatifs dans votre région, il pourrait y avoir plus de nombreux clients à porter également. Donc, fondamentalement, votre patron peut continuer à faire ce qu'il fait, pas de concurrence qui fait mieux. Peut-être démarrer votre propre entreprise? ;-)
Alternativement, vous pouvez simplement lui dire que vous faites toujours les choses "rapidement et sale" et faites simplement votre propre chose.
La meilleure réponse possible serait de l'approche Agile:
libérer tôt, libérer souvent
Release early est bon pour votre entreprise car vous commencez à être payé tôt. Le premier point de sortie est lorsque votre produit dispose de suffisamment de fonctionnalités pour pouvoir être utilisé au moins sous certains aspects. Cela ajoute donc de la valeur à l'entreprise cliente. C'est pourquoi il est intelligent de développer module par module.
Libérer souvent est bon pour votre client car il obtiendra plus tôt ce dont il besoin. Je n'ai pas voulu écrire intentionnellement, car le résultat final diffère souvent de l'idée de départ.
Si rien d'autre ne satisfait plus vos clients, car ils se sentiront plus impliqués et vous itérerez votre produit étape par étape.
J'ai le sentiment fort qu'il n'y a rien que vous puissiez dire dans ce cas. Mais je voudrais soulever quelques points:
La résolution des problèmes prend plus de temps
Lorsque vous copiez et collez du code partout, lorsque vous trouvez un bogue dans ce code, il faudra plus de temps pour le corriger et plus de temps pour le tester. Ainsi, vous perdrez des heures supplémentaires dans la phase de support (car je suppose que vous n'avez pas de phase de test intégrée avec une mentalité de `` sortir de la porte '') .
L'ajout d'une nouvelle fonctionnalité prend plus de temps
L'ajout d'une nouvelle fonctionnalité dans le code spaghetti prend beaucoup plus de temps. Et comme il s'agit d'un désordre de copier-coller, vous devez modifier le code à de nombreux endroits. À son tour, cela créera des bogues ou des fonctionnalités inattendues à divers endroits. Ainsi, vous devrez perdre des heures supplémentaires dans la phase de support.
Le skinning UI Elements and Terminology for New Clients prend plus de temps
L'entreprise dans laquelle je travaille en ce moment leur client Web a commencé à être un désordre de copier-coller de code spaghetti. Avant de commencer, il a fallu 2 semaines pour habiller le client Web d'un nouveau client.
Après plus de quelques longues soirées, il faut maintenant un après-midi. Je travaille et je peaufine encore pour que ça prenne moins de temps.
Si votre patron veut fabriquer un produit facile à vendre auprès de différents clients, il doit investir du temps pour s'assurer que vous ne perdrez pas de temps à dépecer votre produit alors que vous pourriez leur vendre de nouvelles fonctionnalités.
Ça va être difficile, mais vous devez faire comprendre à votre patron qu'à moins que vous ne passiez un certain temps maintenant à vous assurer que c'est bien fait, vous perdrez encore plus d'heures à l'avenir en bogues, et cela vous prendra en fait plus de temps pour obtenir le produit. prêt pour un nouveau client à l'avenir.
Tout ce qui l'intéresse, c'est le résultat, vous devez donc lui faire comprendre que le codage de cette façon ne l'aidera pas et ne fera que le gêner.