Für viele IT-Mitarbeiter, einschließlich meiner selbst, bestand der ideale Softwareentwicklungsprozess vor einigen Jahren darin, detaillierte Designdokumente mit vielen UML-Diagrammen zu erstellen, bevor eine Codezeile geschrieben wird. (Dies sieht aus wie eine Beschreibung des Wasserfallmodells, ist jedoch bei Agile gleich, mit der Ausnahme, dass die Iterationen kleiner sind.)
In den letzten zwei oder drei Jahren habe ich meine Meinung völlig geändert. Eine detaillierte Anforderungsspezifikation mit den dazugehörigen Testfällen halte ich nach wie vor für unabdingbar. Bei großen Projekten würde ich auch einen Überblick über die Gesamtarchitektur benötigen, bevor ich mit dem Code beginnen kann. Der Rest sollte jedoch so weit wie möglich im Code erfolgen. Im Idealfall sollte es außer dem Code selbst keine Beschreibung des Software-Designs geben.
Wie bin ich zu diesem Schluss gekommen? Hier sind einige Argumente:
Feedback
Tools zum Schreiben von Dokumenten oder Erstellen von Diagrammen geben nur wenig Rückmeldung. Ja, es gibt Modellierungswerkzeuge, die einige Konsistenzprüfungen an UML-Diagrammen durchführen, diese sind jedoch begrenzt und mit viel Aufwand verbunden.
Ohne Feedback ist es schwer, Fehler zu erkennen und zu beheben.
Sobald Sie Code schreiben, erhalten Sie viele Rückmeldungen, zum Beispiel:
- Fehler und Warnungen vom Compiler
- Statische Code-Analyseergebnisse
- Unit-Tests
Fehler können schnell erkannt und behoben werden.
Konsistenz
Um sicherzustellen, dass der Code mit Ihren Dokumenten übereinstimmt, müssen Sie immer wieder überprüfen. Bei häufigen Änderungen ist es schwierig, Code und Dokumente synchron zu halten.
Refactoring
Es gibt leistungsstarke Tools und Techniken zum Refactoring von Code, während das Refactoring von Textbeschreibungen oder Diagrammen in der Regel schwierig und fehleranfällig ist.
Voraussetzung dafür ist, dass der Code leicht zu lesen und zu verstehen ist. Dies kann mit Assembler, Basic oder Fortran wahrscheinlich nicht erreicht werden, aber moderne Sprachen (und Bibliotheken) sind viel ausdrucksvoller.
Wenn meine Argumente stimmen, sollte es einen Trend zu weniger oder leichteren Software-Designspezifikationen und Dokumentationen geben. Gibt es empirische Belege für diesen Trend?
quelle
Antworten:
Ich bezweifle, dass Sprachen immer ausdrucksvoller werden. Mit dem heutigen ASP.NET-Code in c # schreibe ich ungefähr auf der gleichen Ebene wie beim Schreiben von ASP-Code in Visual Basic. Wir verwenden immer noch C ++. Javascript hat Funktionen hinzugefügt, aber insgesamt hat sich die Sprache nicht geändert. Gleiches gilt für SQL.
Ich denke, diese anderen Änderungen sind bedeutsamer:
Annahme automatisierter Unit-Tests. Einige würden sagen , dass die Tests sind die Spezifikation. Daher haben wir die Notwendigkeit, Spezifikationen zu schreiben, nicht beseitigt. Wir schreiben sie eher in Code als in Word-Dokumenten.
Änderungen in der Bereitstellungsmethode. In der Vergangenheit war es sehr teuer, einen Fehler zu machen, da Sie eine aktualisierte Kopie Ihrer Software ausliefern mussten. Also musste man vorsichtig sein. Mit webbasierten Anwendungen können Sie Fixes für die sofortige Verwendung bereitstellen und es sich leisten, auf Probleme zu reagieren, anstatt sie vorherzusehen, und den Code bei Bedarf neu strukturieren.
Übernahme von Entwurfsmustern. Wenn jeder die Muster kennt, muss man kaum etwas entwerfen; Sie können einfach "Repository-Factory hinzufügen" sagen und Ihr Team sollte dies tun, ohne UML sehen zu müssen.
SOA Datenverträge. In diesen Tagen ist so ziemlich alles SOA. Alles was Sie brauchen ist eine WSDL. Die Zeiten, in denen Datenübertragungsformate definiert und dokumentiert wurden, sind vorbei. Der derzeitige Trend zu mehr RESTful- und Mikrodiensten setzt diesen Trend fort.
Software sind kleiner. Teilweise aufgrund von SOA-Architekturen schreiben Teams kleinere Programme, die miteinander verbunden sind. Jede einzelne Komponente ist weniger komplex und erfordert weniger Design im Voraus. Außerdem ist es einfacher, einen Teil der Architektur zu ändern, ohne die Gesamtlösung zu beschädigen, da die Schnittstellendefinitionen zwischen den Komponenten zu Brandbrüchen führen.
Viel, viel mehr Gebrauch von etablierten Bibliotheken. Die .NET CLR bietet eine Vielzahl von Funktionen von der Stange, sodass beispielsweise kein Schema zum Zwischenspeichern von Sitzungsdaten entworfen werden muss. Bibliotheken von Drittanbietern wie jQuery UI oder Bootstrap legen Standards für das Schreiben von Code fest, damit diese auf bestimmte Weise funktionieren. Sie müssen diese nicht dokumentieren. Teams sollten sie nur benutzen können.
Branchenreife. SWEs haben erfahren, dass es kein "Battlestar Galactica" -Projekt gibt, bei dem Sie jahrelang versuchen, ein bestimmtes Ziel zu erreichen. Bis diese Jahre vergangen sind, wird sich das Ziel geändert haben. Heute wissen wir, dass Time-to-Market viel wichtiger ist, als alles genau so zu machen, wie wir es im Design wollen.
Besser und beständiger ausgebildete Ingenieure. In diesen Tagen können Sie Ingenieure einstellen, die (hoffentlich) Best Practices verstehen und diese einfach implementieren, ohne dass ein Designdokument vorschreibt, was zu tun ist.
Mit Produktivitätswerkzeugen wie TFS können Sie eine einfache Aufgabe schreiben, die auf einen Anwendungsfall verweist und Aufzählungspunkte für mehrdeutige technische Entscheidungen enthält. Du brauchst nicht viel mehr. Entwickler können alles über das Tool überprüfen, einschätzen, Code-Überprüfungen abrufen, einchecken usw. Dies ist wesentlich effizienter als das Arbeiten mit externen Dokumenten, da hierdurch alles miteinander verbunden wird.
Für einige Dinge benötigen Sie noch Designdokumente. Wenn Ihre Anwendung beispielsweise in verschiedene Komponenten aufgeteilt ist, die von verschiedenen Teams entwickelt wurden, müssen Sie ihnen zumindest mitteilen, welche Komponente für welche Anforderungen verantwortlich ist. Die heutigen Entwicklungsmethoden bieten jedoch größtenteils viel mehr Freiheit und bieten gleichzeitig Tools zur Verwaltung und Eindämmung des Risikos, das sich aus einer schlechten Entscheidung eines Entwicklers ergibt.
quelle
Ich würde für Nein streiten .
Aus einfachem Grund
Wurde nie als "ideal" angesehen, da es Extreme Programming seit den 1990er Jahren gibt . Und wie du sagst:
Wurde vor Ewigkeiten gestritten. Zum Beispiel dieses legendäre Artikel von 1992: Was ist Software Design .
Das Obige zeigt, dass Sie einen "extremen" Prozess mit einer hochentwickelten Architektur und einem iterativen Ansatz haben können, ohne komplexe Sprachen oder IDEs zu benötigen.
Stattdessen würde ich sagen, dass diese "scheinbare" Verlagerung von Design-Up-Front mit vielen Diagrammen und Use-Case-Dokumenten zu einem evolutionäreren und iterativeren Ansatz einfach bedeutet, dass Manager der "alten Schule" durch neue ersetzt werden, die in viel mehr Jahren aufgewachsen sind dynamisches Umfeld und für wen ist es viel einfacher zu akzeptieren und in einem "agileren" Umfeld zu arbeiten.
quelle
Ich bin damit einverstanden, aber ich denke, es hat viel früher begonnen, als Sie vermuten. Ich denke auch, dass es neben der Ausdruckskraft noch einen weiteren wichtigen Faktor gibt. Als mein Vater anfing zu programmieren, musste er Lochkarten erstellen und die Zeit auf dem Computer einplanen. Möglicherweise erhalten Sie eine Chance pro Tag, Ihr Programm auszuführen. Es blieb nicht viel Zeit, um Bauvorschriften zu verschwenden, sie fehlschlagen zu lassen und sie dann zu reparieren. Du hast vielleicht 2 oder 3 Schüsse drauf und wenn es nicht funktioniert hat, warst du in Schwierigkeiten.
Aufgrund des Risikos war es wichtig, viel zusätzliche Zeit für die Planung Ihres Programms aufzuwenden. Die Leute schrieben ihren Code mit Bleistift aus und übertrugen ihn dann auf die Lochkarten. Mit fortschreitender Technologie konnten Sie Code direkt in das Terminal eingeben, verwendeten jedoch weiterhin gemeinsam genutzte Ressourcen und die CPU war teuer. Eine Test-First-Methodik wäre in dieser Welt völlig unhaltbar. Wenn Sie nicht im Voraus planen, sitzen Ihre Kollegen mit Heugabeln an Ihrem Schreibtisch.
Computerressourcen sind in einem unglaublichen Tempo billiger und besser geworden. Viele der Zwänge, unter denen all diese Praktiken entwickelt wurden, sind vollständig beseitigt. Wie Euphoric hervorhebt, begann der Umzug in diese Richtung in den 90er Jahren. Die Fortsetzung eines Großteils des großen Frontdesigns war reine Trägheit.
Ja, die verbesserte Ausdruckskraft von Programmiersprachen hat sich darauf ausgewirkt, da es einfacher ist, ausdrucksstarken Code als eigene Dokumentation zu verwenden. Die Kosten für die Erstellung eines Dokuments, aus dem hervorgeht, was der Code sagt, sind sehr hoch und von großem Wert (was auf einer bestimmten Ebene unvermeidlich falsch ist). Gleichzeitig sind die Kosten für das Werfen von Scheiße an die Wand und das Erkennen von Sticks im Grunde vernachlässigbar.
quelle
Ich denke, Sie vergessen den Zweck, überhaupt Design-Dokumente zu haben!
Mit den Designdokumenten (Anforderungen, Anwendungsfälle, Modelle usw.) können wir das System auf hohem Niveau beschreiben, verstehen und diskutieren. Die Menge an Details , die in solchen Dokumenten fehlen, macht sie nützlich.
Es sind keine Dokumente erforderlich, die das genaue Verhalten des Systems in allen Einzelheiten beschreiben, da der Quellcode selbst diesem Zweck dient.
Die Softwareentwicklung könnte als der Prozess betrachtet werden, bei dem von Menschen lesbare Spezifikationen auf hoher Ebene in eindeutige Spezifikationen auf niedriger Ebene umgewandelt werden, die von einer Maschine ausgeführt werden können. Sie benötigen jedoch Eingaben für diesen Prozess.
quelle
Das ist weiter weg, als Sie vermuten. Sogar Dinge wie abhängige Typen (die, wie ich es verstehe, theoretisch ziemlich vielversprechend sind) sind mehrere Jahre vergangen.
Die formale Verifizierung ist recht schwierig, und aus diesem Grund werden Kryptografiebibliotheken häufig nur für die formale Verifizierung verwendet.
Wenn das Testen von Eigenschaften noch nicht den Mainstream erreicht hat, wird dies meines Erachtens noch lange nicht praktikabel sein.
Darüber hinaus ist es ziemlich schwierig, gute Tests zu schreiben (die nicht mit jedem Refactor bearbeitet werden müssen, aber dennoch genügend Fehler auffangen).
Möglicherweise ist es im Moment einfacher, ein Tool zum Testen der Dokumentation zu verwenden.
Leider ist es schwierig, Sprachen zu entwerfen, die nicht nur extrem ausdrucksstark, sondern auch hervorragend lesbar sind. Sprachen wie Go priorisieren die Lesbarkeit und behindern das Denken auf höherer Ebene.
Schließlich führen nach meiner Erfahrung bessere Sprachen und Tools nicht zu einer Software mit weniger Fehlern, sondern zu größeren Projekten. Es gibt eigentlich keinen plausiblen Weg
pandoc, der 1970 geschrieben worden wäre.quelle