Gibt es bei komplexem Design wirklich etwas zu gewinnen?

Ich arbeite seit einiger Zeit für ein Beratungsunternehmen mit Kunden unterschiedlicher Größe und habe Webanwendungen gesehen, deren Komplexität von wirklich einfach bis sehr einfach reicht:

• MVC
• Serviceschicht
• EF
• DB

Zu wirklich komplex:

• MVC
• UoW
• DI / IoC
• Repository
• Bedienung
• UI-Tests
• Unit Tests
• Integrationstests

An beiden Enden des Spektrums sind die Qualitätsanforderungen jedoch ungefähr gleich. In einfachen Projekten können neue Entwickler / Berater sofort einsteigen, Änderungen vornehmen und Beiträge leisten, ohne 6 Abstraktionsebenen durchlaufen zu müssen, um zu verstehen, was vor sich geht, oder das Risiko eingehen, eine komplexe Abstraktion zu missverstehen und später Kosten zu verursachen.

In allen Fällen bestand nie die Notwendigkeit, Code tatsächlich austauschbar oder wiederverwendbar zu machen - und die Tests wurden nie nach der ersten Iteration beibehalten, da sich die Anforderungen änderten, es zu zeitaufwändig war, Fristen, Geschäftsdruck usw. usw.

Also wenn - am Ende -

• Tests und Schnittstellen werden nicht verwendet
• Eine schnelle Entwicklung (sprich: Kosteneinsparungen) hat Priorität
• Die Anforderungen des Projekts werden sich während der Entwicklung stark ändern

... wäre es falsch, einem Unternehmenskunden eine supereinfache Architektur zu empfehlen, selbst um ein komplexes Problem zu lösen? Ist es die Komplexität, die Unternehmenslösungen definiert, oder ist es die Zuverlässigkeit, # gleichzeitige Benutzer, Wartungsfreundlichkeit oder all das oben Genannte?

Ich weiß, dass dies eine sehr vage Frage ist, und jede Antwort würde nicht für alle Fälle gelten, aber ich bin daran interessiert, von Entwicklern / Beratern zu hören, die schon eine Weile im Geschäft sind und mit diesen unterschiedlichen Komplexitätsgraden gearbeitet haben , um zu hören, ob die coolen, aber teuren Abstraktionen die Gesamtkosten wert sind, zumindest während das Projekt in der Entwicklung ist.

... wäre es falsch, einem Unternehmenskunden eine supereinfache Architektur zu empfehlen, selbst um ein komplexes Problem zu lösen?

Das hängt vom Kunden ab. Vielen wird es mit einem einfacheren Ansatz gut gehen. Einige werden denken, dass Sie inkompetent sind, weil dieser einfache Ansatz ihre Probleme nicht lösen wird - die ganze Sache "Das Ding muss aus einem bestimmten Grund super billig sein ...", die dazu führt, dass manche Dinge viel teurer sind, als es kostet, sie herzustellen.

Tests und Schnittstellen werden nicht verwendet

Ich würde argumentieren, dass es in der Hölle keine Möglichkeit gibt, nicht triviale Software ohne diese kostengünstig herzustellen. Wenn Sie als Unternehmen versuchen würden, mir etwas ohne sie zu verkaufen, würde ich befürchten, dass Sie mich mit einem völlig unflexiblen, nicht zu wartenden Haufen dampfenden Hundekot satteln. ( Bearbeiten: um klar zu sein, ich spreche hier nicht über Schnittstellen , nicht interfaces. Prozedurale und funktionale Programme sind nicht alles Misthaufen, obwohl ihnen Schnittstellen im Java-Stil fehlen.)

wenn die cool-aber-teuren Abstraktionen die Gesamtkosten wert sind

Als Programmdesigner müssen wir fundierte Vermutungen anstellen, wo sich die Dinge ändern werden, und dort Linien ziehen, damit sich die Dinge, die sich ändern, so schnell, einfach und korrekt ausführen können. Gute Abstraktionen sparen im Laufe der Zeit Geld, da unvermeidliche Änderungen billig werden.

