Dem Client fehlerhaften Code demonstrieren?

Ein Kunde hat mich gebeten, seine Website neu zu gestalten, eine ASP.NET-Webforms-Anwendung, die von einem anderen Berater entwickelt wurde. Es schien ein relativ einfacher Job zu sein, aber nachdem man sich den Code angesehen hat, ist klar, dass dies nicht der Fall ist.

Diese Anwendung wurde nicht gut geschrieben. Überhaupt. Es ist extrem anfällig für SQL-Injection-Angriffe, die Geschäftslogik ist über die gesamte Anwendung verteilt, es gibt viele Duplikate und Dead-End-Code, der nichts bewirkt. Darüber hinaus werden weiterhin Ausnahmen ausgelöst, die unterdrückt werden, sodass die Website anscheinend reibungslos funktioniert.

Meine Aufgabe ist es, einfach HTML und CSS zu aktualisieren, aber ein Großteil des HTML-Codes wird in der Geschäftslogik generiert und wäre ein Albtraum. Meine Schätzung für die Neugestaltung ist länger als vom Kunden angestrebt. Sie fragen warum so lange.

Wie kann ich meinem Kunden erklären, wie schlecht dieser Code ist? In ihren Augen läuft die Anwendung großartig und das Redesign sollte ein einmaliges Erlebnis sein. Es ist mein Wort gegen den vorherigen Berater. Wie kann ich einfache, konkrete Beispiele nennen, die ein nicht technischer Kunde versteht?

Aktualisieren

Vielen Dank für alle Antworten. Die SQL-Injection-Attack-Demonstration macht Sinn und ich werde dies in einer Testumgebung demonstrieren. Das ist nur ein Teil vieler Probleme in dieser Anwendung. Ich suchte nach Möglichkeiten, um zu erklären, warum andere Teile (z. B. HTML, die in der Datenschicht generiert werden) durch bessere Methoden ersetzt werden müssen, damit das HTML- und CSS-Update durchgeführt werden kann. Hier gibt es viele gute Vorschläge, die ich zusammenstellen werde, wenn ich mit meinem Kunden spreche.

Non-Techies sind (zum größten Teil) keine Idioten. Sie können ein technisches Argument verstehen, wenn Sie es hoch genug halten. Wählen Sie eine Aufgabe aus, die Ihrer Meinung nach einfach sein sollte, und erklären Sie, warum dies nicht der Fall ist.

Ich habe erwartet, dass diese Änderung ein Wort in einer Datei ist. Der wahrscheinlichste Ort, um es zu ändern, schien hier zu sein, aber als ich es dort änderte, funktionierte es nur an einem Ort, und diese 7 anderen Orte wurden zerstört. Als ich eine reparierte, brach sie zwei weitere Stellen und verursachte einen Dominoeffekt. Eine Änderung, die ich für 10 Minuten gehalten hatte, dauerte 2 Stunden. Das ist nur ein Beispiel. Es gibt viel mehr unerwartete 2-Stunden-Aufgaben.

Codestruktur, Stil und technische Verschuldung sind eine Sache, mit der Sie - zumindest anfangs, bis der Kunde Ihnen vertraut - leben müssen.

Sicherheitslücken sind eine andere Sache.

Persönlich würde ich eine Schätzung auf der Grundlage der erforderlichen Arbeit unter Verwendung der vorhandenen Struktur und des vorhandenen Stils vornehmen und gleichzeitig klarstellen, dass es erhebliche Probleme mit der Codebasis gibt. Ich möchte die Sicherheitsaspekte separat ansprechen: Machen Sie eine Demonstration eines Hacks in der Datenbank, um den Punkt während eines Meetings nach Hause zu bringen.

Ich hatte große Freude, dies mit einem früheren Kunden mit einem Treue-Geschenk-Kartensystem zu tun, als ich "meine" Karte mit £ 5000 belegte und ihn die Karte auf seiner Kasse überprüfen ließ.

Einige großartige Vorschläge, wie dies dem Kunden vermittelt und kommuniziert werden kann. Hoffentlich zahlen sie sich für Sie aus.

