Quelle der Schwierigkeit bei Software-Entwicklung
-
leider nicht eloquent schrieb:
Was ich meine ist, dass selbst Tools, die ein relativ simples Ziel verfolgen, wie git, eine enorme Komplexität aufweisen.
Wenn du schon von Komplexität redest... Diese Tools sind meist so komplex, weil die Problematik entsprechend komplex ist und es viele unterschiedliche Anforderungen gibt. Und mit der eigenen Software ist es noch schlimmer, außer man schreibt irgendwelche trivialen Projekte. Die Tools musst du meistens wenigstens nicht in ihrem vollen Umfang verstehen und hast da viel weniger Verantwortung.
Bei uns kommen die meisten Probleme wohl daher, dass die Software sehr komplex und sehr umfangreich ist, und auch nicht wirklich gut dokumentiert. Dutzende Entwickler, die über Jahrzehnte was gemacht haben, hunderte Kunden mit unterschiedlichen Anforderungen. Man fängt an etwas umzubauen oder anzupassen und merkt dann (hoffentlich), dass noch zig Sachen dranhängen, an die man überhaupt nicht gedacht hat. Im einfachsten Fall kostet das dann einfach mehr Zeit. Teilweise ist es aber so, dass auch Jahre später noch irgendwas auffällt, was man nicht berücksichtigt hatte.
Oft ist es so, dass man irgendwelche grundlegenden Basisfunktionalitäten hat, die noch alle kennen. Auf denen bauen tausende von Features und Projekten auf, die nur noch die einzelnen Entwickler kennen, wenn überhaupt. Ich kann mich auch nicht an jedes Feature erinnern, das ich in den letzten fünf Jahren implementiert habe. Dann erweitert man die Basisfunktionalitäten, macht es komplexer/flexibler, weil Anforderungen dazukommen. Läuft eine Weile, ohne dass man alles andere angepasst hat. Jahre später haben sich Kunden, Consultants usw. an die neuen Möglichkeiten gewöhnt, und plötzlich ist es keine Erweiterung mehr, sondern ein Bug, dass irgendein Randfeature, das vor zehn Jahren von einem Praktikanten entwickelt wurde, nicht alle Möglichkeiten des Datenmodells unterstützt.
Ich finde das was wir machen um Größenordnungen komplexer, als irgendwelche Tools drum herum.
-
leider nicht eloquent schrieb:
Ich würde Vieles dafür geben, von morgens bis abends nur Code scheiben zu dürfen, ohne mich durch diesen Urwald an Komplexität kämpfen zu müssen.
Warum programmierst Du dann C++? Es gibt unzählige Sprachen, bei denen Du nichts über Compiler, Linker Errors oder Makefiles wissen mußt. C++ ist nunmal eine komplexe Angelegenheit, sowohl was Sprachumfang als auch was Build Tools angeht.
Außerdem ist C/C++ kein Kinderspiel. Jedenfalls möchte ich nicht die Programme von jemandem debuggen müssen, der so etwas glaubt.
-
Ich sehe das Problem in den sich ständig ändernden Anforderungen.
Einen Tag will der Kunde das, am nächsten Tag dies, Feature A soll plötzlich auch Feature B können etc. Aus dem Grund entwickelt ja auch praktisch jeder agil.Raus kommt entweder Code, der einfach overengineert ist, um thoeretisch alles zu können - der ist einfach schwer zu verstehen und komplex. Oder die Sachen werden einfach reingehackt und nur im Notfall refactort, dann wird der Code buggy, unschön und unübersichtlich.
Gutes OOP-Design hilft natürlich, können aber bei weitem nicht alle. Das Niveau hier am Forum ist einfach deutlich höher als das, das man in der echten Welt antrifft.Bei konkreten und sich nicht ändernden Anforderungen ist Software Engineering ein Kinderspiel.
-
Ethon schrieb:
Raus kommt entweder Code, der einfach overengineert ist, um thoeretisch alles zu können - der ist einfach schwer zu verstehen und komplex.
Wobei die Gefahr von Overengineering ja meist VOR der Änderung des Features passiert, um auf alle Eventualitäten vorbereitet zu sein (und dann feststellt das dort doch keine Änderung kommt, oder der Kunde einen Wunsch hat der sich gerade damit nicht leicht einbauen lässt.
Ethon schrieb:
Oder die Sachen werden einfach reingehackt und nur im Notfall refactort, dann wird der Code buggy, unschön und unübersichtlich.
Buggy Code kannst du auch mit Overengineering erreichen, in der Praxis habe ich letzteren in vielen Fällen erlebt wenn mindestens einer der nachfolgenden Punkte (teilweise alle) erfüllt sind:
a) Man Altcode tunlichst nicht anfassen darf (Solche Firmen lehnen auch jedwede Form von Refactoring ab)
b) Man immer im Zeitdruck arbeitet (mit immer meine ich immer, nicht nur in Stoßzeiten - Kleine Anektode am Rande: Als in meiner Aktuellen Firma das erste mal aus Sicht meines Chefs das ganze stressig wurde und er sich dafür entschuldigt hat, meinte ich nur ganz trocken dass das was er als Stress nennt, in der vorherigen Firma die "Ruhephasen" waren).
c) Man die Auswahl hat ein riesiges Altprojekt von grundauf zu refactorieren, da es schon lange nicht mehr verständlich ist oder die Auswahl hat zu hoffen das der Code schon an der richtigen Stelle ist. Diese Situation sollte im Idealfall in einem Projekt zwar nicht auftreten (wenn den ernsthaft Refactoring betrieben wird, in der Praxis ist das leider nicht immer der Fall - vor allem wenn die Tools dies auch nicht unterstützen - <ironie>Kann jemand mal Embacadero in die Luft sprengen?</ironie>).Ethon schrieb:
Gutes OOP-Design hilft natürlich, können aber bei weitem nicht alle. Das Niveau hier am Forum ist einfach deutlich höher als das, das man in der echten Welt antrifft.
Ebenso hilft, wenn die Kollegen vom Niveau entweder ungefähr gleich sind oder aktiv daran gearbeitet wird die schwächeren entsprechend aufzuwerten. Ebenso sollten Entwickler nicht absolute Individualisten sein und nicht jeder einen komplett anderen Codestil pflegen - Ich kenne das Problem wie es ist wenn jeder anders programmiert zu genüge.
Ethon schrieb:
Bei konkreten
..., möglichst vollständig definierten, klar verständlichen...
Ethon schrieb:
und sich nicht ändernden Anforderungen ist Software Engineering ein Kinderspiel.
... Sofern sich die Entwickler einigermaßen einig sind (s.o.). Sprich zumindest ungefähr gleichen Codestil einhalten (oder sich zumindest nur in den Teilen wesentlich unterscheiden, die Tools teilweise auffangen können - z.B. unterschiedliche Einrückungen).
-
Ethon schrieb:
Gutes OOP-Design hilft natürlich, können aber bei weitem nicht alle.
... und ist kein Allheilmittel, wenn sich die Spezifikation rapide ändert. Schließlich schaffen Data members zeitabhängigen Zustand und Verantwortlichkeit, beides Hemmnisse beim freizügigen Refactoring.
Wenn man wenig darüber weiß, welche Funktionen in Zukunft Zugriff auf welche Informationen benötigen, kann es flexibler sein, eine Information nicht zum Data member eines Objekts zu machen (i.e. auf die Vorteile der Kapselung zu verzichten), und die zugehörigen Funktionen nicht zu Methoden einer Klasse zu machen, sondern die Information klassisch (als struct oä) zu speichern und die Methoden zu ihrer Verarbeitung als freie Funktionen. Wenn man die Zukunft nicht kennt, muß man abwägen - Flexibilität bei Zugriff und Verantwortlichkeit vs Kapselung und entsprechend wählt man einen eher funktionalen, prozeduralen oder objektorientierten Ansatz. Zum Glück hat man in C++ alle 3 und kann sie mischen, sodaß man nicht von Anfang an auf eine Methodik festgelegt ist.
Ethon schrieb:
Bei konkreten und sich nicht ändernden Anforderungen ist Software Engineering ein Kinderspiel.
Ok. Auf geht's: Schreiben Sie ein Programm, das eine 1 (eine 0) ausgibt, wenn die Riemannsche Vermutung richtig (falsch) ist.
-
Mich wundert es, dass noch niemand "schwere probleme in der Informatik" aufgeführt hat. (zumindest soweit ich beim rüberfliegen sehen konnte).
Ich finde nicht alles trivial... vor allem wenn wirklich heftige Mathematik im Spiel ist.Was mich meistens nervt ist der grottige Debugger, der nur triviales gebacken kriegt. (gdb) vllt liegts auch an der IDE Integration... (debuggt jemand vom terminal aus?)
-
ja, ich. Aber ich brauche den gdb kaum öfter als 2-mal im Jahr, weil ich mit Hilfe von Vor- und Nachbedingungen und Invarianten so entwickle, daß mein Code in der Regel von Anfang an korrekt läuft.
-
zufallswert schrieb:
Ethon schrieb:
Bei konkreten und sich nicht ändernden Anforderungen ist Software Engineering ein Kinderspiel.
Ok. Auf geht's: Schreiben Sie ein Programm, das eine 1 (eine 0) ausgibt, wenn die Riemannsche Vermutung richtig (falsch) ist.
Das ist ja eher ein mathematisches Problem.
Ich meinte das eher so: Wenn die Anforderungen alle in Stein gemeißelt sind, dann setzt man ein paar Software-Architekten für ein paar Monate an einen Tisch, lässt sie UML malen, generiert aus dem Model alle Klassen/Methoden/Datenmember und die Codemonkeys füllen die Stubs aus.
Ist natürlich in 99,9% der Fälle nicht praxistauglich.
-
und wer garantiert, daß die vorgegebene Spezifikation vollständig und widerspruchsfrei ist? Wenn eine Lücke oder ein Widerspruch erst spät, tief in der Implementationsphase, gefunden wird, können die notwendigen Änderungen teuer werden.
-
ich würde das jetzt gar nicht so theoretisch sehen.
Wenn ich mich so umsehe, was die letzten Jahre im Arbeitsleben am meisten Probleme gemacht hat:
1. alter Code, der gewartet werden muss, wofür aber weder Entwickler/Doku/Testfälle vorhanden sind
2. die Programmiersprache an sich:
a. Man glaubt es kaum, aber es gibt genug Programmierer da draussen die zwar C++ entwickeln aber nicht wirklich viel Plan davon haben.
b. teilweise (vor allem bei älteren) Compilern gibts tatsächlich auch Abweichung vom Standardverhalten - hier muss man dann tüfteln, dass das richtige Verhalten sowohl am alten als auch am neuen Compiler passt
3. sich ändernde Anforderungen: die Software wird für die Anforderungen der ersten paar Kunden geschrieben, nachträglich den Code so zu ändern, dass er bei den alten Kunden wie gehabt weiter funktioniert, allerdings für die neuen Kunden dies und jenes noch zusätzlich kann, ist oft auch nicht so einfach. Und für jede Kleinigkeit ein INI Setting hinzuzufügen ist meist auch nicht die beste Lösung.
4. Technische Details: Unterstützung mehrerer Plattformen, Multithreading, ...
