Wie würden Sie einer nichttechnischen Person erklären, warum das Schreiben von Code (Business-Logik) hinter dem onclick-Ereignis eine schlechte Übung ist und zu nicht mehr erreichbarem Code führt?
Bearbeitet: Ich muss dem Management erklären, warum ein Refactoring benötigt wird, auch warum Code nicht Code-Überprüfung passiert. Für manche Führungskräfte bedeutet das nur mehr Mittel. Ich kam zu diesem Beispiel, weil jemand an einem Punkt einer Diskussion gesagt hat: "Gib den Code hinter dem Knopf ein und vergiss den ganzen Modell-View-Controller-Hype, du wirst deine Aufgabe schneller erledigen."
So würde ich es erklären:
Der Unterschied zwischen dem Schreiben von Code hinter onclick-Ereignissen und dem Schreiben von Anwendungen, die mehrstufig oder geschichtet sind, ist wie der Unterschied zwischen einer mittelalterlichen Stadt und einer modernen Stadt >
In einer mittelalterlichen Stadt pflügt jeder sein Feld, jeder näht seine Kleidung, baut sein Haus und bildet seine Kinder nach besten Kräften aus, niemand ist wirklich darauf spezialisiert, eine Aufgabe gut zu machen, Sie müssen alle Aufgaben erledigen, die zum Überleben notwendig sind. So ist das Schreiben von Code hinter onclick-Ereignissen, der Code muss alles machen, UI-Interaktionen handhaben, Geschäftsvalidierungen durchführen, Datenbankzugriffe handhaben, und dies wird für jedes Ereignis wiederholt.
In einer modernen Stadt gibt es Bauern, die Landwirtschaft in größerem Maßstab betreiben und sich auf sie spezialisieren, es gibt Schneider, die aufgrund größerer Erfahrung und Spezialisierung bessere Kleidung für jeden nähen können, es gibt Baumeister, Es gibt Lehrer, die Kinder in Schulen unterrichten und dort bessere Arbeit leisten können, weil sie mehr Zeit dafür haben. So sieht das Schreiben einer mehrschichtigen Anwendung aus: Die Benutzerschicht ist für die Verarbeitung von Benutzeranforderungen und nur für die Aktualisierung der Benutzerschnittstelle zuständig und kann daher leichter geändert oder ersetzt werden, da keine zusätzliche Code-Belastung entsteht. Die Geschäftsschicht ist für die Geschäftslogik zuständig und die gesamte Logik ist zentralisiert, wiederverwendbar, der Geschäftslogikcode ist kompakter und sauberer, die Datenzugriffsebene behandelt die Datenbankinteraktion und ist darauf spezialisiert, möglicherweise mit mehr als einer Art von Datenbank zu interagieren.
Das Schreiben von Code hinter onclick-Ereignissen ist ein rudimentärer Programmierstil, der nicht der effizienteste Stil ist und auf lange Sicht nicht die bestmöglichen Ergebnisse liefert, obwohl die Ergebnisse mehr als oft akzeptabel sind (die Anwendung funktioniert) kann besser arbeiten, einfacher zu warten und zu erweitern und konsistenter sein (in Bezug auf ui, Interaktionen, Fehlerberichterstattung, Workflow usw.), indem ein richtiges gestaffeltes Design verwendet wird, das gute Programmierpraktiken verwendet.
Warum muss eine nichttechnische Person das wissen? Da "Codestil" wirklich eine technische Angelegenheit ist, werden Sie es nicht erklären können, ohne einige der technischen Details dahinter zu erklären.
Wahrscheinlich die einfachste Erklärung, die ich mir vorstellen kann (aber das deckt nicht alle Gründe ab, warum es eine schlechte Praxis ist, was ich glaube, ist der häufigste Grund):
Wenn Sie Software schreiben, bemühen Sie sich, sie so wartbar wie möglich zu machen. Dies bedeutet, dass Sie die Anwendung schnell an sich ändernde Benutzer-, Client- und Verwaltungsanforderungen anpassen können. Der Code hinter einem onClick-Ereignis ändert sich, wenn sich die GUI-Anforderungen ändern. Der Geschäftslogikcode ändert sich, wenn sich die Geschäftsanforderungen ändern. Indem man einen von dem anderen unabhängig macht, wird es weniger Arbeit zu tun geben, wenn sich eines dieser Dinge ändert. Außerdem müssen Sie sich beim Aktualisieren der Geschäftslogik keine Gedanken darüber machen, wie sie mit der GUI verbunden ist. Wenn Sie die GUI aktualisieren, brauchen Sie sich keine Gedanken darüber zu machen, wie die Geschäftslogik tatsächlich funktioniert.
Der andere Hauptgrund ist die Wiederverwendbarkeit. Die GUI mit allen Schaltflächen ist wirklich nur eine 'Ansicht' der zugrunde liegenden Daten / eine Schnittstelle zu diesen Daten. Sie können auf verschiedene Arten auf dieselben Informationen zugreifen / sie ändern, und es wäre überflüssig, die Geschäftslogik zu replizieren. Dies würde auch die Komplexität erhöhen, wenn sich die Geschäftslogik ändert, da Sie sie an mehreren Stellen ändern müssten.
Mit Bildern und Geschichten :)
Nicht zu oberflächlich sein, sondern ein Szenario auf einem Whiteboard aufbauen, wo es eine einfache Geschäftsfunktion gibt (ein Benutzerpasswort ändern). Illustrieren Sie grafisch, wie es aussieht. Jetzt erweitern Sie es, so dass 2 Formulare das Benutzerpasswort ändern müssen (Admin und Benutzer) Doppel-Code! Erklären Sie DRY. Ändern Sie die Regeln zur Kennwortkomplexität, und jetzt benötigen wir eine Doppelkorrektur. Refaktorieren Sie die Felder, um den Code in einen gemeinsamen Bereich im selben Projekt zu verschieben.
Jetzt erweitern Sie es wieder, wo eine andere App dasselbe tun muss. Jetzt ist eine Klassenbibliothek besser. Sprechen Sie ehrlich über die Zunahme der Komplexität gegenüber Wartbarkeit und Resuse.
Spülen und wiederholen, bis es eindringt.
Ich muss wie jeder andere fragen - warum?
Was für eine nichttechnische Person wichtig ist, ist, dass das gewünschte Verhalten passiert, wenn auf die Schaltfläche geklickt wird. Aus ihrer Sicht codieren Sie in das Click-Ereignis.
Aber wenn es wirklich ein Problem ist, konzentriere dich darauf, was die nicht-technischen Menschen interessieren - BUGS. Sie kümmern sich nicht darum, Code elegant zu machen oder schöne Designmuster zu haben, etc. Es geht darum, ob Dinge funktionieren oder nicht.
Sagen Sie etwas wie folgt:
Alle Geschäftsregeln, die in das System einprogrammiert werden müssen, müssen möglicherweise an vielen verschiedenen Orten wiederverwendet werden, wie zum Beispiel ein Bericht, eine Schaltfläche, eine Suche usw. Ich muss vielleicht sogar dieselbe Logik auf einer Webseite verwenden wie Sowie das Softwarepaket. Sie denken vielleicht, dass es nur hier benötigt wird, aber die Erfahrung hat gezeigt, dass Geschäftsregeln meistens an mehr als einer Stelle verwendet werden müssen, und es ist am besten davon auszugehen, dass sie immer wiederverwendet werden.
Wenn ich die Geschäftsregeln direkt hinter die Schaltfläche setze, kann die Wiederverwendung dieser Logik schwierig, wenn nicht sogar unmöglich sein. Dann muss ich mehr als einmal die gleiche Logik in das System einbauen, was mehr Möglichkeiten für Fehler mit sich bringt. Ich könnte die Logik an einem Ort reparieren und es wäre immer noch woanders kaputt.
Stattdessen nehme ich die Geschäftsregeln und lege sie an einen zentralen Ort, sodass ich sie, wo immer ich sie brauche, auch wiederverwenden kann. Dann ist ein Bugfix an einer Stelle ein Fehler, der überall behoben wurde und die Software wird weniger Probleme haben.
Eine Analogie wären Links auf einer Webseite. Anstatt den gesamten Text von einer Webseite in eine andere Webseite zu kopieren, machen wir einfach einen Link. Dann haben wir immer die aktuellsten Informationen.
Denken Sie daran - Nichtechy Leute sind pragmatisch - es geht darum, was sie sofort sehen und benutzen können.
Erzählen Sie Ihren Managern von technischen Schulden (und auch hier )
Ich denke, Sie sollten Ihre Manager von dem allgemeinen Grundsatz überzeugen, dass das Umbauen oder Auszahlen der technischen Schulden hin und wieder notwendig ist. So wie ein Koch seine Küche hin und wieder säubern muss, um gutes Essen zu machen, müssen Sie Ihren Code hin und wieder aufräumen, bevor Sie neue Funktionen implementieren können.
Wenn Ihre Manager mit diesem allgemeinen Grundsatz nicht einverstanden sind, dann sind Sie in großen Schwierigkeiten. Wenn sie einverstanden sind, dann sollten sie meiner Meinung nach nicht in der Lage sein, Sie zu migrieren, sondern Ihrer technischen Expertise vertrauen, welche Art von Refactoring oberste Priorität hat.
Wirtschaft
3/4 der gesamten Lebenszykluskosten einer typischen Softwareanwendung sind Wartung. Indem Sie den 1/4 Teil nach vorne kippen, laden Sie den 3/4.
Skimp der Entwicklung genug und der 3/4 wird 19/20. Tun Sie es richtig und Ihr 100.000-Dollar-Projekt kostet 400.000 Dollar im Laufe seines Lebens. Skip auf TLC vorne und Sie sparen $ 20.000 jetzt aber Ihr Projekt kostet $ 2 Millionen über seine Lebensdauer.
Wenn sich der CFO in der Besprechung befindet, können Sie einen Kommentar in folgenden Zeilen hinterlassen:
Aber keine Sorge, die zusätzlichen $ 1,5 Millionen werden es tun so aus dem Budget eines anderen kommen Es hat keinen Einfluss auf deinen Bonus. "
Die anderen versteckten Kosten, ein herumliegendes Chaos zu hinterlassen, sind die Bit Rotfäule, die Änderungen an der Anwendung massiv verlangsamen und das Risiko unerkannter Fehler erhöhen, die niemand bemerkt, bis sie mitten in einem Monatsende liegen.
Weil Sie die Türklingel nicht direkt mit dem Freigabesummer verbinden würden.
So würde ich es erklären:
Der Unterschied zwischen dem Schreiben von Code hinter onclick-Ereignissen und dem Schreiben von Anwendungen, die mehrstufig oder geschichtet sind, ist wie der Unterschied zwischen einer mittelalterlichen Stadt und einer modernen Stadt >
In einer mittelalterlichen Stadt pflügt jeder sein Feld, jeder näht seine Kleidung, baut sein Haus und bildet seine Kinder nach besten Kräften aus, niemand ist wirklich darauf spezialisiert, eine Aufgabe gut zu machen, Sie müssen alle Aufgaben erledigen, die zum Überleben notwendig sind. So ist das Schreiben von Code hinter onclick-Ereignissen, der Code muss alles machen, UI-Interaktionen handhaben, Geschäftsvalidierungen durchführen, Datenbankzugriffe handhaben, und dies wird für jedes Ereignis wiederholt.
In einer modernen Stadt gibt es Bauern, die Landwirtschaft in größerem Maßstab betreiben und sich auf sie spezialisieren, es gibt Schneider, die aufgrund größerer Erfahrung und Spezialisierung bessere Kleidung für jeden nähen können, es gibt Baumeister, Es gibt Lehrer, die Kinder in Schulen unterrichten und dort bessere Arbeit leisten können, weil sie mehr Zeit dafür haben. So sieht das Schreiben einer mehrschichtigen Anwendung aus: Die Benutzerschicht ist für die Verarbeitung von Benutzeranforderungen und nur für die Aktualisierung der Benutzerschnittstelle zuständig und kann daher leichter geändert oder ersetzt werden, da keine zusätzliche Code-Belastung entsteht. Die Geschäftsschicht ist für die Geschäftslogik zuständig und die gesamte Logik ist zentralisiert, wiederverwendbar, der Geschäftslogikcode ist kompakter und sauberer, die Datenzugriffsebene behandelt die Datenbankinteraktion und ist darauf spezialisiert, möglicherweise mit mehr als einer Art von Datenbank zu interagieren.
Das Schreiben von Code hinter onclick-Ereignissen ist ein rudimentärer Programmierstil, der nicht der effizienteste Stil ist und auf lange Sicht nicht die bestmöglichen Ergebnisse liefert, obwohl die Ergebnisse mehr als oft akzeptabel sind (die Anwendung funktioniert) kann besser arbeiten, einfacher zu warten und zu erweitern und konsistenter sein (in Bezug auf ui, Interaktionen, Fehlerberichterstattung, Workflow usw.), indem ein richtiges gestaffeltes Design verwendet wird, das gute Programmierpraktiken verwendet.
Warum muss eine nichttechnische Person das wissen? Da "Codestil" wirklich eine technische Angelegenheit ist, werden Sie es nicht erklären können, ohne einige der technischen Details dahinter zu erklären.
Wahrscheinlich die einfachste Erklärung, die ich mir vorstellen kann (aber das deckt nicht alle Gründe ab, warum es eine schlechte Praxis ist, was ich glaube, ist der häufigste Grund):
Wenn Sie Software schreiben, bemühen Sie sich, sie so wartbar wie möglich zu machen. Dies bedeutet, dass Sie die Anwendung schnell an sich ändernde Benutzer-, Client- und Verwaltungsanforderungen anpassen können. Der Code hinter einem onClick-Ereignis ändert sich, wenn sich die GUI-Anforderungen ändern. Der Geschäftslogikcode ändert sich, wenn sich die Geschäftsanforderungen ändern. Indem man einen von dem anderen unabhängig macht, wird es weniger Arbeit zu tun geben, wenn sich eines dieser Dinge ändert. Außerdem müssen Sie sich beim Aktualisieren der Geschäftslogik keine Gedanken darüber machen, wie sie mit der GUI verbunden ist. Wenn Sie die GUI aktualisieren, brauchen Sie sich keine Gedanken darüber zu machen, wie die Geschäftslogik tatsächlich funktioniert.
Der andere Hauptgrund ist die Wiederverwendbarkeit. Die GUI mit allen Schaltflächen ist wirklich nur eine 'Ansicht' der zugrunde liegenden Daten / eine Schnittstelle zu diesen Daten. Sie können auf verschiedene Arten auf dieselben Informationen zugreifen / sie ändern, und es wäre überflüssig, die Geschäftslogik zu replizieren. Dies würde auch die Komplexität erhöhen, wenn sich die Geschäftslogik ändert, da Sie sie an mehreren Stellen ändern müssten.
Wie würden Sie einer nichttechnischen Person erklären, warum das Schreiben von Code (Business-Logik) hinter dem onclick-Ereignis eine schlechte Übung ist und zu nicht mehr erreichbarem Code führt?
Bearbeitet: Ich muss dem Management erklären, warum ein Refactoring benötigt wird, auch warum Code nicht Code-Überprüfung passiert. Für manche Führungskräfte bedeutet das nur mehr Mittel. Ich kam zu diesem Beispiel, weil jemand an einem Punkt einer Diskussion gesagt hat: "Gib den Code hinter dem Knopf ein und vergiss den ganzen Modell-View-Controller-Hype, du wirst deine Aufgabe schneller erledigen."
Mit Bildern und Geschichten :)
Nicht zu oberflächlich sein, sondern ein Szenario auf einem Whiteboard aufbauen, wo es eine einfache Geschäftsfunktion gibt (ein Benutzerpasswort ändern). Illustrieren Sie grafisch, wie es aussieht. Jetzt erweitern Sie es, so dass 2 Formulare das Benutzerpasswort ändern müssen (Admin und Benutzer) Doppel-Code! Erklären Sie DRY. Ändern Sie die Regeln zur Kennwortkomplexität, und jetzt benötigen wir eine Doppelkorrektur. Refaktorieren Sie die Felder, um den Code in einen gemeinsamen Bereich im selben Projekt zu verschieben.
Jetzt erweitern Sie es wieder, wo eine andere App dasselbe tun muss. Jetzt ist eine Klassenbibliothek besser. Sprechen Sie ehrlich über die Zunahme der Komplexität gegenüber Wartbarkeit und Resuse.
Spülen und wiederholen, bis es eindringt.
Ich muss wie jeder andere fragen - warum?
Was für eine nichttechnische Person wichtig ist, ist, dass das gewünschte Verhalten passiert, wenn auf die Schaltfläche geklickt wird. Aus ihrer Sicht codieren Sie in das Click-Ereignis.
Aber wenn es wirklich ein Problem ist, konzentriere dich darauf, was die nicht-technischen Menschen interessieren - BUGS. Sie kümmern sich nicht darum, Code elegant zu machen oder schöne Designmuster zu haben, etc. Es geht darum, ob Dinge funktionieren oder nicht.
Sagen Sie etwas wie folgt:
Alle Geschäftsregeln, die in das System einprogrammiert werden müssen, müssen möglicherweise an vielen verschiedenen Orten wiederverwendet werden, wie zum Beispiel ein Bericht, eine Schaltfläche, eine Suche usw. Ich muss vielleicht sogar dieselbe Logik auf einer Webseite verwenden wie Sowie das Softwarepaket. Sie denken vielleicht, dass es nur hier benötigt wird, aber die Erfahrung hat gezeigt, dass Geschäftsregeln meistens an mehr als einer Stelle verwendet werden müssen, und es ist am besten davon auszugehen, dass sie immer wiederverwendet werden.
Wenn ich die Geschäftsregeln direkt hinter die Schaltfläche setze, kann die Wiederverwendung dieser Logik schwierig, wenn nicht sogar unmöglich sein. Dann muss ich mehr als einmal die gleiche Logik in das System einbauen, was mehr Möglichkeiten für Fehler mit sich bringt. Ich könnte die Logik an einem Ort reparieren und es wäre immer noch woanders kaputt.
Stattdessen nehme ich die Geschäftsregeln und lege sie an einen zentralen Ort, sodass ich sie, wo immer ich sie brauche, auch wiederverwenden kann. Dann ist ein Bugfix an einer Stelle ein Fehler, der überall behoben wurde und die Software wird weniger Probleme haben.
Eine Analogie wären Links auf einer Webseite. Anstatt den gesamten Text von einer Webseite in eine andere Webseite zu kopieren, machen wir einfach einen Link. Dann haben wir immer die aktuellsten Informationen.
Denken Sie daran - Nichtechy Leute sind pragmatisch - es geht darum, was sie sofort sehen und benutzen können.
ConcernedOfTunbridgeW erklärt es gut in Bezug darauf, was das Management hören möchte. Der Hauptpunkt ist, dass wenn es momentan Probleme gibt, es wahrscheinlich wegen der Redundanz der Code Logik ist. Das Refactoring, das Sie tun möchten, wird das beseitigen. Es wird auf lange Sicht ein wenig mehr kosten, aber es wird langfristig Geld sparen.
Erzählen Sie Ihren Managern von technischen Schulden (und auch hier )
Ich denke, Sie sollten Ihre Manager von dem allgemeinen Grundsatz überzeugen, dass das Umbauen oder Auszahlen der technischen Schulden hin und wieder notwendig ist. So wie ein Koch seine Küche hin und wieder säubern muss, um gutes Essen zu machen, müssen Sie Ihren Code hin und wieder aufräumen, bevor Sie neue Funktionen implementieren können.
Wenn Ihre Manager mit diesem allgemeinen Grundsatz nicht einverstanden sind, dann sind Sie in großen Schwierigkeiten. Wenn sie einverstanden sind, dann sollten sie meiner Meinung nach nicht in der Lage sein, Sie zu migrieren, sondern Ihrer technischen Expertise vertrauen, welche Art von Refactoring oberste Priorität hat.
Wirtschaft
3/4 der gesamten Lebenszykluskosten einer typischen Softwareanwendung sind Wartung. Indem Sie den 1/4 Teil nach vorne kippen, laden Sie den 3/4.
Skimp der Entwicklung genug und der 3/4 wird 19/20. Tun Sie es richtig und Ihr 100.000-Dollar-Projekt kostet 400.000 Dollar im Laufe seines Lebens. Skip auf TLC vorne und Sie sparen $ 20.000 jetzt aber Ihr Projekt kostet $ 2 Millionen über seine Lebensdauer.
Wenn sich der CFO in der Besprechung befindet, können Sie einen Kommentar in folgenden Zeilen hinterlassen:
Aber keine Sorge, die zusätzlichen $ 1,5 Millionen werden es tun so aus dem Budget eines anderen kommen Es hat keinen Einfluss auf deinen Bonus. "
Die anderen versteckten Kosten, ein herumliegendes Chaos zu hinterlassen, sind die Bit Rotfäule, die Änderungen an der Anwendung massiv verlangsamen und das Risiko unerkannter Fehler erhöhen, die niemand bemerkt, bis sie mitten in einem Monatsende liegen.
Zumindest in dieser Hinsicht werden Sie keinen Erfolg damit haben, dies einer nicht technischen Person zu erklären. Es ist zu technisch von einem Punkt.
Wenn Sie ein bisschen verallgemeinern und vielleicht versuchen, etwas wie die Trennung von Bedenken zu erklären (nicht in diesen Worten), haben Sie vielleicht ein bisschen mehr Glück
Der Grund, warum ich den Code normalerweise nicht hinter das onclick-Ereignis bringe, ist, weil ich den Code oft vervielfältige und alle diese Art von onclick-Ereignissen dieselbe Routine aufrufen wollen.
Dies ist wirklich die Trennung von Business-Schicht (wie Dinge verarbeitet werden) und Präsentationsebene (wie Dinge angezeigt werden).
Die Änderungsrate und die Gründe für die Änderung der beiden sind im Allgemeinen sehr unterschiedlich. Sie möchten flexibel genug sein, um sie so zu ändern, dass sich die geschäftlichen Anforderungen so einfach wie möglich ändern lassen und das Risiko (von Regressionen) reduziert wird.
Der Grund, warum ich den Code normalerweise nicht hinter das onclick-Ereignis bringe, ist, weil ich den Code oft vervielfältige und alle diese Art von onclick-Ereignissen dieselbe Routine aufrufen wollen.
Zumindest in dieser Hinsicht werden Sie keinen Erfolg damit haben, dies einer nicht technischen Person zu erklären. Es ist zu technisch von einem Punkt.
Wenn Sie ein bisschen verallgemeinern und vielleicht versuchen, etwas wie die Trennung von Bedenken zu erklären (nicht in diesen Worten), haben Sie vielleicht ein bisschen mehr Glück
Dies ist wirklich die Trennung von Business-Schicht (wie Dinge verarbeitet werden) und Präsentationsebene (wie Dinge angezeigt werden).
Die Änderungsrate und die Gründe für die Änderung der beiden sind im Allgemeinen sehr unterschiedlich. Sie möchten flexibel genug sein, um sie so zu ändern, dass sich die geschäftlichen Anforderungen so einfach wie möglich ändern lassen und das Risiko (von Regressionen) reduziert wird.
Tags und Links code-behind