Große rote Fahne hier!

Wenn der Kunde Sie auffordert, keine anderen Änderungen vorzunehmen, als die, denen Sie zugestimmt haben (HTML und CSS), würde ich dieses Projekt weiterleiten und mein Gebot zurückziehen.

Selbst mit einem schriftlichen und gut kommunizierten Überblick über alle Mängel und Sicherheitsprobleme ist die potenzielle Haftung einfach zu groß, als dass ich mich damit abfinden könnte. Selbst wenn der Kunde nach einem Hack oder Verstoß niemals rechtliche Schritte unternahm oder Korrekturen verlangte; Ihr Name und Ihr Ruf sind immer noch mit der Arbeit verbunden!

Möglicherweise verlieren Sie viel mehr, als Sie gewinnen können.

Erklären und möglicherweise den Fehler demonstrieren
Wenn es Ihr Wort gegen sein ist, könnte alles, was Sie sagen, für sie nur heiße Luft sein. Sobald Sie ihnen zeigen, wie ihre App per SQL-Injection missbraucht werden kann, sind Sie plötzlich eine vertrauenswürdige Person. Sie brauchen Glaubwürdigkeit, um neu zu verhandeln. Und das ist genug von einem Game-Changer, um es Ihnen zu geben.

Seien Sie Ihrem Vorgänger gegenüber wohltätig
Das bedeutet nicht, dass Sie so tun, als wären die Fehler nicht da. Wenn Sie jedoch auf Herablassen stoßen, verlieren Sie an Glaubwürdigkeit. Sagen Sie kein Wort über den Programmierer, außer vielleicht, um ihm den Vorteil des Zweifels zu geben. Konzentrieren Sie sich auf den Code, nicht auf den Codierer. Wenn Sie das Gefühl haben, der "Gute" zu sein, haben Sie viel mehr Verhandlungsspielraum. Und "Gute" sagen niemals gemeine Dinge. Wenn ich dem Client vorhandene Sicherheitsfehler (z. B. SQL-Injection-Schwachstellen) erkläre, möchte ich Folgendes sagen:

Die Sicherheit von Webanwendungen ist ein sich schnell entwickelndes Feld. Viele der Entwicklungstools und -techniken, die Menschen heute noch lernen, haben sich entwickelt, bevor die meisten dieser Exploits gut verstanden wurden. Um den Sicherheitsentwicklungen immer einen Schritt voraus zu sein, müssen Sie das Feld genau verfolgen und gelegentlich sogar Ihren gesamten Entwicklungsstil ändern. Die meisten Programmierer machen das nicht.

Na, bitte. Über den Entwickler wurde kein böses Wort gesprochen. er ist nur "der meiste Programmierer", was bedeutet, dass er in ziemlich guter Gesellschaft ist. Und jetzt haben Sie bewiesen, dass Sie nicht die meisten Programmierer sind, die Ihnen ein bisschen mehr Glaubwürdigkeit und vielleicht einen Grund dafür bieten, dass sie Ihnen mehr Geld bezahlen.

Verhandeln Sie eine neue Vereinbarung.
Sobald der Kunde versteht, dass seine App von der Öffentlichkeit missbraucht werden kann, möchte er, dass sie repariert wird. Sie sind wahrscheinlich die Person, die er bitten wird, das Problem zu beheben. Sie möchten diesen Job vielleicht oder auch nicht, überlegen Sie es sich also sorgfältig, bevor Sie mit ihnen sprechen.

Zumindest möchten Sie mehr Zeit, um die Arbeit zu beenden, die sie Ihnen bereits gegeben haben. Sie haben sie mit den Sicherheitslücken so überrumpelt, dass sie Sie wahrscheinlich nicht an Ihre ursprüngliche Schätzung halten. Aber stellen Sie sicher, dass der Kunde weiß, was Sie sind und nicht als Teil dieser Vereinbarung repariert werden.