Aber machen Sie keinen Fehler, der Begriff "Architekturastronaut" existiert aus einem bestimmten Grund. Sie bauen nicht immer das Space Shuttle. Das Hinzufügen von schlechten Abstraktionen, die entweder mitten in Dingen existieren, die geändert werden müssen, oder existieren, um Änderungen zu unterstützen, die nicht existieren ... sie können Sie kosten.

Aber meiner Erfahrung nach habe ich gehört, dass sich Leute über abstrahierten Code beschwert haben , aber ich habe nur gesehen, dass Projekte aufgrund von nicht abstrahiertem Code fehlschlagen .

Zum Architekten oder nicht zum Architekten

Um Einstein neu zu formulieren: "Die Dinge sollten so einfach wie möglich sein - aber nicht einfacher." Es ist wichtig, die wahre Verwendung einiger Architekturen zu verstehen - und sie sind nicht unbedingt für die individuelle Leistung und oft auch nicht für die Arbeitszufriedenheit.

Manchmal sind Architekturen so kompliziert, weil ein Unternehmensprojekt so groß ist und so viele Menschen arbeiten, dass die Architektur hauptsächlich so vielen Menschen ermöglicht, auf etwas hinzuarbeiten, ohne dass jeder über alle anderen stolpert. Manchmal sind sie kaum mehr als Komplexität, die die individuelle Produktivität verringert und die Arbeit erschwert - aber es einer großen Anzahl von Menschen ermöglicht, zu arbeiten. Dies funktioniert, wenn der zusätzliche Aufwand den individuell verringerten Lebenswillen überwiegt, ähm, ich meine "Produktivität".

Ist das die Situation Ihres Kunden? Nun, wenn ihr Budget für dieses Projekt nicht in Millionenhöhe liegt, vielleicht auch nicht. Wenn es unter 100 km ist, dann mit ziemlicher Sicherheit nicht. Sie bauen einen Betonbunker für einen Kernreaktor, keinen Holzofen :)

Es ist nicht unbedingt falsch, Ihrem Kunden "das Einfachste vorzuschlagen, was möglicherweise funktionieren könnte", wenn die Situation dies erfordert. Es könnte der bestmögliche Weg sein, damit umzugehen. Der einfachste Weg, dies zu sehen, besteht darin, es mit kommerziell erhältlichen / Open-Source-Projekten zu vergleichen, die eine ähnliche Aufgabe erfüllen sollen (dies ist sowieso Ihre Due-Diligence-Marktforschung), und zu sehen, was sie brauchten, um das zu tun, was sie getan haben.

Wenn Sie mit Millionen von Dollar arbeiten, sollten Sie sich natürlich einiger perverser Anreize im Spiel bewusst sein. Kurz gesagt, "Ass Covering": Wenn Sie ein superkomplexes Architektursystem empfehlen, für dessen Verständnis ein Doktortitel erforderlich ist, wer ist dann schuld, wenn es zur Hölle geht? Natürlich nicht Ihre - Sie haben nur die besten hoch entwickelten Technologien vorgeschlagen, von denen jeder sagt, dass sie die besten sind -, aber sie sind "kompliziert" und "schwierig", daher liegt die Schuld bei den Leuten, die versucht haben, sie umzusetzen. Sie müssen einfach nicht klug oder geschickt genug gewesen sein ... mit anderen Worten, es werden viele Ratschläge gegeben, um sicherzustellen, dass Sie nicht schlecht aussehen, wenn Projekte scheitern, was sie zwangsläufig müssen, da nicht alle Projekte erfolgreich sind. Es ist schlechtes Juju, aber es ist eine Tatsache unserer Realität.

Nichteinhaltung

Ich würde vorschlagen, dass das Versäumnis, Tests kontinuierlich zu aktualisieren und Architekturentscheidungen zu verfolgen (Pläne zu werfen, wenn sie sich ändern, anstatt sie zu aktualisieren usw.), der Grund dafür ist, dass so viele Systeme weggeworfen und von Grund auf neu geschrieben oder durch ein neues ersetzt werden. Lösung 'ein paar Jahre später.

