Pragmatische Softwareentwicklung

image.png

Stellt einem Softwareentwickler mal die Frage, ob der Code den er vor ein oder zwei Jahren geschrieben hat immer noch gut findet. Meistens ist die Antwort: Würde ich heute anders machen.

Diesen Prozess habe ich sowohl in dienstlichen Projekten als auch in Privatprojekten mehr als einmal festgestellt. In die Liste der größeren Privatprojekte gehören ShoppingMap von 2007, ReadYou von 2008, DieSachsen.de von 2009 und BizzBingo.com von 2011.

Bei jedem Projektstart geht einem daher immer wieder dasselbe durch den Kopf:

image

(Bildquelle – schaut euch auch mal die anderen Comics an, sind einige Gute dabei)

Der Weg ist nicht immer das Ziel

Man lernt recht schnell, dass es nicht den richtigen Weg gibt um Software zu entwickeln. Es gibt dutzende Programmiersprachen, Frameworks und Konzepte. D.h. es gibt zwangläufig auch mehrere Wege das Ziel zu erreichen. Man muss sich im klaren werden:

Was ist das Ziel?

Möchte man einfach nur in eine Technologie reinschauen, dann kann man bauen was man möchte. Hat man jedoch ein konkretes Ziel im Auge, sollte man sich überlegen: Was bringt mich meinem Ziel näher? Brauch ich eine 5 Schichten Architektur, mit Response/Request Gedöns und muss ich streng gläubig nach TDD vorgehen? Muss ich mein Loginsystem jetzt mit der Windows-Identity Foundation ausstatten? Oder möchte ich einfach nur ein paar ganz triviale Daten so einfach wie möglich abspeichern?

Und wie verhindert man das Chaos?

Meist kommt das Chaos zustande, weil man zu viele Sachen gleichzeitig haben will. Man hat dutzende Ideen oder dutzende Feature Requests vom Kunden und natürlich muss alles bereits von Version 1, aber mindestens ab Version 2 dabei sein. Das heißt natürlich, man muss sich für alle Eventualitäten sichern.

Meistens endet sowas in einer völlig aufgeblasenen Architektur: Kanonen auf Spatzen oder die Kanone zielt wo ganz anders hin.

Die Software in kleinen Schritten entwickeln und immer wieder prüfen ob das Gebilde immer noch “in Takt” ist hilft dem Chaos Herr zu werden.

image

(Quelle)

Meine Empfehlung:

Wenn man ein Projekt entwickelt, was irgendwann einmal etwas sinnvolles tun möchte (!= Lernprojekte zum Rumspielen), dann geht in winzigen Schritten voran. Continuous Delivery kann ein Weg sein um schnell Antworten zu bekommen. Viele der Anforderung an die Software werden sich im Projektverlauf ohnehin noch ändern. Bei anderen Sachen gilt: YAGNI.

Konzentration aufs Wesentliche:

Welchen Zweck soll die Software erfüllen und wie kann man dies am einfachsten erreichen – ganz ohne Mondraketen-Architektur. Software baut man nicht “weil man es kann”, sondern weil man ein Bedürfnis/Zweck erfüllen möchte. Den richtigen Weg das zu tun gibt es nicht und solange der Zweck erfüllt ist, ist doch alles andere auch egal.

Wenn dir der Blogpost gefallen hat, dann hinterlasse doch einen Kommentar. Wenn du auf dem Laufenden bleiben willst, abonniere unseren RSS Feed oder folge uns auf Twitter.

About the author

Written by

Hi, ich bin Robert Mühsig und bin Webentwickler und beschäftige mich mit Web-Frameworks auf dem Microsoft Web Stack und scheue mich auch nicht vor Javascript. Der Blog begann als "Problemsammelstelle und Lösungshilfe" und seitdem schreibe ich hier alles auf. Seit 2008 bin ich Microsoft MVP für ASP.NET. Treffen kann man mich online via Twitter (@robert0muehsig) oder hier.