Normalerweise würde der Entwickler (Sie) es vorziehen, das Ganze von Grund auf neu zu machen. Und in solchen Fällen könnte dies sogar eine Option sein. Aber selbst dann wird der Kunde etwas wollen, das sein Geschäft am Laufen hält, bis die neue App erstellt ist. Das bedeutet, dass Sie die alte App wahrscheinlich immer noch aktualisieren müssen , auch wenn Sie von vorne beginnen .

Ich habe das als Kommentar angefangen, weil ich anfangs dachte, es sei eine Seite, aber das ist es wahrscheinlich wirklich nicht.

Ich würde vollständig dokumentieren, dass alles, was Ihrer Meinung nach neu gestaltet werden sollte, und warum (was passiert, wenn sie die Änderung nicht vornehmen) sowie eine Schätzung zur Behebung des Problems. Ich würde mit allem, was Sie als Sicherheitsrisiko empfinden, besonders akribisch umgehen.

Ich würde dies tun, bevor ich einen Code berühre , und sicherstellen, dass Ihr Kunde eine Kopie dieses Berichts hat, vorzugsweise mit einer Art Zeitstempel. Es kann einige Zeit dauern, aber es deckt Sie auch ab, wenn eines dieser Sicherheitsrisiken jemals zum Tragen kommt. Noch besser, wenn Sie eine Unterschrift erhalten, aus der hervorgeht, dass das Dokument bei Ihnen eingegangen ist.

Sicher, Sie können auf die Quellcodeverwaltung des ursprünglichen Codes verweisen, den Sie geerbt haben, falls dies jemals geschehen sollte, aber es ist viel einfacher, auf dieses Dokument zu verweisen und professioneller zu sagen: "Verstehen Sie? Ich habe es Ihnen gesagt."

Dieses Dokument kann der Ausgangspunkt für weitere Diskussionen sein, und es kann sogar von Ihrem Kunden verwendet werden, um die "richtigen Personen" dazu zu bringen, die Erlaubnis zu erteilen, einige oder alle Änderungen vorzunehmen.

Sobald der Kunde die Risiken versteht, muss er grinsen und es ertragen, wenn er sagt, dass er die Arbeit trotzdem erledigen oder weggehen soll.

Denken Sie daran, dass der Kunde Sie bei der Pflege seiner Anwendung um Hilfe bittet. Es ist Ihre Aufgabe als Fachmann, auf Probleme hinzuweisen, die Sie bei der Bewerbung feststellen. Der Kunde hat wahrscheinlich keine Ahnung, dass diese Probleme vorliegen, und sie sollten darauf aufmerksam gemacht werden. Erklären Sie diese Probleme auf eine Weise, die sie verstehen können, und lassen Sie sie entscheiden, wie sie fortfahren möchten.

Verwenden Sie Beispiele aus der Praxis, um diese Probleme zu veranschaulichen, z. B. eine Autopanne oder eine Waschmaschine, die repariert werden muss. Zeigen heißt, Beispiele zu verwenden, mit denen sie bereits vertraut sind. Um die SQL-Injection zu erläutern, würde ich einfach zeigen, was das ist und warum es ein Problem ist.

Am Ende möchten Sie vermitteln, dass Ihnen der Erfolg der Anwendung am Herzen liegt, an der Sie arbeiten sollen.

Ich verwende gerne Analogien, auf die sich der Kunde beziehen kann. Die Menge an Arbeit, die ich im Vorfeld in die Gewinnung des Jobs gesteckt habe, hängt davon ab, wie viel Geld der Kunde ausgeben wollte (100 US-Dollar unterscheiden sich erheblich von 20.000 US-Dollar). Beachten Sie, dass ich "beabsichtigt" sagte. Ihre persönliche Einschätzung des Wertes bedeutet nicht viel, wenn Sie nicht das bekommen, was Sie verlangen.

In Ihrer Situation - wiederum abhängig vom Geld - zeichne ich möglicherweise eine Box mit einer Linie von jeder Seite und sage dem Kunden: "So visualisieren Sie die Software jetzt. Daten gehen an einem Ende vorbei und kommen am anderen Ende heraus sieht nett und sauber und einfach aus ". "So sieht die Software Ihrer Meinung nach von innen aus" und zeichnen Sie dann eine dritte Linie, die die beiden Linien innerhalb der Box verbindet.