Wenn Dinge, die Klarheit und Konsistenz erzwingen, aus Gründen der Zweckmäßigkeit verworfen werden, ist es manchmal leicht zu glauben, dass Sie sehr schlau waren und wirklich "Dinge erledigen", wenn Sie tatsächlich zukünftige Änderungen schwieriger und komplizierter vorgenommen haben. Es ist sehr üblich, von der zukünftigen Produktivität zu stehlen, um sofortige Gewinne zu erzielen. Es ist schlecht, wenn niemand merkt, dass das passiert.

Das Testen ist zum Beispiel besonders gut geeignet, wenn sich Dinge ändern. Sie ändern die Tests, um die neue Richtung widerzuspiegeln, und reparieren dann alle Dinge, die jetzt "kaputt" sind, weil die Leute ihre Meinung geändert haben oder zu der Erkenntnis gekommen sind, dass sie beim letzten Mal etwas verpasst haben. Das ist so, als würde man das Schlafen aufgeben, weil man diese Woche noch viel zu tun hat - das wird die Sache schwieriger machen.

Fazit: "Es kommt darauf an" (hilfreich, nicht wahr?)

Die Komplexität der Architektur ist mit Gemeinkosten verbunden, beispielsweise mit der Anmietung eines größeren Raums für ein stationäres Unternehmen. Es ist nur dann sinnvoll, wenn es eine echte Komplexität gibt, die verwaltet werden muss. Wenn es sich um ein 3-köpfiges Team handelt, das an einer relativ konventionellen Lösung arbeitet, sind einfache MVC und minimale Werkzeuge wahrscheinlich völlig ausreichend.

Wenn es sich um eine komplexe Unternehmenssoftwarelösung mit mehreren Subsystemen handelt, mit einem Budget von Millionen und mindestens einem halben Dutzend Teams von 3 bis 5 Personen? Sie werden um die süße, süße Liebe betteln, die nur Round-Trip-Engineering auf objektorientierter Programmanalyse und all ihren Diagrammen und Diagrammen und Modellen geben kann. Alles, was Ihnen helfen kann, die Dutzende oder Hunderte von Augenpaaren davon abzuhalten, Sie ohne zu blinzeln anzustarren und sich zu fragen, was sie heute tun sollen und wie sie überhaupt etwas tun sollen.

Willkommen bei der Beratung.

Ein großartiger Ort, um eine Menge Geld zu verdienen und Kunden schnell Funktionen bereitzustellen.

Wenn Sie daran arbeiten möchten, wartbare, anpassungsfähige und schöne Software zu erstellen, die jetzt und in Zukunft gut funktioniert, empfehle ich Ihnen, in einer bestimmten Branche wie dem Gesundheitswesen oder der Regierung zu arbeiten, in der Sie eine bessere Nische für qualitativ hochwertige Arbeit finden können.

Was Sie von einem soliden Design profitieren, ist ein langfristig zuverlässigerer Änderungszyklus. Die Kosten sind anfangs höher, da Sie entsprechend geschulte Programmierer und ein ordnungsgemäßes Design benötigen. Ziel ist es jedoch, die Kosten für spätere Änderungen nicht außer Kontrolle zu bringen.

Ohne eine solide Architektur sind Änderungen nur am Anfang billiger. Im Laufe des Projekts werden Änderungen immer kostspieliger. Dies, kombiniert mit dem Wunsch nach billigerer Arbeit und schnellerer Iteration, könnte das Projekt zum Erliegen bringen, da Änderungen letztendlich mehr kosten, als das Unternehmen bereit ist zu zahlen, und mehr Zeit in Anspruch nehmen, als das Unternehmen warten kann. Spätere Änderungen, die ein durchschnittliches Team und eine durchschnittliche Zeit in Anspruch genommen haben könnten, erfordern stattdessen ein übermenschliches Team und eine lange Zeit, um die Jahre des Codes und des Refactors so lange durchzusehen, bis Änderungen sicher vorgenommen werden können.

Wenn der Kunde dieses Opfer versteht und bringen möchte, nehmen Sie die erforderlichen Änderungen mit der schnellsten Methode vor. Es ist jedoch unklug (und möglicherweise unehrlich), diese Kompromisse für sie einzugehen, da dieser Prozess ihre Geschäftsentscheidungen beeinflusst.

