Wie kann man erklären, warum Designentscheidungen gut sind? [geschlossen]

Da ich ein besserer Entwickler geworden bin, spüre ich, dass ein Großteil meiner Konstruktionsfähigkeiten eher auf der Intuition als auf der mechanischen Analyse beruht. Das ist toll. Dadurch kann ich Code lesen und schneller ein Gefühl dafür bekommen. Dadurch kann ich Entwürfe viel einfacher zwischen Sprachen und Abstraktionen übersetzen. Und damit kann ich Dinge schneller erledigen.

Der Nachteil ist, dass es mir schwerer fällt, Teammitgliedern (und noch schlimmer dem Management) zu erklären, warum ein bestimmtes Design vorteilhaft ist. vor allem Teamkollegen, die mit Best Practices hinter der Zeit sind. "Dieses Design ist mehr testbar!" oder "Sie sollten die Komposition der Vererbung vorziehen." Gehen Sie direkt über ihre Köpfe hinweg und führen Sie mich in das Kaninchenloch, in dem ich versuche, alle auf das letzte Jahrzehnt der Fortschritte in der Softwareentwicklung hinzuweisen.

Ich werde es natürlich mit dem Üben besser machen, aber in der Zwischenzeit ist es mit viel Zeitverschwendung und / oder schlechtem Design verbunden (das wird zu Zeitverschwendung führen, um es später zu reparieren). Wie kann ich besser erklären, warum ein bestimmtes Design überlegen ist, wenn die Vorteile für das Publikum nicht ganz offensichtlich sind?

Dies beantwortet Ihre Frage möglicherweise nicht direkt, führt Sie jedoch möglicherweise in eine interessante Richtung.

Ich denke, was Sie tun müssen, ist mehr damit zu tun , sie über die Idee zu verkaufen , als sie ihnen zu erklären . Beim Verkauf geht es darum, das Problem des Kunden zu verstehen und ihm dann zu zeigen, wie Ihr Produkt (oder Ihre Entwicklungsmethode, was auch immer) für ihn von Nutzen ist . Jede Person hat unterschiedliche Bedürfnisse, daher können die Dinge, die einer Person zugute kommen und sie aufregen, eine andere Person kalt lassen.

Die Time-to-Market-Zeit für Ihren CEO ist möglicherweise der Schlüssel, für Ihren Manager sind es möglicherweise vorhersehbarere Zeitpläne, für Ihre Programmierkollegen ist es möglicherweise eine schnellere Codierung (oder einfachere Tests / Dokumentation / Fehlersuche / was auch immer) und für die Kunden Ihres Unternehmens könnte sein ... ?

Verkäufe finden nicht automatisch statt - Sie müssen konzertierte Anstrengungen unternehmen, um die Sichtweise der anderen Person zu verstehen , und dann herausfinden, wie Sie Ihre Ideen in Happy Place ™ umsetzen können. Sobald sie wissen, wie sie persönlich von dieser neuen Sache profitieren werden, fragen sie oft: "Wie viel wird es kosten und wie schnell können wir es tun?" Wenn Sie diese magischen Worte einmal gehört haben, wissen Sie, dass Sie Ihren Verkaufsjob gut gemacht haben.

Ich habe keine wirkliche Lösung für Ihre Frage, aber vor einiger Zeit hatte ich genau das gleiche Dilemma und wollte genau diese Frage beantworten.

Ich würde mich auf der einen Seite des Streits und auf der anderen Seite eines anderen wiederfinden, und obwohl jede Faser meines Körpers mir sagte, dass das richtige Design X ist, konnte ich es nicht mit Worten bestätigen.

Schlimmer noch ist, dass ich manchmal den Punkt zugestand und der anderen Person erlaubte, ihn auf ihre Weise umzusetzen, nur um ihr Design in die Luft zu jagen, und dann dachte ich: "Ja, das ist ein perfektes Beispiel dafür, warum ich es nicht wollte Wenn ich ihnen diesen Code damals nur demonstrieren könnte. "