Dann würde ich eine andere Box wie die erste mit den Ein- und Ausgabelinien auf der Außenseite zeichnen, mit der Ausnahme, dass ich diesmal sagen würde: "So sieht die Software im Moment wirklich in der Box aus." und dann, um die zwei Linien dieses Mal zu verbinden, würde ich einen zufälligen Haufen Spaghetti-Chaos zeichnen, möglicherweise mit Pausen und Verbindungen und Kritzeleien.

Schließlich würde ich sagen: "Nun, was Sie von mir verlangen, ist das ..." und eine einfache Form in das erste Kästchen zeichnen, vielleicht einen kleinen Halbkreis, der die Linie berührt, und dann sagen: "Aber um das zu tun, ich". Müsste dies tun ... "und eine Art Tornado aussehende Spiralform um die Linie zeichnen und fortfahren ...", um all dies zu umgehen ... "und auf die Spaghetti in der anderen Box zeigen.

Ich würde denken, dass das den Punkt in ungefähr 2 Minuten nach Hause fahren würde. Wenn sie darauf bestehen, dass Sie es trotzdem tun, dann dokumentieren Sie es wie oben erwähnt.

Wie kann ich meinem Kunden erklären, wie schlecht dieser Code ist?

Vielleicht können Sie eine Analogie wie das Klempnerhandwerk in einem Haus anwenden, das im Laufe der Zeit nach dem Reparieren und Umgestalten so launisch und unbeständig wird, dass beim Reparieren einer Sache etwas anderes beeinflusst und möglicherweise zerstört wird, das dann repariert werden muss, und es gibt einfach keine Möglichkeit für Sie, es zu wissen alle Orte, an denen dies auftreten wird.

Es ist mein Wort gegen den vorherigen Berater. Wie kann ich also einfache, konkrete Beispiele nennen, die ein nicht technischer Kunde verstehen würde?

Sie haben recht, es ist ein Wort gegen das, was der vorherige Berater in ihren Köpfen geschaffen hat. Mein Vorschlag ist, genau das zu tun, wonach Sie fragen, und einfache, konkrete Beispiele zu nennen. Da es sich um ein Redesign handelt, zeigen Sie, wie ein im kompilierten Code definiertes HTML-Fragment mit dem Rest einer HTML-Seite angezeigt wird und wie sich dies auf den Rest der Seite auswirkt oder nicht. Vielleicht rendert derselbe kompilierte Code das Markup, nachdem eine "Geschäfts" -Regel angewendet wurde. Zeigen Sie den Unterschied.

Dies ist ein hartes und sehr verbreitetes Problem. Viel Glück damit.

Sei ehrlich und direkt.

Am wichtigsten ist jedoch, dass Sie keine Arbeit annehmen, die Ihren Erwartungen nicht entspricht. Die meisten Menschen wissen nicht, dass ein Auftragnehmer einen Kunden entlassen kann, sie können und sollten, wenn die Arbeit mehr Mühe bereitet als sie sich lohnt.

Hier ist eine Analogie, die ich verwendet habe (obwohl ich nicht für die Wirksamkeit bürge): Stellen Sie sich vor, ihre Website ist eine physische Maschine, wie eine mechanische Druckmaschine, die Eingaben irgendwie akzeptiert.

Sie denken wahrscheinlich, dass die Maschine über eine Komponente verfügt, die X und eine andere, die Y ausführt. In Wirklichkeit sind es 20 oder so meist ähnliche Maschinen. Einige von ihnen tun nichts mehr, alle versuchen, Funktionen vorzubereiten, die andere bereits tun, und niemand außer dem vorherigen Berater hat jemals etwas gesehen, das genau so ist wie sie.

