Unabh\u00e4ngig davon, aus welcher Sicht man es betrachtet, haben Entwickler von Gesch\u00e4ftsanwendungssoftware im Allgemeinen einen schlechten Ruf. Systeme werden fast zwangsl\u00e4ufig versp\u00e4tet oder gar nicht geliefert. Der durchschnittliche Benutzer in einem durchschnittlichen Unternehmen verbringt jede Woche buchst\u00e4blich Stunden damit, \u00fcber die Computersysteme zu meckern, denen er ausgesetzt ist. \u201eWarum wurde das getan?\u201c \u201eWas zum Teufel bedeutet das?\u201c sind einige der Dinge, die ich t\u00e4glich h\u00f6re. <\/p>\n\n\n\n\n\n\n\n
\n\t\tIch habe Jahre damit verbracht, Gesch\u00e4ftssysteme zu schreiben, und die meisten Benutzer waren positiv \u00fcber das, was sie bekamen und nutzten. Systeme, die nach einer anf\u00e4nglichen Spezifikation geschrieben, auf Herz und Nieren getestet und dann bei Bedarf und bei Bedarf zu einem vereinbarten Preis angepasst werden. Kontinuierlicher Support f\u00fcr den Kunden und nachhaltige Einnahmen f\u00fcr das Softwareunternehmen waren eine gewinnbringende Kombination. Die anf\u00e4ngliche Spezifikation, die auf einer detaillierten Anforderungsanalyse basiert, w\u00e4re immer eine Funktions\u00fcbersicht und w\u00fcrde keine Code-Spezifika enthalten. Ich glaube, ich habe einmal Pseudocode verwendet (als ich Spiele geschrieben habe). \u201eDas ist es, wof\u00fcr wir es brauchen\u201c war f\u00fcr mich normalerweise gut genug. Abgesehen davon waren es noch ein paar Benutzeroberfl\u00e4chen-Mock-ups und viel Datenbankdesign und schon ging es los. Die Test- und Optimierungsphase des Entwicklungslebenszyklus war von entscheidender Bedeutung. Die Systeme wurden im Allgemeinen p\u00fcnktlich geliefert und funktionierten.\n\t\t<\/p>\n\n\n\n
\n\t\tHeutzutage (ich h\u00e4tte nie gedacht, dass ich das jemals sagen w\u00fcrde) geht es bei allem, was mit Systemen zu tun hat, um Planung, noch mehr um Planung und dann um Wiederverwendbarkeit. Was mir so fremd vorkommt, ist, dass ein Gro\u00dfteil dieser Planung nicht darauf abzielt, eine funktionale Anforderung zu erf\u00fcllen, sondern vielmehr detailliert darzulegen, wie und warum wir schreiben werden, was wir schreiben, wenn wir es schreiben. Hoffe das macht Sinn? Warum etwas in 10 Zeilen schreiben, das man in 1000 Zeilen schaffen k\u00f6nnte, wenn es die M\u00f6glichkeit gibt, dass man es zwei Jahre sp\u00e4ter \u201evielleicht\u201c wiederverwenden muss? Pers\u00f6nlich habe ich noch nie etwas geschrieben, das ich zwei Jahre sp\u00e4ter nicht besser umschreiben k\u00f6nnte. Ich lerne st\u00e4ndig dazu und verbessere mich. Wenn ich auf Code zur\u00fcckblicke, der selbst 12 Monate alt ist, zucke ich oft zusammen. Wenn man sich Stellenanzeigen ansieht, kann man sich leicht in den Methoden und F\u00e4higkeiten verlieren, nach denen gefragt wird. Ist es menschlich m\u00f6glich, dass eine Person so viel wei\u00df, frage ich mich oft? Eine andere Frage ist, ob sie jemals ein Produkt produzieren. Wird bei all dieser Planung und Sorge um die Wiederverwendung von Code jemals etwas erledigt? Ich kenne ein Unternehmen, das akademische Entwickler eingestellt hat, die sich so sehr auf das Design konzentrierten, dass das Unternehmen unterging, bevor \u00fcberhaupt ein Produkt fertig war, im Ernst! Wie viele Verz\u00f6gerungen k\u00f6nnen wir von den Leuten erwarten, die Testphase war dort nie ein Problem! Warum sollte von dem Unternehmen, das uns f\u00fcr ein Produkt bezahlt, erwartet werden, dass es f\u00fcr Code bezahlt, der in sp\u00e4teren Projekten immer wieder verwendet wird, nicht f\u00fcr das Unternehmen?\n\t\t<\/p>\n\n\n\n
\n\t\tVerstehen Sie mich nicht falsch, ich sage nicht, dass Planung schlecht ist, sie ist ein wesentlicher Teil der Systementwicklung, aber nicht der einzige. Vielleicht bin ich altmodisch, aber der Teil, der mir Spa\u00df macht, besteht darin, das System tats\u00e4chlich zu schreiben und daf\u00fcr zu sorgen, dass es funktioniert. Ok, ich wei\u00df, dass Systeme immer gr\u00f6\u00dfer und komplexer werden. Gro\u00dfe Entwicklerteams sind die Norm. Ich denke nur, dass, egal wie viel man plant, visualisiert und Brainstorming betreibt, immer etwas \u00fcbersehen wird. Wir streben nach dem Unm\u00f6glichen, nach perfekten Systemen, aber im schlimmsten Fall liefern wir tats\u00e4chlich kein System. Glauben Sie mir nicht? Schauen Sie sich Microsoft an. Stellen Sie sich vor, wie viele Arbeitsstunden in die Planung ihrer Anwendungen flie\u00dfen? Wie oft wird ein neuer Fehler oder eine neue Schwachstelle entdeckt? Warum wurden diese nicht bereits in der Entwurfsphase ausgearbeitet? Dem Entwicklungsteam kam es nie in den Sinn, dass \u201eSchwachstelle X\u201c \u00fcberhaupt auftreten k\u00f6nnte. Einfach ausgedr\u00fcckt ist es mit mehr als den einfachsten Systemen fast unm\u00f6glich, f\u00fcr alle Eventualit\u00e4ten zu planen, egal wie logisch Sie sind. Wie kommt es, dass sie beim Testen nicht gefunden werden? Liegt hier die L\u00f6sung in der Old-School-Entwicklung, weniger Zeit f\u00fcr Planung (Reden), mehr Zeit f\u00fcr Schreiben und Testen? Weniger Zeit damit, sich Gedanken \u00fcber die Wiederverwendung von Code zu machen, mehr Zeit damit, dem Kunden ein funktionierendes Produkt zu bieten? W\u00e4re es f\u00fcr Microsoft besser oder schlechter, wenn sie weniger Zeit f\u00fcr die Planung und mehr Zeit f\u00fcr Tests aufwenden w\u00fcrden? Zur Verteidigung von Microsoft muss man sagen, dass sie sehr gut im Patchen sind. Ich nehme an, man k\u00f6nnte sagen, dass sie uns als Tester eingesetzt haben. Nur wenn sie mehr Zeit damit verbringen w\u00fcrden, ordnungsgem\u00e4\u00dfe Tests durchzuf\u00fchren, m\u00fcssten wir vielleicht keine Tests f\u00fcr sie durchf\u00fchren?\n\t\t<\/p>\n\n\n\n
\n\t\tDas schlimmste Beispiel f\u00fcr \u00dcberplanung, das mir bisher begegnet ist, ist ein Finanzsystem, das ich t\u00e4glich nutze. Die Implementierung dieses Systems hat Millionen Dollar gekostet, jahrelange Planung und wer wei\u00df wie viele Berater. Es wurde von einem der gr\u00f6\u00dften Player der Softwarebranche geschrieben und von einer spezialisierten Softwareberatung angepasst. Das Endergebnis ist ein System, das praktisch unbrauchbar ist und nicht mehr weit davon entfernt ist, durch ein Standardprodukt ersetzt zu werden. Auf der niedrigsten Ebene ist es so schlimm, dass selbst ein falsch platzierter Mausklick die Anwendung zum Absturz bringt. Ich kann nicht glauben, dass dieses System vor der \u00dcbergabe jemals getestet wurde. Die Lieferung erfolgte bereits sehr sp\u00e4t, der Grund daf\u00fcr war ein l\u00e4nger als erwarteter \u201ePlanungszyklus\u201c. Was es tut, ist nicht so komplex, es ist nur offensichtlich so weit geplant, dass die Umsetzung nur noch in Eile erfolgt. All diese Planungen haben nicht einmal zu einem System gef\u00fchrt, das die grundlegenden Funktionsanforderungen seiner Benutzer erf\u00fcllen w\u00fcrde, aber heh, ich bin mir sicher, dass sie diesen Code irgendwann sp\u00e4ter wiederverwenden werden.\n\t\t<\/p>\n\n\n\n
\n\t\tWie auch immer, ich habe gerade mit einem Diplom begonnen, um zu verstehen, warum die Verwendung verschiedener Planungsstrategien so wichtig ist. Warum an einem Tag schreiben, was ich einen Monat lang \u201erichtig\u201c tun k\u00f6nnte? Ich wei\u00df, dass ich das in ein paar Jahren noch einmal lesen werde und mich fragen werde, was ich gedacht habe; Entweder das, oder ich sage mir: \u201eWow, da war ich tats\u00e4chlich fertig mit dem, was ich geschrieben habe.\u201c Aber im Ernst, ich bin mir sicher, dass ich am Ende erkennen werde, wo ich falsch liege. In der Zwischenzeit schreibe ich einfach weiterhin Bewerbungen in meinem RAD-Stil (ich bin froh, dass er einen Namen hat!). Obwohl es nicht jedermanns Geschmack ist, funktioniert es f\u00fcr mich ganz gut. \n\t\t
<\/p>\n\n\n\n