Nun, ich habe die Antwort erst vor ein paar Tagen gefunden, als ich mich durch Lean Software Development: An Agile Toolkit gekümmert habeIch bin auf etwas Interessantes gestoßen, das darauf hindeuten könnte, dass die Antwort tatsächlich nicht existiert. In einem Abschnitt des Buches ging es um Führungskräfte in anderen Bereichen, insbesondere in Notfalleinheiten, und darum, wie diese Führungskräfte Entscheidungen treffen. Wenn es brennt oder jemand auf Sie schießt, setzen sich diese Anführer niemals hin und streiten sich mit ihren Teamkollegen über Vor- und Nachteile. Stattdessen nutzen sie die Intuition, die durch Training und Erfahrung entwickelt wurde, um Entscheidungen zu treffen. Gleiches gilt für unseren Beruf: Wie können Sie bei einer Vielzahl von Unbekannten und Schwankungen, die in der Softwareentwicklung so häufig vorkommen, eine völlig logische Entscheidung treffen? Die Autoren argumentieren, dass die Entwickler angehalten werden sollten, ihre Instinkte zu trainieren und zu verbessern, anstatt zu versuchen, alle Entscheidungen zu rechtfertigen, damit sie irgendwann "nur noch wissen", was zu tun ist.

Die einzige Möglichkeit, diese Argumente zu überwinden, besteht darin, eine nachgewiesene Erfolgsbilanz meiner Arbeit zu erstellen. Um dem Management und anderen Mitarbeitern in meinem Team zu zeigen, dass die von mir in meinem Code getroffenen Entwurfsentscheidungen zu Code führen, der einfacher zu warten, zu erweitern und zuverlässiger ist. Sie tun dies wiederholt und die Leute werden Sie bemerken. Zu diesem Zeitpunkt wird Ihre Meinung, die möglicherweise nur auf Ihrem Instinkt basiert, ein viel höheres Gewicht haben als heute. Diese Strategie hat bei über 90% meines Teams einschließlich meines Chefs funktioniert. Leider werden Sie vielleicht einen oder zwei Typen finden, die völlig eigensinnig sind und sich weigern, irgendetwas auf Ihre Weise zu sehen. Zu diesem Zeitpunkt haben Sie einige Optionen:

1. Sie können versuchen, einen Rang zu ziehen (ich ging schließlich zu meinem Chef und fragte nach einem Rang, weil ich diese Sackgassen-Argumente so satt hatte)
2. Sie können versuchen, sich für die Mehrheit des Teams einzusetzen, um Sie zu unterstützen.
3. Wenn sich das Projekt leisten kann (dh nicht zu viel Produktivitätsverlust), was Ihrer Meinung nach eine schlechte Entscheidung ist, lassen Sie die andere Person das Argument gewinnen. Eines von zwei Dingen wird passieren:
   • In einigen Fällen (hoffentlich in sehr geringem Umfang) ist Ihre Intuition falsch und Sie werden am Ende etwas lernen. Schön für dich.
   • In den meisten Fällen (wieder ... hoffentlich) werden Sie UND die Person, die "schlechtes" Design befürwortet, genau erkennen, warum es schlecht ist; im nachhinein immer 20/20. Hoffentlich wird dies eine Lektion für diese Person sein, die möglicherweise weiß, wovon Sie sprechen, und das nächste Mal überlegt sie sich zweimal, ob sie ihren Fall diskutieren sollen.

Nun, diese Antwort ist für die Programmierung nicht so spezifisch, wie Sie vielleicht denken. Sie müssen es auf Dinge zurückführen, die sie verstehen.

Wenn es so etwas wie Komposition über Vererbung ist, müssen Sie wahrscheinlich nur sagen, dass derzeit vielleicht 90% der Entwickler dies als Best Practice betrachten würden (eine wilde Vermutung, die teilweise auf der Tatsache beruht, dass 100% der Entwickler sich auf fast nichts einigen), und Sie Ich bin damit einverstanden und gehe gerne auf das Warum ein.

Ich versuche so ehrlich wie möglich zu sein, was umstritten ist und wie viel Prozent der Entwickler mir zustimmen würden.

Dies funktioniert in der Regel besser mit dem Management als mit Entwicklern, die Sie wahrscheinlich dazu bringen, zu erklären, ob Sie wirklich gutes Design befürworten und woher Sie es wissen. Es ist etwas Lobenswertes dabei, aber es bedeutet, dass Sie viel Zeit investieren müssen. Es sei denn, sie vertrauen Ihnen genug, um Ihr Wort für solche Dinge zumindest vorläufig zu nehmen. Auf der guten Seite können sie Sie davon überzeugen, dass Sie falsch liegen, was die kalte, harte Realität schlägt, die Sie auf der Straße überzeugt.