"Sehen Sie sich dieses Gizmo hier an, das die Post-Variablen analysiert und diese Komponente dann durch ein Kaninchenloch von If-Elses schickt? Es gibt nicht nur eine davon, es gibt eine davon auf jeder Seite (oder was auch immer), einige davon Desinfizieren Sie die Eingabe und einige tun es nicht (oder alle tun es nicht) und ohne das ganze zu lesen, kann ich nicht wissen, welche. "

Ein Punkt, der noch nicht wirklich erwähnt wurde, ist, dass Sie in diesem Fall möglicherweise einfach das überschreiten, was Ihr Kunde wirklich von Ihnen will. Übererfüllung ist großartig und kann Ihnen viel Arbeitszufriedenheit bringen. Aber wenn es dem Kunden einfach egal ist, er die aktuelle Leistung für "gut genug" hält und nur ein paar kleinere Aktualisierungen wünscht, kann es unmöglich sein, ihn davon zu überzeugen, eine große Investition in Sie zu tätigen, um die Codebasis zu überarbeiten.

An diesem Punkt müssen Sie sich wahrscheinlich entscheiden, ob Sie sich an Grundsätze halten und sich weigern, einen Job anzunehmen, der Sie zwingen würde, Ihren guten Namen in ein peinliches Code-Chaos zu stecken, oder ob Sie Ihre Nase halten, einsteigen und die Arbeit erledigen können mit etwas Klebeband, und mit Ihrer Zahlung raus.

Wenn Sie den Klebebandauftrag dennoch ausführen möchten, stellen Sie sicher, dass Sie dokumentieren, dokumentieren, dokumentieren und so transparent wie möglich sind. Das Letzte, worüber Sie sich Gedanken machen möchten, ist die Schuld an einem zukünftigen Fehler, der auf einen Anwendungsfehler zurückzuführen ist, vor dem Sie den Kunden gewarnt haben, bei dem der Kunde jedoch festgestellt hat, dass er zu diesem Zeitpunkt nicht wichtig genug war.

Was die SQL-Injection-Risiken angeht, sollten Sie, wie andere gesagt haben, in der Lage sein, die Gefahren für sie auf eine Weise aufzuzeigen, die die Risiken aufzeigt, ohne tatsächlich irgendetwas in der Produktion zu zerstören. Aber auch hier, wenn sie es sehen und es Ihnen nicht wichtig genug ist, es zu reparieren, haben Sie in diesem Fall nach bestem Wissen und Gewissen vorgegangen.

Es ist kein Problem, in ein Projekt einzusteigen und als Erstes ein Umschreiben vorzuschlagen, eine kleine Teilmenge der Modifikationen durchzuführen und anhand dieser zu veranschaulichen, wie viel einfacher und billiger es hätte sein können. Dann haben Sie einen nachweisbaren Grund dafür, warum die höheren Kosten für eine sauberere Entwicklung zu geringeren Wartungskosten und einer schnelleren Entwicklung auf lange Sicht führen, wenn ein geringer Teil der Schriftartkosten anfällt.

Vergessen Sie niemals, dass Sie im Grunde genommen darum bitten, dass sie Sie bezahlen, um Ihr eigenes Leben einfacher zu machen. In ihren Augen kann die bloße Notwendigkeit, einen Mann zu finden, der X-Funktionen zu Y-Kosten bietet und die Komplexität Ihres Projekts vergrößert, die Chance möglicherweise ausschließen für dich. Es ist ein schwieriger Weg, wenn Sie sich nach einem Monat mit dem ursprünglichen Entwickler treffen und feststellen müssen, dass die gesamte App von einem Entwickler in einem äußerst eingeschränkten Fenster geschrieben wurde, der alle eingegangenen Kompromisse vollständig verstanden hat. Wenn die App von innen schrecklich aussieht, aber von außen gut funktioniert, ist dies sehr wahrscheinlich. Oft ist die technische Verschuldung innerhalb einer Codebasis ein Produkt der Ressourcenbeschränkungen, in denen der Code entwickelt wurde, und wenn sie kein Team bilden und stattdessen Dinge auslagern ...

Ich sage ja nur'