3 Responses

  1. Hallo Robert,

    also, grundsätzlich stimme ich Dir zu, dass man leicht mal mit Kanonen auf Spatzen schießt.

    Ich habe aber auch die andere Seite erlebt: Das man einfach mal drauflos codet und auf einmal erreicht das eine Größenordnung, die nicht mehr so ohne Weiteres pflegbar ist. Jetzt müsste eigentlich mal ein konsequentes Refactoring stattfinden. Das traut sich dann aber keiner, z.B. weil es terminlich schwer zu rechtfertigen ist oder weil keine Unit-Tests da sind.

    Der Weg, den du beschreibst, erfordert viel Disziplin – nämlich rechtzeitig und kompromisslos Refactoring zu betreiben, statt das nächste spannende Feature zu entwickeln.

    Ich fühle mich inzwischen viel wohler, wenn ich auf einer fertigen Anwendungsarchitektur aufsetzen kann. Die muss man sich natürlich vorher genau anschauen, ob sie auch passt – und gegebenenfalls etwas modifizieren. Ich habe solche Architekturen für mich entwickelt und finde die recht leistungsfähig. Bei allem, was mehr als 1-2 Wochen braucht, habe ich damit sehr gute Erfahrungen gemacht.

    Viele Grüße
    Jörg

    Reply
    • Ich stimme dir völlig zu – einfach ist es nicht die Balance zu halten. Momentan probier ich quasi beides aus: Ein großes Projekt mit einem größeren Team was auch recht komplexe Anforderungen hat (vermutlich sieht jeder seine Projekte so ;) ). Oftmals kommen dabei erst Mondraketen heraus und man muss sich (und die Kollegen ;) ) zwingen manchmal ein Schritt zurück zu treten um eine einfachere Möglichkeit zu finden. “Overengineering” ist hier das Stichwort. Bei einem anderen Projekt wird wild losgebaut, allerdings sind da die Anforderungen genauso wild zusammen gekommen ;)
      Meine Lektion war jedoch bevor ich die neusten Killer-Frameworks einsetze um Feature X und Y eventuell besser umzusetzen sich erstmal überlegen was das Ziel war.

      Reply
  2. Hallo,

    ich finde es sehr vernünftig für einen pragmatischen Ansatz zu plädieren. Von allem sollte man soviel nehmen, wie man braucht. Die Architekturansätze “teile und herrsche” und “so einfach wie möglich” dürfen nicht vergessen werden. Die beste Kontrolle eines solchen Ansatzes ist eine offene Fehlerkultur in einem Team, welches achtungsvoll miteinander kommuniziert und somit eine schnellere Korrektur hinbekommt als Einzelkämpfer. Deshalb vertrete ich auch in meinem Blog (http://easyrequirement.blogspot.de/) einen ganz andere Teamansatz und trotzdem die Forderung nach systematischer Softwareentwicklung. Aber eben immer pragmatisch!

    Viele Grüße Ralf

    Reply

Comment on this post

Letzte Posts

  • image.png
    Source Code veröffentlichen – aber bitte mit Lizenz

    Seit es den Blog gibt wird auch meist der gesamte Demo Source Code mit veröffentlicht. Das Ganze hatte ich am Anfang noch als .zip verteilt, später lag es mal auf Google Code und nun liegen alle Samples und sonstige Sachen auf GitHub. Beim letzten User Group Treffen in Zürich mit dem Titel “Open Source: Get […]

  • Fix: Cannot convert from ‘CConnectProxy::_ComMapClass *’ to ‘AddInDesignerObjects::IDTExtensibility2 *’

    Mal einen etwas esoterischer Blogpost, welcher auftaucht wenn man zu viel mit Office Addins rumspielt. Der Fehler passiert beim Bauen von C++ Projekten, welchen diesen Typ benötigen. Lösung (auf 64bit Systemen): C:\Program Files (x86)\Common Files\DESIGNER>regsvr32 MSADDNDR.DLL And Rebuild. Meine lieben Kollegen hatte mir dies schon mehrfach gesagt, allerdings hatte ich es immer wieder vergessen Das […]

  • Gegen das Gesetz verstoßen: X Jahre Haft. Gegen die Terms of Use verstoßen: Bann auf Lebenszeit. Danke Google & co.

    Bei fast allen Diensten die man im Internet nutzen kann muss man den “Terms of use” zustimmen. Völlig logisch dass da natürlich drin steht was erlaubt und was nicht. Wenn man gegen diese Regelungen verstößt hat das Unternehmen natürlich das Recht etwas dagegen zu unternehmen. In der heutigen Welt beherrschen einige wenige Unternehmen die digitale […]

  • image.png
    RSS Feed samt Kommentaranzahl und andere nicht Standard Elemente mit dem SyndicationFeed auslesen

    Jetzt mal ein Blogpost ohne ein fancy NuGet Package: Seit .NET 3.5 gibt es die SyndicationFeed Klasse. Eine schon etwas ältere API, reicht aber aus um Atom bzw. RSS Feeds zu lesen. In diversen RSS Feeds gibt es aber Erweiterungen, welche man natürlich auch auslesen möchte. So gibt WordPress z.B. auch die Anzahl der geposteten […]

  • image.png
    ASP.NET Bundling & Fontawesome

    Vor einer halben Ewigkeit hatte ich mal geschrieben wie man Fontawesome in ASP.NET nutzen kann. Aufgrund des Alters des Post und einem Kommentar ob man denn Fontawesome auch in das ASP.NET Bundling Framework integrieren kann möchte ich nur ein kurzes Update schreiben. TL;DR: NuGet Package “Fontawesome” runterladen und Pfad in der Bundleconfig angeben. Kurze Schritte […]

Amazon Shop

Facebook