Warum ist Software so schlecht?
-
Wir müssen hier ganz klar unterscheiden was wir mit schlechter Software meinen. Den Teil der der Anwender sieht, oder wie intern designt ist. Ich denke hier geht es hauptsächlich um das Interne.
Da vermute ich mal locker 90% schlechten Code, im Sinne der immer angepriesenen Designrichtlinen aller Effektive C++, alles mit Factorys zuklatschen, und/oder Entkopplung von Allem als Ziel haben.
Generalisierung bis keiner mehr erkennt was das Programm/Datenbank eigentlich macht. Umgekehrt ist sinnlosen Cut&Paste Coding mit leichten Anpassungen auch nicht der heilige Grahl, genauso wie einfach drauf los hacken verkehrt sein kann.
-
Abstrahierung und wrapping werden zumindest bei mir nicht nur zum Spaß gemacht, sondern aus Notwendigkeit - weil ich beispielsweise selbst erlebt habe, wie sich die Anforderungen an die Software noch während der Entwicklungszeit änderten, teils im Wochenrhythmus Änderungsanforderungen usw - da ich die Klassen bei > 10000 sloc nicht jede Woche zwischen Freitag und Montag neu schreiben kann, war ich gezwungen, die Interfaces so allgemein wie möglich zu programmieren und Schicht für Schicht zu wrappen, um für spätere Änderungen und Erweiterungen flexibel zu sein. Ein Problem, wenn die Spezifikation "moving target" ist - bei von Anfang an unabänderlich feststehender Spezifikation läßt sich konkreter und weniger abstrakt programmieren.
-
derUnterschied schrieb:
Wir müssen hier ganz klar unterscheiden was wir mit schlechter Software meinen. Den Teil der der Anwender sieht, oder wie intern designt ist. Ich denke hier geht es hauptsächlich um das Interne.
Im Eröffnungspost ging es eigentlich ausschließlich um Probleme aus Anwendersicht.
-
derUnterschied schrieb:
Da vermute ich mal locker 90% schlechten Code, im Sinne der immer angepriesenen Designrichtlinen aller Effektive C++,...
Du hast "Effective C++" nicht verstanden...
derUnterschied schrieb:
...alles mit Factorys zuklatschen, und/oder Entkopplung von Allem als Ziel haben.
...und vermutlich auch nicht den Sinn von Entkopplung und Factories, selbst wenn man es mit beiden übertreiben kann. Und es gibt Techniken die Fehler reduzieren können, bevor der Kunde drauf stößt, die eine Entkopplung erzwingen (TDD).
derUnterschied schrieb:
Generalisierung bis keiner mehr erkennt was das Programm/Datenbank eigentlich macht.
Ganz ehrlich: Halte ich für gut. Ich weiß noch wie viele potentielle Kunden wir in der letzten Firma verloren hatten, weil wir MS SQL Server angeboten haben, sondern ausschließlich Oracle (Die Anfragen zu anderen Datenbanken waren vor 4-8 Jahren eher zu vernachlässigen).
Ebenso haben wir hier auch das Problem das unsere Aktuelle Anwendung gegen eine feste Datenbank entwickelt wurden ist (noch dazu Access), und die Unterstützung auch nur einer "echten" Datenbank trotz ein paar Kapselungen noch massiven Aufwand bedeuten würde. So massiv das ein Neuschreiben wegen einer weiteren Anforderung (Webschnittstelle) selbst meinen Chef sinnvoll erscheint.
derUnterschied schrieb:
...Cut&Paste Coding mit leichten Anpassungen auch nicht der heilige Grahl, genauso wie einfach drauf los hacken verkehrt sein kann.
Genau diese beiden letzteren Punkte sind imho mit die schlechtesten Praktiken.
-
Wir müssen hier ganz klar unterscheiden was wir mit schlechter Software meinen.
Das Ausgangsposting des Threaderstellers geht ja eher in die Richtung "Mängel in der Bedienung" wobei dies aber auch ein wenig mit Unwissen gepaart ist (Treiber, Aktualisierungen, Standardisierung).
Im Gegensatz hierzu reden viele über Fehler, Defects im Code-Design, Programmierung.
Refactoring ist ja nicht nur zeitintensiv, sondern auch fehlerträchtig - und das Resultat gefällt einem im schlimmsten Fall ein halbes Jahr später auch nicht mehr.
Vor solchen Sprüchen habe ich Angst, denn er wird auch manchmal benutzt um grottenschlechten Code zu rechtfertigen. Da würgt man, weil man keine Zeit hat, seinen Quellcode runter, aber wenn man mal wieder Zeit hat soll man diesen nicht refactorn, weil man sich ja Fehler einhandeln könnte.
Gewiss bei Refactoring besteht die Gefahr dass man sich Fehler einhandelt. Aber bei vorsichtiger und wohlüberlegter Vorgehensweise kann man diese Gefahr minimieren.
Was aber dabei herauskommt ist immer ein Code, welcher weniger fehleranfällig ist und welcher mir bei Neuentwicklungen meistens einen Haufen Zeit spart, da ich wiederverwendbarer Code herausbekomme. Und wiederverwendbar bedeutet oftmals nur dass Funktionen zum Thema X in Datei X stehen.
Da komme ich mir manchmal wie Scotty vor.
Da vermute ich mal locker 90% schlechten Code, im Sinne der immer angepriesenen Designrichtlinen aller Effektive C++, alles mit Factorys zuklatschen, und/oder Entkopplung von Allem als Ziel haben.
Ähh selbst an der Uni wurden die Design Patterns selten eingesetzt. Ich kenne nur wenige Fälle ich denen ich auch solche benutze.
Übrigens, lies mal Effektive C++ und spiele es durch. :p
-
fdfdg schrieb:
Nein, ich will sagen, dass man als Entwickler zu oft dazu neigt, Code aufzuräumen.
Stimmt. Das tue ich, wenn ich nicht mehr wach genug bin für produktive Arbeit, total entspannend
fdfdg schrieb:
Es gibt genug Szenarien, wo es einfach nicht nötig ist.
Stimmt. Ohne Deadlines würde die meiste Software, skrupulöse Entwickler vorausgesetzt, nie fertig.
-
Man kann auch eine Menge Geld machen mit guten Programmen:
http://www.apple.com/de/why-mac/better-software/Bei digitalen Synthesizern war die Bedienung oft grottenschlecht (verschachtelte Menüstruktur, tipp tipp tippomat statt einfache Drehregler für jede Funktion), einfach weil das Gerät dann billiger herzustellen war.
Irgendwann kam ein Typ mit technischem Filter Know How (aus E-Technik Studium), und hatte richtig gut klingende digitale Echtzeitfilter (für einen Satz vorgegebener Wellenformen, wie bei Analogsynths) programmiert. Die Hardware wurde wie bei einem Analogsynth erstellt (UND: man konnte den Synth AUCH als reine Software kaufen, als Sequenzerplugin!) Das Ding verkauft sich noch heute wie warme Semmeln und hat viele Nachahmer gefunden.
http://de.wikipedia.org/wiki/Access_Virus