Ich werde hier Devil's Advocate spielen (in Anlehnung an das, was @khrome sagt: "Sie zahlen keine Kunden, um Ihr Leben einfacher zu machen "). Ich würde sogar sagen, dass der von Ihnen vorgelegte Fall zu einseitig ist, weil Sie den Fall allgemein beschrieben haben. Die meisten eingehenden Berater für ein neues Projekt würden ein schlechtes Licht auf das vorherige werfen ... Ich sage nicht, dass Sie das hier tun, aber bis wir Beispiele sehen, kann ich nicht einfach Ihr Wort dafür nehmen.

Das heißt, ich werde versuchen, die Probleme Punkt für Punkt an Sie zu adressieren:

• SQL-Injektionen . OK, also denke ich, dass der Programmierer Zeichenfolgenverkettungen anstelle von parametrisierten Abfragen und / oder gespeicherten Prozeduren verwendete. Dies ist besonders in ADO.NET sehr einfach zu beheben ... Ich persönlich würde es dem Kunden gegenüber erwähnen, aber nicht zu viel daraus machen.
• HTML wird in der Geschäftslogik generiert und wäre ein Albtraum, den es zu lösen gilt . OK, Alter, das ist einer von denen, bei denen du mir mehr Details gibst. Wenn Sie nicht MVC verwenden, ist dies eine Tendenz, aber es ist nicht unbedingt eine schlechte Sache. Es ist eine der Situationen, in denen die meisten Programmierer sagen würden, " goto is bad; never use it", aber wissen Sie was? Ich habe gehe dahin, wo es Sinn machte! Sind Sie sicher, dass sie keine Hilfsklassen verwenden, die zufällig denselben Namespace wie die Geschäftscode-DLL verwenden? Auch hier ist es nicht so schwer zu isolieren.
• Die Geschäftslogik ist über die gesamte Anwendung verteilt, es gibt viele Duplikate und Dead-End-Code, der nichts bewirkt. . Und? Der Client fordert Sie lediglich auf, HTML / CSS zu ändern. Warum interessieren Sie diese Themen überhaupt?
• Es werden weiterhin Ausnahmen ausgelöst, die unterdrückt werden, sodass die Website anscheinend reibungslos funktioniert . Wieder sehr vage. Ausnahmen sind in allen Anwendungen normal. Aus diesem Grund haben wir Try / Catch-Klauseln in unserem Code. Sofern sie nicht in der Benutzeroberfläche auftauchen und die Benutzererfahrung ruinieren (z. B. das unnötige Anzeigen von HTTP 500), sollten Sie sich auch nicht darum kümmern.

Kurz gesagt, ich rate Ihnen, die Hauptstraße zu nehmen. Wenn Sie der Meinung sind, dass es Ihre Zeit nicht wert ist und Sie es auf Kosten Ihres Kunden umschreiben möchten, gehen Sie vom Job weg. Im Ernst, am Ende zahlt der Kunde für Ihre Zeit, damit das Ganze mit dem geringsten Geldbetrag funktioniert.

Aufgrund meiner langjährigen Erfahrung in diesem Bereich bin ich immer der Meinung, dass die besten Programmierer, denen ich begegnet bin, diejenigen sind, die ein System stabilisieren können, indem sie die geringste Menge an Code schreiben , nicht indem sie das Ganze neu schreiben .

Bearbeiten: Ich sehe bereits, dass meine Antwort nicht die beliebteste ist (ich habe dies bereits erwartet), aber ich stehe zu meiner Antwort. Ich habe dies bearbeitet, um es weniger snarky zu machen. ;-)

Sicherlich hatten die SQL-Injection-Angriffe und andere Funktionsmängel in der Anwendung Vorrang, aber Sie können auch schlechte Codequalität und -praktiken "demonstrieren". Mit Tools für Codemetriken können Sie deutlich machen, wie schlecht der Code ist, und ihm zeigen, wie hoch die Kosten für zukünftige Änderungen und Fehlerbehebungen sind. Ich bin mit der .net-Umgebung nicht vertraut, bin mir aber sicher, dass es mehrere Möglichkeiten gibt.