Ein Teil der Aufgabe besteht darin, alle von Ihnen aufgelisteten Abstraktionen zu verstehen und nicht nur zu fragen: "Sind diese notwendig?" aber zu verstehen, wann und warum sie notwendig sind, und herauszufinden, wie diese Muster im Rahmen der Arbeit mit der Software angewendet werden können.

Ein weiterer Teil der Arbeit besteht darin, zu verstehen, dass Kunden ihre Arbeit häufig nach dem beurteilen, was sie sehen können (die Benutzeroberfläche, die Funktionalität), und dass sie über das informiert werden sollten, was sie nicht sehen können (den Status der Codebasis).

• Lesen Sie diesen Vortrag über die Kosten für schlechtes Design im Laufe der Zeit
• Lesen Sie diesen Vortrag über stabile Produktivität
• Siehe diese SO-Antwort bezüglich des Werts von Komponententests

Kompliziert ist relativ. Als ich anfing, das Programmieren von Zeigern zu lernen, war es kompliziert, insbesondere verknüpfte Listen ("Wie kann man etwas haben, das sich selbst als Feld hat"), aber als ich mich mit dem Konzept beschäftigte, war das einfach.

Als ich anfing, funktionale Programmierung zu lernen, schien das Konzept eines Lambda komplex zu sein. Aber dann habe ich es mit der Idee eines Funktionszeigers aus C ++ in Verbindung gebracht und es war einfach. Und so weiter mit Curry und Vervollständigungen und so weiter und so fort.

Als ich anfing, TDD zu lernen, dachte ich, es sei komplex oder es füge dem Entwicklungsprozess zusätzlichen Aufwand hinzu. Jetzt habe ich nicht das Gefühl, dass mein Code vollständig ist, es sei denn, ich habe Tests, die zumindest den glücklichen Weg abdecken. Die Abhängigkeitsinjektion und die Verwendung von Schnittstellen anstelle konkreter Klassen erscheinen zunächst komplex. Sie ermöglichen es Ihnen jedoch, Ihren Code unter der Annahme zu erstellen, dass Sie die Details der Abhängigkeiten herausarbeiten und sich zuerst auf die übergeordneten Konstrukte konzentrieren.

Schauen Sie sich Clean Code und The Clean Coder von "Onkel Bob" Martin an. Der erste spricht darüber, wie man besser codiert. Der zweite spricht darüber, wie man ein besserer Programmierer sein kann. Es gibt einen Unterschied zwischen den beiden.

Um eine Analogie zu geben, lerne ich Gitarre. Ich bin in der Phase, in der ich einfache Melodien und Akkorde spielen kann. Der Übergang zwischen Akkorden und Positionen ist schwierig. Wenn ich mehr übe, kann ich diese Übergänge leichter treffen und es wird für mich zur zweiten Natur.

Ich verwende das Repository / Arbeitseinheitsmuster, damit ich ein In-Memory-Repository verwenden kann, während ich die Grundfunktionalität erstelle, und in ein "SQL Lite" - oder "Odata" -Repositor konvertieren kann, wenn ich mich der Lieferung nähere. Beachten Sie, dass ich so mehr Funktionen ausführen kann, noch bevor die endgültige Infrastruktur vorhanden ist (oder sogar entschieden wurde). Mit den Abstraktionen kann ich Mocks und Stubs einfacher erstellen, damit ich überprüfen kann, ob der Code, der von den Abstraktionen abhängt, wie erwartet funktioniert. Auch hier kann ich Funktionen von oben nach unten vervollständigen.

Ich würde sagen, es ist falsch, zuerst die Infrastruktur zu erstellen. Die einfache Tatsache ist, dass es anti-agil ist. Wenn ich einen Sprint für "Infrastruktur" verbringe, baue ich Dinge, von denen ich nicht einmal sicher bin, ob ich sie am Ende brauche, und die Benutzer müssen sich nichts ansehen, um Feedback zu geben.