Wenn Dinge wie ein Design mehr testbar sind und sie nicht der Meinung sind, dass es mehr testbar ist, ist es so ziemlich dasselbe wie das erste Beispiel. Wenn sie sich nicht einig sind, dass es wünschenswert ist, prüfbarer zu sein, müssen Sie es auf Dinge zurückführen, die sie verstehen. Dies ist höchstwahrscheinlich das Management, und Sie können über langfristig niedrigere Entwicklungskosten, weniger Qualitätssicherung, besser vorhersehbare Prozesse (da die Länge wiederholter Qualitätssicherungszyklen schwer vorherzusagen ist) usw. sprechen.

Ich denke, ein Teil des Problems ist, dass Sie unterschätzen, wie schwierig es ist, ein Team dazu zu bringen, sich auf etwas Kontroverses zu einigen, auch wenn Sie zufällig richtig sind (und natürlich nicht). Das Programmieren ist zum Teil eine soziologische Übung, und Sie müssen möglicherweise Zeit einplanen, um einige dieser Hasenlöcher tatsächlich zu befahren, da ein großartiges Design, das niemand versteht oder hinter sich lässt, in der Praxis selten ein großartiges Design ist. Betrachten Sie diese Zeit nicht als verschwendet, sondern als einen wichtigen Teil Ihres Projekterfolgs. Auch wenn es so viel einfacher wäre, wenn Sie es irgendwie überspringen könnten.

Die einzige Stimme der Veränderung zu sein, ist nie einfach. Die erste Herausforderung besteht normalerweise darin, andere Leute an Bord zu holen (hoffentlich gibt es einige in Ihrem Unternehmen, die aufgeschlossener sind als die anderen). Wenn Sie die Aufmerksamkeit von ein paar anderen erfahrenen Entwicklern / Managern auf sich ziehen können, um sich Ihrem Kreuzzug anzuschließen, werden diese kombinierten Stimmen für den Rest immer schwerer zu ignorieren sein.

Ich finde eine gute Möglichkeit, Menschen zu erklären, indem ich konkrete Beispiele für Fehler in der Vergangenheit in Projekten liefere, an denen sie aktiv beteiligt waren (z. B. "Haben Sie jemals versucht, dieses Ding zu debuggen? Es ist seit Jahren so und niemand weiß, wie es geht." repariere es.."). Besser noch, Sie wenden diese „neuen“ Designideen und -prinzipien auf ein kleines Projekt an und können zeigen, wie erfolgreich es am Ende war.

Abhängig von den Einstellungen anderer in Ihrem Unternehmen kann es schnell zu Veränderungen kommen, oder es kann sein, als würde man versuchen, durch Melassesirup zu schwimmen. Einige Manager sind völlig unbeweglich, es sei denn, sie haben solide Statistiken / Beweise vor sich, während andere sehr daran interessiert sind, mit den neuesten Überlegungen Schritt zu halten.

Je nachdem, mit wem Sie es zu tun haben, müssen Sie möglicherweise verschiedene Taktiken ausprobieren. Der Vorschlag, Geld, Zeit und Mühe zu sparen und die Qualität zu verbessern, ist ein guter Weg, um die Aufmerksamkeit von nicht-technischen Managern auf sich zu ziehen. Das Versprechen des einfachen automatisierten Testens spricht eine ganze Reihe von Entwicklern an, die es normalerweise nicht ertragen können, Tage damit zu verbringen, dieselben Testtabellen wiederholt durchzuarbeiten.

Kommt auf das Publikum an! Als Entwickler haben wir eine Intuition für guten und schlechten Code entwickelt und verwenden vage emotionale Begriffe wie "Codegeruch", "hässlicher Code", "schöne Lösung". Dies funktioniert nur, wenn Sie mit anderen Entwicklern mit derselben Einstellung kommunizieren. Versuchen Sie Ihrem nicht-technischen CEO zu erklären, dass Sie x Mannstunden investieren sollten, um Code "schöner" zu machen. Sie werden höchstwahrscheinlich spektakulär scheitern.

Sie müssen in der Lage sein, den Fall zu begründen, dass eine bestimmte Designverbesserung auch dazu führt

• Sparen Sie Geld für das Unternehmen
• Geld verdienen für das Unternehmen

Was ist zum Beispiel der Fall, wenn das Prinzip der Einzelverantwortung eingehalten wird? Wenn jede Klasse eine einzelne Verantwortung hat, ist es viel einfacher, Fehler zu lokalisieren und zu beheben, und es ist einfacher, Funktionen und Verbesserungen hinzuzufügen. Weniger Zeit zum Beheben von Fehlern und Hinzufügen von Funktionen = Geld gespart.