Démontrer un mauvais code au client?
Un client m'a demandé de refaire son site Web, une application ASP.NET Webforms qui a été développée par un autre consultant. Cela semblait être un travail relativement simple, mais après avoir examiné le code, il est clair que ce n'est pas le cas.
Cette demande n'a pas été bien écrite. Du tout. Il est extrêmement vulnérable aux attaques par injection SQL, la logique métier est répartie dans toute l'application, il y a beaucoup de duplication et un code sans issue qui ne fait rien. En plus de cela, il continue de lever des exceptions qui sont étouffées, donc le site semble fonctionner correctement.
Mon travail consiste simplement à mettre à jour le HTML et le CSS, mais une grande partie du HTML est généré dans la logique métier et serait un cauchemar à trier. Mon estimation sur la refonte est plus longue que ce que le client visait. Ils demandent pourquoi si longtemps.
Comment puis-je expliquer à mon client à quel point ce code est mauvais? Dans leur esprit, l'application fonctionne très bien et la refonte devrait être rapide. C'est ma parole contre le consultant précédent. Comment puis-je donner des exemples simples et concrets qu'un client non technique comprendra?
Mise à jour
Merci pour toutes les réponses. La démonstration de l'attaque par injection SQL est logique et je vais la démontrer dans un environnement de test. Ce n'est qu'une partie de nombreux problèmes dans cette application. Je cherchais des moyens d'expliquer pourquoi d'autres parties (comme le html généré dans la couche de données) devraient être remplacées par de meilleures pratiques pour que la mise à jour html et css ait lieu. Il y a beaucoup de bonnes suggestions ici que je rassemblerai lorsque je parlerai avec mon client.
Les non-techniciens ne sont pas des idiots (pour la plupart). Ils peuvent comprendre un argument technique si vous le maintenez suffisamment haut. Choisissez une tâche qui, selon vous, devrait être simple et expliquez-lui pourquoi elle ne l'est pas.
Je m'attendais à ce que ce changement soit un mot dans un fichier. L'endroit le plus probable pour le changer semblait être ici, mais quand je l'ai changé là-bas, cela ne fonctionnait qu'à un seul endroit, et il a cassé ces 7 autres endroits. Lorsque j'en ai réparé un, il a cassé deux autres endroits, provoquant un effet domino, donc un changement que je pensais avoir dû prendre 10 minutes a fini par prendre 2 heures. Ce n'est qu'un exemple. Il y a beaucoup plus de tâches inattendues de 2 heures.
La structure du code, le style, la dette technique sont une chose - au moins initialement, jusqu'à ce que le client vous fasse confiance - dont vous aurez besoin pour vivre.
Les failles de sécurité sont une autre affaire.
Personnellement, je ferais une estimation basée sur le travail requis en utilisant la structure et le style existants tout en précisant qu'il y a des problèmes importants avec la base de code. Je soulèverais les implications de sécurité séparément: faites une démonstration d'un piratage de la base de données pour ramener le point de départ lors d'une réunion.
J'ai eu beaucoup de plaisir à faire cela avec un client précédent avec un système de carte-cadeau de fidélité quand j'ai mis 5000 £ sur "ma" carte et lui ai fait vérifier la carte sur son caisse.
Voici d'excellentes suggestions sur la façon de transmettre et de communiquer cela au client. J'espère qu'ils seront payants pour vous.
Drapeau rouge majeur ici!
Si le client vous demande de ne faire aucun changement autre que ce que vous avez accepté (HTML et CSS), je transmettrai ce projet et retirerai ma soumission.
Même avec un aperçu écrit et bien communiqué de tous les défauts et problèmes de sécurité, la responsabilité potentielle est tout simplement trop grande pour que je sois à l'aise. Même si le client n'a jamais intenté d'action en justice ou demandé des correctifs après un piratage ou une violation; votre nom et votre réputation sont toujours attachés à l'œuvre!
Vous risquez bien de perdre bien plus que vous ne gagnez.
expliquer et éventuellement démontrer la faille
Quand c'est ta Parole contre la sienne, tout ce que tu dis peut être de l'air chaud en ce qui les concerne. Une fois que vous leur montrez comment leur application peut être utilisée de manière abusive via l'injection SQL, vous êtes soudainement une personne de confiance. Vous allez avoir besoin de crédibilité pour renégocier. Et cela suffit à changer la donne pour vous le donner.
Soyez charitable envers votre prédécesseur
Cela ne veut pas dire que les erreurs ne sont pas là, mais si vous rencontrez de la condescendance, vous perdez en crédibilité. Ne dites pas un mot du programmeur, sauf peut-être pour lui donner le bénéfice du doute. Concentrez-vous sur le code, pas sur le codeur. Leur faire sentir que vous êtes le "bon gars" vous donnera beaucoup plus de latitude dans les négociations. Et les "bons gars" ne disent jamais des choses méchantes. Lorsque j'explique les erreurs de sécurité existantes (telles que les vulnérabilités d'injection SQL) au client, je préfère dire quelque chose comme ceci:
La sécurité des applications Web est un domaine en évolution rapide. De nombreux outils et techniques de développement que les gens apprennent encore aujourd'hui ont évolué avant que la plupart de ces exploits soient bien compris. Afin de garder une longueur d'avance sur les développements en matière de sécurité, vous devez suivre le terrain de très près et parfois même changer votre style de développement. La plupart des programmeurs ne le font pas.
Et voilà. Pas une Parole de mal parlée du développeur; il est juste "la plupart des programmeurs" ce qui signifie qu'il est en assez bonne compagnie. Et maintenant, vous avez démontré que vous n'êtes pas "la plupart des programmeurs", ce qui vous donne un peu plus de crédibilité et peut-être une raison pour eux de vous payer plus argent.
Négocier un nouvel arrangement
Une fois que le client comprend que son application est ouverte aux abus du public, il voudra qu'elle soit corrigée. Vous êtes probablement la personne à qui il va demander de le réparer. Vous pouvez ou non vouloir ce travail, alors réfléchissez bien avant de leur parler.
À tout le moins, vous voulez plus de temps pour terminer le travail qu'ils vous ont déjà donné. Vous les avez suffisamment mis au dépourvu avec les éléments de vulnérabilité qui ne vous tiendront probablement pas à votre estimation initiale. Mais assurez-vous que le client sait ce que vous êtes et ne va pas réparer dans le cadre de cet arrangement.
Généralement, le développeur (vous) préférerait refaire le tout à partir de zéro. Et dans des cas comme celui-ci, cela pourrait même être une option. Mais même dans ce cas, le client voudra quelque chose qui puisse faire fonctionner son entreprise jusqu'à la création de la nouvelle application. Cela signifie que même si vous recommencez, vous devrez probablement mettre à jour un peu l'ancienne application.
J'ai commencé cela comme un commentaire, car au début, je pensais que c'était un aparté, mais ce n'est probablement pas vraiment le cas.
Je documenterais pleinement tout ce qui, selon vous, devrait être repensé et pourquoi (que se passe-t-il s'ils ne pas apportent le changement), et une estimation sur la résolution du problème. Je serais particulièrement méticuleux avec tout ce que vous percevez comme un risque pour la sécurité.
Je le ferais avant de toucher tout code, et de m'assurer que votre client a une copie de ce rapport, de préférence avec une sorte d'horodatage. Cela peut prendre un certain temps, mais cela vous couvrira également si l'un de ces risques de sécurité se concrétise. Encore mieux si vous pouvez faire signer quelque chose qui indique qu'ils ont reçu le document.
Bien sûr, vous pouvez pointer vers le contrôle de code source du code d'origine dont vous avez hérité s'il se produit, mais il sera beaucoup plus facile de pointer vers ce document et de dire, de manière plus professionnelle, "Vous voyez? Je vous l'ai dit."
Ce document peut être le point de départ de discussions ultérieures, et il peut même être utilisé par votre client pour obtenir les "bonnes personnes" pour donner la permission d'effectuer tout ou partie des modifications.
Cela étant dit, une fois que le client comprend les risques, souriez et supportez-le s'il vous dit de faire le travail de toute façon ou de vous éloigner.
N'oubliez pas que le client vous demandera de l'aide pour gérer sa demande. C'est votre travail en tant que professionnel de signaler tout problème que vous rencontrez avec leur application. Le client n'a probablement aucune idée de l'existence de ces problèmes et il doit en être informé. Expliquez ces problèmes d'une manière qu'ils peuvent comprendre et laissez-les décider comment ils veulent procéder.
Utilisez des exemples réels pour illustrer ces problèmes, comme une panne de voiture ou une machine à laver nécessitant des réparations. Il s'agit d'utiliser des exemples qu'ils connaissent déjà. Pour expliquer l'injection SQL, je voudrais simplement montrer ce que c'est et pourquoi c'est un problème.
En fin de compte, vous voulez dire que vous vous souciez du succès de l'application sur laquelle vous êtes invité à travailler.
J'aime utiliser des analogies auxquelles le client peut se rapporter. La quantité de travail que j'ai mise de l'avant pour gagner le travail dépendrait de la somme d'argent que le client avait l'intention de dépenser (100 $ est très différent de 20 000 $). Remarquez que j'ai dit "intention". Votre estimation personnelle de la valeur impliquée ne signifie pas grand-chose si vous n'obtenez pas ce que vous demandez.
Dans votre situation - encore une fois en fonction de l'argent - je pourrais dessiner une boîte avec une ligne sortant de chaque côté et dire au client "C'est ainsi que vous visualisez le logiciel maintenant. Les données vont à une extrémité et sortent de l'autre, toutes semble agréable et propre et simple ". "Voici à quoi ressemble le logiciel à l'intérieur", puis tracez une troisième ligne reliant les deux lignes à l'intérieur de la boîte.
Ensuite, je dessinais une autre boîte comme la première avec les lignes d'entrée et de sortie à l'extérieur, sauf que cette fois je dirais "Voici à quoi ressemble vraiment le logiciel à l'intérieur de la boîte en ce moment." puis pour relier les deux lignes cette fois, je dessinais une pile aléatoire de désordre de spaghetti, éventuellement avec des ruptures et des jointures et des gribouillis.
Enfin, je dirais: "Maintenant, ce que vous me demandez de faire, c'est ceci ..." et dessiner une forme simple à l'intérieur de la première boîte, peut-être un petit demi-cercle touchant la ligne, puis dire "mais pour ce faire, je ' je dois faire ceci ... "et dessiner une sorte de forme de spirale ressemblant à une tornade autour de la ligne et continuer ..." afin de contourner tout cela ..... "et pointer du doigt les spaghettis dans l'autre boîte.
Je pense que cela ramènerait le point à la maison dans environ 2 minutes. S'ils insistent pour que vous le fassiez de toute façon, documentez-le comme d'autres l'ont mentionné ci-dessus.
Comment puis-je expliquer à mon client à quel point ce code est mauvais?
Peut-être pouvez-vous utiliser une analogie comme la plomberie dans une maison qui, au fil du temps, après des corrections et des remodelages, devient si inconstante et couplée que lors de la réparation d'une chose, affecte et éventuellement brise quelque chose d'autre qui doit ensuite être réparé et il n'y a tout simplement aucun moyen pour vous de savoir tous les endroits où cela se produira.
C'est ma Parole contre le consultant précédent, alors comment puis-je réellement donner des exemples simples et concrets qu'un client non technique comprendrait?
Vous avez raison, c'est Word contre tout ce que le précédent consultant a créé dans leur tête. Ma suggestion est de faire exactement ce que vous demandez, de donner des exemples simples et concrets. Puisqu'il s'agit d'une refonte, montrez comment un fragment HTML défini dans le code compilé est affiché avec le reste d'une page HTML et comment la modification qui affecte ou non le reste de la page. Peut-être que le même code compilé rend le balisage après l'application d'une règle "métier". Montrez la différence.
Il s'agit d'un problème difficile et TRÈS courant. Bonne chance.
Soyez honnête et direct.
Mais surtout, ne prenez pas un travail qui ne répondra pas à vos attentes. La plupart des gens ne réalisent pas qu'un entrepreneur peut licencier un client, ils peuvent et devraient le faire si le travail pose plus de problèmes qu'il n'en vaut la peine.
Voici une analogie que j'ai utilisée (bien que je ne garantisse pas son efficacité): Imaginez que leur site Web est une machine physique, comme une presse à imprimer mécanique qui accepte en quelque sorte l'entrée.
Ils pensent probablement que la machine a un composant qui fait X et un autre qui fait Y. En réalité, il s'agit d'une vingtaine de machines essentiellement similaires. Certains d'entre eux ne font plus rien, tous tentent déjà de réaliser des fonctions que les autres font déjà et personne à part le consultant précédent n'a jamais rien vu exactement comme eux auparavant.
"Voir ce gizmo ici qui analyse les variables de publication et envoie ensuite ce composant dans un lapin de si-elses? Il n'y en a pas seulement un, il y en a un dans chaque page (ou autre), certains d'entre eux aseptiser l'entrée et certains ne le font pas (ou tous ne le font pas) et sans lire le tout, je ne peux pas savoir lequel. "
Un point qui n'est pas encore vraiment mentionné est que vous pourriez simplement dépasser ce que votre client attend vraiment de vous dans ce cas. Le dépassement est excellent et peut vous donner beaucoup de satisfaction au travail. Mais si le client s'en fiche, pense que les performances actuelles sont "assez bonnes" et souhaite simplement quelques mises à jour mineures, il peut être impossible de les persuader de faire un gros investissement en vous pour réviser la base de code.
À ce stade, vous devrez probablement décider de respecter des principes et de refuser de faire un travail qui vous obligerait à attacher votre bonne réputation à un code embarrassant ou si vous pouvez garder le nez, entrer, faire le travail avec du ruban adhésif et sortez avec votre paiement.
Si vous décidez d'aller de l'avant avec le travail du ruban adhésif, assurez-vous de documenter, documenter, documenter et être aussi transparent que possible. La dernière chose que vous voulez, c'est d'être blâmé pour quelque chose qui ne va pas à l'avenir à la suite d'une faille d'application dont vous avez averti le client, mais que le client a décidé n'était pas assez important pour traiter à l'époque.
En ce qui concerne les risques d'injection SQL, comme d'autres l'ont dit, vous devriez pouvoir démontrer les dangers de cela pour eux d'une manière qui montre les risques sans réellement faire quoi que ce soit de destructeur en production. Mais encore une fois, s'ils le voient et ne se soucient pas assez de vous payer pour le réparer, vous avez fait preuve de diligence de bonne foi dans ce cas.
Je vais jouer l'avocat du diable ici (un peu dans le sens de ce que dit @khrome: "vous ne payez pas les clients pour rendre la vie votre plus facile"). J'irais même jusqu'à dire que l'affaire que vous avez présentée est trop unilatérale parce que vous avez décrit l'affaire de manière générale. La plupart des consultants entrants pour un nouveau projet jetteraient un mauvais éclairage sur le précédent ... Je ne dis pas que c'est ce que vous faites ici, mais tant que nous ne verrons pas d'exemples, je ne peux pas simplement prendre votre mot pour cela.
Cela dit, je vais essayer de vous aborder les points point par point:
- Injections SQL. OK, donc je suppose que le programmeur utilisait des concaténations de chaînes au lieu de requêtes paramétrées et/ou de procédures stockées. C'est très facile à résoudre, en particulier dans ADO.NET ... Je le mentionnerais personnellement au client, mais je n'en ferais pas grand cas.
- HTML est généré dans la logique métier et serait un cauchemar à trier. OK, mec, c'est l'un de ceux où tu me donnes plus de détails. À moins que vous n'utilisiez MVC, cela a tendance à se produire ... mais ce n'est pas nécessairement une mauvaise chose ... c'est une de ces choses où la plupart des programmeurs diraient " goto est mauvais; ne l'utilisez jamais "mais vous savez quoi? J'ai utilisé goto là où ça avait du sens! Alors, êtes-vous sûr qu'ils n'utilisent pas de classes auxiliaires qui partagent le même espace de noms que la DLL de code métier? Encore une fois, ce n'est pas si difficile à isoler.
- la logique métier est répartie dans toute l'application, il y a beaucoup de duplication et un code sans issue qui ne fait rien.. Et? Le client vous demande simplement de changer HTML/CSS. Pourquoi vous soucieriez-vous de ces problèmes?
- il continue de lancer des exceptions qui sont étouffées, donc le site semble fonctionner correctement. Encore une fois, très vague. Les exceptions sont normales dans toutes les applications, c'est pourquoi nous avons des clauses try/catch dans notre code. À moins qu'ils ne bouillonnent dans l'interface utilisateur et ne ruinent l'expérience utilisateur (comme l'affichage de HTTP 500 inutilement), je ne pense pas que ce soit quelque chose dont vous devriez vous soucier non plus ..
Bref, je vous conseille de prendre la grande route. Si vous pensez que cela ne vaut pas votre temps et que vous souhaitez le réécrire au détriment de votre client, quittez le travail. Sérieusement, à la fin, le client paie votre temps pour que tout fonctionne avec le moins de $$$.
Dans mes nombreuses années d'expérience dans le domaine, je dis toujours que les meilleurs programmeurs que j'ai rencontrés sont ceux qui peuvent rendre un système stable en en écrivant le moins de code, pas en réécriture du tout.
Edit: je vois déjà que ma réponse n'est pas la plus populaire (je m'y attendais déjà) mais je maintiens ma réponse. J'ai modifié cela pour le rendre moins sarcastique. ;-)
C'est une sauce noob que de venir dans un projet et de suggérer une réécriture en premier lieu, d'effectuer un petit sous-ensemble des modifications et de les utiliser pour illustrer à quel point cela a été plus simple et moins cher pourrait. Ensuite, vous avez un cas démontrable sur la raison pour laquelle l'augmentation du coût d'un développement plus propre entraînera une baisse des coûts de maintenance et un développement plus rapide à long terme étant donné un petit coût côté police.
N'oubliez jamais que, fondamentalement, vous leur demandez de vous payer pour vous faciliter la vie, dans leur esprit, le simple besoin de trouver "le gars" qui peut X fonctionnalités à un coût Y et magnifier la complexité de votre projet peut simplement éliminer l'opportunité pour vous. C'est un chemin difficile quand vous êtes dans un mois dans la réécriture et que vous rencontrez le développeur d'origine seulement pour réaliser que l'application entière a été écrite dans une fenêtre extrêmement contractée par un développeur qui a parfaitement compris tous les compromis qui ont été faits. Si l'application semble horrible en interne mais fonctionne bien en externe, comme vous le dites, il est très probable que ce sera le cas. Souvent, la dette technique au sein d'une base de code est le produit des contraintes de ressources dans lesquelles le code a été développé et s'ils ne construisent pas une équipe et contractent plutôt des contrats ... ils ne sont probablement toujours pas sérieux au sujet de la maintenance.
Je dis juste