Das bieten die Abstraktionen. Je mehr Sie üben, sie zu verwenden, desto mehr werden sie zur zweiten Natur, und Sie werden auf diese Diskussion zurückblicken und sich wundern, wie weit Sie sich entwickelt haben. Genau wie hoffentlich werde ich mich in ein paar Jahren fragen, wie Akkordübergänge jemals eine Herausforderung für mich waren.

Ich stimme Ihrer Aussage nicht vollständig zu, dass die Abstraktion automatisch die Komplexität erhöht. Abstraktion ist der Hauptgrund, warum man sich heutzutage nicht in Maschinencode auflösen muss.

Das Problem bei Abstraktionen ist manchmal, dass sie sich eher auf das Innenleben konzentrieren, als die Komplexität für die Endbenutzer zu verbergen. Abstraktionen sollten die Logik isolieren und die Wiederverwendbarkeit fördern. Darüber hinaus denke ich, dass das Testen eine großartige Möglichkeit ist, das architektonische Design herauszufordern. Hauptsächlich, weil Sie dadurch gezwungen sind, Ihren Code aus Benutzersicht zu betrachten.

Die Probleme, die Sie wegen Zeitmangels erwähnt haben, sind die Hauptursache für schlechtes Design. Gutes Design kommt normalerweise nicht sofort, sondern durch Iterationen und Verfeinerungen. Wie wir normalerweise Anforderungen von unseren Kunden extrahieren, erfolgt über User Stories. Auf diese Weise kann der Kunde darüber nachdenken, was und wie er das System nutzen möchte. Wenn der Architekt die Absichten des Systems kennt, können geeignete Entwurfsentscheidungen oder Abstraktionstechniken ausgewählt werden, um die Flexibilität des Systems zu erhöhen. Nicht weil sie cool oder nett sind.

Beantwortung Ihrer Fragen ...

... wäre es falsch, einem Unternehmenskunden eine supereinfache Architektur zu empfehlen, selbst um ein komplexes Problem zu lösen?

Absolut nicht.

Aus Sicht des Kunden

Wie oben erwähnt, hängt es weitgehend vom Kunden ab. Dies hängt auch von Ihrer Fähigkeit ab, genau zu beurteilen, welche Lösungen für Ihren Kunden geeignet sind. Während es immer wahrgenommene Kosten für den gewünschten Wert geben wird, ist es Ihre Aufgabe als Berater, die entsprechenden Erwartungen des Kunden festzulegen. In einigen Fällen müssen Sie diese Wahrnehmung erfüllen. In anderen Fällen liegt es in Ihrem Interesse, sie zu korrigieren. Schließlich sollten Sie der Experte für Ihren Kunden sein. Und wenn nicht, sollten Sie das Wissen haben, um dieser Experte zu werden. Dafür bezahlen sie dich.

Aus Entwicklersicht

Das Schwierigste bei der Auswahl der zu verwendenden Architektur ist häufig die korrekte Schätzung des Arbeitsaufwands, der erforderlich ist, um die Technologie zur Erfüllung der spezifischen Anforderungen einzusetzen. Dies kann sehr schnell zu Projekten führen, die die Erwartungen der Kunden nicht erfüllen. Verstehen Sie, dass einige Projekte mit diesen von Ihnen erwähnten "komplexen" Codeteilen tatsächlich schneller ausgeführt werden. Es versteht sich auch, dass einige nicht sind. Sie müssen diese Messung basierend auf dem, was Sie oder Ihr Team wissen, bereitstellen.

Ist es die Komplexität, die Unternehmenslösungen definiert, oder ist es die Zuverlässigkeit, # gleichzeitige Benutzer, Wartungsfreundlichkeit oder all das oben Genannte?

Während die Besonderheiten variieren können, ist eine Unternehmenslösung im Allgemeinen eine Softwarelösung, die für ein breites Publikum geeignet ist. Die Anzahl der gleichzeitigen Benutzer kann ein Faktor sein oder auch nicht, obwohl dies häufig der Fall ist. Die Gesamtzahl der Benutzer, häufig in verschiedenen Geschäftsrollen, ist einer der größten bestimmenden Faktoren dafür, ob es sich bei der Lösung um "Unternehmen" handelt.

Viele Unternehmenslösungen sind sehr komplex, einige jedoch recht einfach. Während Unternehmen ein Gefühl der Zuverlässigkeit vermitteln (und auf jeden Fall einen bestimmten Standard einhalten sollten), weisen unterschiedliche Lösungen unterschiedliche Zuverlässigkeitsniveaus auf.

Einfache Wartung ist etwas, das meiner Meinung nach jeder Entwickler (unabhängig oder Teammitglied) anstrebt. Es ist nicht unbedingt so einfach zu erreichen. Wichtig ist, dass es ein Wartungsverfahren gibt, das feste Richtlinien enthält, anstatt "einfach" zu sein. Denken Sie daran, dass unterschiedliche Codebasen je nach Philosophie, Methodik, (Geschäfts-) Umgebungsaktivität und Komplexität des Codes erheblich unterschiedliche Benutzerfreundlichkeit aufweisen .

Auf Ihre anderen Aussagen reagieren ...

In allen Fällen war es nie erforderlich, Code austauschbar oder wiederverwendbar zu machen

Es besteht oft nie ein spezifischer Bedarf dazu. Dies sollte jedoch immer Ihr Ziel sein. Bedenken Sie Folgendes ... Möglicherweise haben Sie einen Client, der die Möglichkeit benötigt, über die Webseite auf seinen Kalender zuzugreifen oder ihn anzuzeigen. Wenn Sie Ihren eigenen Code wiederverwendbar machen und ein anderer Client dasselbe verlangt, haben Sie bereits einen Teil der Arbeit erledigt. Wenn Sie dies nicht tun, müssen Sie alles noch einmal machen. Jedes Client-Problem ist häufig eines, das ein anderer Client in Zukunft möglicherweise benötigt. Mit anderen Worten, jeder Kunde, mit dem Sie zusammenarbeiten, sollte das Potenzial haben, die Arbeitskosten für Ihre zukünftigen Kunden zu senken (nicht unbedingt die Kosten des Produkts).

und die Tests wurden nach der ersten Iteration nie wirklich beibehalten, da sich die Anforderungen änderten, es war zu zeitaufwändig,

Ich würde hier argumentieren, dass die Testmethode nicht ausreichend abstrahiert wurde. Ich habe kürzlich einen Code verwendet, der seine eigenen Komponententests direkt in sich selbst durchgeführt hat. Es wurde ein Brauch assertund eine expectFunktion erstellt, die den Anforderungen des Projekts entsprachen. Immer wenn ein Komponententest benötigt wurde, konnte er angewendet werden, ohne den Code anzupassen. Tatsächlich wird der Code aktiv mit den Asserts verteilt und erwartet noch dort. Diese Überprüfungen wurden als Teil des Arbeitscodes durchgeführt.

... Fristen, geschäftlicher Druck usw. usw. ....

Ich habe oft festgestellt, dass zusätzlicher geschäftlicher Druck und Fristen, die den Codierungsprozess behindern, die Schuld des Entwicklers und nicht des Kunden waren. Dies ist zwar nicht immer der Fall, aber der geschäftliche Druck wird häufig durch die Wahrnehmung verursacht, dass die Erwartungen der Kunden nicht erfüllt werden. Wenn Fristen den Code behindern, liegt dies häufig daran, dass der Entwickler den für den verwendbaren Funktionscode erforderlichen Arbeitsaufwand nicht genau einschätzen konnte. Mit anderen Worten, planen Sie sie (Kunden erwarten es) , messen Sie sie (zukünftige Kunden erwarten es) , führen Sie sie aus (Benutzer verlangen es) und werden Sie dafür bezahlt (Ihr Vertrag sollte es verlangen) .

Vieles, was diese Frage stellt, ist unglaublich subjektiv. Ich denke, es ist wichtig, einige Daten über die Gesamtkosten der architektonischen Komplexität aufzurufen. Es gibt eine wirklich interessante Fallstudie von MIT Sloan, die misst

• Verringerung der Entwicklerproduktivität
• Umsatzsteigerung
• und erhöhte Defektdichte, die aus mehr Komplexität resultiert.

Grundsätzlich würde ich sagen, dass es ein fröhliches Medium gibt, das jede Codebasis zwischen (A) Einfachheit, damit die Entwicklerproduktivität hoch ist, und (B) Weitsicht streben sollte, damit die Funktionalität nicht beeinträchtigt wird, wenn neue Funktionen hinzugefügt werden.

Die Fallstudie befasste sich mit diesem einen Unternehmen mit einer monolithischen Codebasis, die einen hochkomplexen Kern (denken Sie an Dienstprogramme und Dinge mit hoher Abstraktion) und eine Peripherie mit geringerer Komplexität (denken Sie an neuere Funktionen mit wenigen Abhängigkeiten) hatte. Zwischen Peripherie und Kern sank die Entwicklerproduktivität um 50% (verrücktes Zeug) und die Defekte um das 2,6-fache.

Ich kann mich auf Ihre Zweifel in Bezug auf komplexe Softwareentwicklungstechniken beziehen und würde vermuten, dass es viele Menschen gibt, die dies aus genau den von Ihnen genannten Gründen können: Sie erhöhen den Aufwand für die anfängliche Erstellung eines neuen Systems, zeigen jedoch nicht immer sofort ihre Leistungen.

Das bedeutet natürlich nicht, dass sie nicht existieren, für jedes Konzept gibt es einen Grund, meistens einen guten. Insgesamt sollten sie den Arbeitsaufwand für die Fertigstellung eines Projekts reduzieren und anschließend verbessern.

Theoretisch natürlich, und ich wette, Sie haben all diese theoretischen Vorteile gelernt, und jetzt sehen Sie mehr denn je, dass sie scheitern. Und das mag auch einen guten Grund haben: Die Verwendung eines Konzeptrechts ist nicht so einfach wie das Verstehen, warum es verwendet wird, und obwohl Sie möglicherweise die Erfahrung haben, die erforderlich ist, um zu entscheiden, wann und wann nicht, sollten Ihre Kunden dies möglicherweise noch nicht tun.

Die Verwendung eines Konzepts an jedem möglichen Punkt in Ihrem Projekt kann Sie viel Zeit kosten (siehe Telatsyns Antwort für einen einfachen Satz dazu), und selbst die Verwendung eines Konzepts am richtigen Ort kann Sie kosten, wenn Sie nicht genug Erfahrung damit haben . Wie Sie sagten, sind dies keine einfachen Konzepte, sondern manchmal wirklich komplexe, die an Ihre Situation angepasst werden müssen. Ein theoretisches Verständnis kann nicht ausreichen, um es schnell und richtig anzuwenden.

Und aus diesen Gründen ist es keine Überraschung, wenn Ihre Kunden, ohne es wirklich zu bemerken, von den Konzepten abweichen und ihre Tests und Abstraktionen aufgeben und wieder einfach arbeiten.

In Bezug auf die große Barriere, die Software-Engineering sein kann, schlage ich Ihnen diesen Artikel vor: Die sieben Stufen des Fachwissens im Software-Engineering Ich bin irgendwo auf dieser Seite darauf gestoßen und er drückt einige wirklich interessante Gedanken und Erfahrungen aus.

Ich würde sagen, wenn Sie Anwendungen für das Unternehmen entwickeln, sollten Sie oder jemand, der für Ihre Projekte verantwortlich ist (Proj mgr), ein besseres Gefühl für den Arbeitsaufwand haben, der in die Projekte fließen sollte. Wenn Sie Zeitverschwendung sehen, sollten Sie Ihre Ansicht mit dem Projektleiter besprechen. Die Art und Weise, wie ich mich fühle und arbeite, hängt immer von der Art des Urteils ab, aber ich halte immer Ausschau nach dem Kunden, der Ihnen einen Kurvenball wirft. Ich würde mich irren, wenn ich einen guten Job mache, indem ich dein Ich punktiere und dein T kreuze. Ich würde auch sicherstellen, dass ich das richtige Management des Anwendungslebenszyklus eingerichtet habe, damit der größte Teil des Overheads automatisiert wird, so dass keine Zeit gespart wird usw. Ich hoffe, das hilft!