"Gute" und "schlechte" Programmierung?

M

McMoneysack91

Gast
Liebe Freunde,

ich bin KEIN Programmierer. Das einzige, was ich an Code beherrsche ist ein wenig HTML, PHP und CSS für Webdesign. Dennoch stoße ich (auch im Alltag) auf ein Phänomen, welches andere und ich mit guter und schlechter Programmierung betiteln könnten.

"It is hard to write good code" - Linus Torvalds

Meinen ersten Berührungspunkt hatte ich, als ich Gothic 3 spielte. Ein von Piranha Bytes (Essen/Bochum, NRW) programmiertes Spiel. Ein Team von etwa 20 Leuten erstellte in einer Essener zum Studio umgebauten Wohnung dieses große und großartige Spiel. Umstritten, verfrüht veröffentlicht aber eine große Leistung! Es war erst das AddOn zu Gothic 3 also Götterdämmerung, das mich aufmerksam werden ließ. Das Spiel hatte nur einen Bruchteil der Welt, einen Bruchteil der Charaktere, einen Bruchteil der Dialoge, Quests etc. Also wesentlich weniger Inhalt. Dennoch war die Performance deutlich "schlechter". Das Addon war ressourcenhungrig wie das Original. Dieses Addon war nicht von Piranha Bytes geschaffen sondern wurde meines Wissens nach nach Indien outsourced. So ging bereits damals die These einher, es sei "schlechter" programmiert/geschrieben.

Ein weiteres Beispiel sind moderne AAA Games. Ich bin KEIN AAA Gamer. Dennoch verfolge ich ein wenig die Entwicklungen der Hard- und Software. Mancherorts habe ich schon gehört, dass die exponentiell stärker werdende Hardware heutige Softwareentwickler "faul" ("lazy") mache und man sich nicht länger die Mühe mache, "sparsamer" oder ordentlicher zu programmieren. Man verlasse sich einfach darauf, dass die monströse Hardware die eigenen Patzer schon irgendwie ziehen werde. Dies resultiere in fürchterlich "bloated" und auch unnötig bloated Software, die eigentlich viel schlanker sein könnte.

Aus HTML/CSS kenne ich Situationen, die man auf unterschiedliche Weisen lösen könnte. Wenn ich eine Seite mit bestimmten Elementen auf eine bestimmte Weise erschaffen will, so gibt es mehrere Möglichkeiten. Alles als Tabellenzellen, Wrapper, Säulen, Boxen etc. Im Endeffekt kommt man visuell und haptisch zum etwa selben Ergebnis, die Anforderungen an die Hardware (im weitesten Sinne) oder auch an den Browser sind jedoch unterschiedlich. So las ich viele Tipps, dies und jenes lieber so und so zu machen, da die andere Methode nur unnötig den Browser "stresse", weil er jedes einzelne Element neu berechnen und darstellen müsse. Resultat wäre also auch hier eine eher leichte, snappy Website oder eine schwere, zögerliche.

Kann man das so in etwa vergleichen? Gibt es "unter der Motorhaube" so viel Platz für gestalterische Freiheit, dass es die sichtbare Oberfläche so stark verändert? Ist das gemeint mit "gutem" oder "schlechtem" Programmieren?
 
Zuletzt bearbeitet von einem Moderator:
Kurz: ja
Früher wurden die Spiele (und Programme) noch mit Leidenschaft entwickelt. Von Spielern für Spieler. Heute steht oftmals leider der Gewinn im Vordergrund. Du solltest programmieren lernen. Es braucht mehr Entwickler wie dich.
 
  • Gefällt mir
Reaktionen: gongplong, Innensechskant, RAMSoße und eine weitere Person
Ich bin auch kein Programmierer, aber zu gutem Code gehört mehr als nur Performance...

Auch wichtig:
  • gut kommentieren, dass ein anderer Programmierer eine Chance hat, zu verstehen, wie das Programm funktioniert
  • Umgang mit Fehlern
  • Umgang mit nicht erwarteten Inputs
Insbesondere letzter Punkt ist einer, der zu sehr vielen Schwachstellen in Programmen führt. Stichwort 'code injection'.
 
  • Gefällt mir
Reaktionen: Tzk, evilnear, species_0001 und eine weitere Person
mr_andersson schrieb:
Du solltest programmieren lernen. Es braucht mehr Entwickler wie dich.
Das Problem sind wohl weniger fähige Programmierer, sondern die Tatsache, dass ein Unternehmen die Wirtschaftlichkeit immer betrachten muss. Da sollte man keine romantische Vorstellung in der Spieleindustrie haben, dass da alle zum Spaß und aus Leidenschaft programmieren. Auch das ist Arbeit mit begrenztem Budget. Und begrenztes Budget heißt auch begrenzte Zeit für bestimmte Tasks. Das frustet den Programmierer ebenso, wenn er was hinscheißen muss, was zwar funktioniert, aber nicht gut ist.

Gibt natürlich auch Spiele, die mit Liebe programmiert wurden und kein Publisher im Nacken steht, der auf einen Release pocht. Stardew Valley wurde innerhalb von vier Jahren von einem einzelnen Entwickler auf die Beine gestellt. Eine AAA-Schmiede hat da einen ganz anderen Personalstamm.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Schtefanz und Gorasuhl
Bzgl AAA Games, du musst den Umfang heutiger Spiele bedenken. Laufen auf unterschiedlichen Plattformen mit teils massiv unterschiedlicher Rechenleistung.
Das führt dann dazu, dass ein Großteil der Funktionalität extern eingekauft wird, zb Gesichtsanimationen oder realistische Bäume etc. Schau dir das Intro eines modernen AAA Spiels an und da stehen dann schnell mal ein halbes Dutzend SDKs auf der Liste für bestimmte Funktionen.
Damit müssen die engine Entwickler sehr viel glue-code schreiben, also Code der die unterschiedlichen Teile miteinander verbindet und das ist selten reibungslos.

Das hat nichts mit schlecht oder gut programmieren zu tun, sondern primär mit Zeitdruck und Feature Creep.
Qualität fällt halt schnell hinten runter wenn ein neues flashy Feature benötigt wird.
 
McMoneysack91 schrieb:
man sich nicht länger die Mühe mache, "sparsamer" oder ordentlicher zu programmieren. Man verlasse sich einfach darauf, dass die monströse Hardware die eigenen Patzer schon irgendwie ziehen werde
Das ist gang und gäbe heutzutage. Ein paar User haben schon auf Twitter über die hohe Hardware Anforderungen beschwert. Einige Entwickler haben "hole dir eine bessere GPU" geantwortet.

Die Anforderungen für Diablo2 Ressurected zwischen low und high settings sind wohl fast identisch (in der beta getestet). 10fps unterschied wenn überhaupt, auch wenn grafisch deutlichere Unterschiede erkennbar sind.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: floq0r und KitKat::new()
Ich habe zu Zeiten der Dinosaurier COBOL gelernt und viele Jahre programmiert. Wer COBOL beherrscht, schreibt meist sehr gut lesbaren Code.

Heute verwende ich fast ausschließlich VBA und kann, ähnlich wie in grauer Vorzeit mit COBOL, sehr gut lesbaren und daher selbstdokumentierenden Code schreiben!
 
Um mich meinen Vorrednern anzuschließen: Ja, gerade bei so großen Studio-Produktionen leidet inzwischen sehr oft die Qualität - Und das nicht nur in Hinsicht auf sauberen oder performanten Code.

Vorab sei gesagt, dass der vorherschende Zeitdruck FAST IMMER einer der größten Rollen dabei spielt.
Denn zum einen leidet darunter die Codequalität allgemein und zudem erhöht das den Druck, Komponenten von externen Parteien einzukaufen, die streckenweise dann einfach "drangefrickelt" werden müssen.

Dann muss oft noch Kompatibität zu verschiedenen Systemen (wie z.B. PC, XBox und PS) gewährleistet werden. Gerade hier bliebt oftmals nicht so performanter Code mit dabei, wenn es dafür ohne viel Aufwand auf allen Systemen läuft. Sprich die Optimierung für die jeweils einzelnen Systeme leidet.

Ein weiteres Problem bei großen Softwareprojekten ist, dass da ja deutlich mehr Parteien, als nur die Entwickler dran zu schaffen haben.
Management, Marketing und diverse Entscheidungsträger, bei denen natürlich der Gewinn vorrang gegenüber dem Spielerlebnis steht.
Tatsächlich ist es nichtmal selten, dass diejenigen, die am Ende entscheiden ob ein Produkt "Marktreif genug" ist, gar nicht in der Lage sind die tatsächliche Qualität zu beurteilen.
Geschweige denn das eigentliche Produkt gar nicht erst selber getestet haben, es Aufgrund des Gewinns aber bereits auf den Markt gebracht wird.

Zudem ist es üblich, dass solche Projekte in viele kleine Teams von Entwicklern gegliedert werden, von denen jede eigene Module zu bauen hat (ähnlich wie im Bau, eine Partei bauts Dach, eine die Verrohrung etc.), die Teams untereinander manchmal aber gar keinen großen Austausch haben.
Auch dabei bleibt dann oft Leistung liegen..

Könnte dir da Lieder von singen..

Andererseits muss leider auch sagen, dass die Kunden selbst auch ein Teil des Problems sind.
Denn ganz häufig werden ja solche Qualitätskrüppel trotzdem gekauft.
Ganz im Sinne von "die nächsten Updates regeln das schon"...
Eigentlich müsste sowas großflächig boykottiert werden damit sich in da ggf. mal was tut.
 
  • Gefällt mir
Reaktionen: McMoneysack91
netzgestaltung schrieb:
die bequemste funktion ist meistens die langsamste. ich kenns auch nur von JS, zb:
Aber nur in einem Fall (viele Daten)
 
was abgesehn davon auch noch oft der fall ist, ist das geschwindigkeit einer gewissen wartbarkeit geopfert wird. vor allem wenn viele leute gemeinsam arbeiten, ist ein dokumentiertes SDK schon eine seriöse überlegung.
 
Nero2019 schrieb:
Das ist gang und gäbe heutzutage. Ein paar User haben schon auf Twitter über die hohe Hardware Anforderungen beschwert. Einige Entwickler haben "hole dir eine bessere GPU" geantwortet.
Das ist nicht nur heute gang und gebe, sondern das war früher so.
Früher war der Umstand nur anderen Beweggründen geschuldet. Man hat für seine Software trotz Optimierung eine gewisse Leistung gebraucht. Diese war aber zu Beginn der Entwicklung noch nicht für die Breite Masse verfügbar. Man ging davon aus, dass bei der Veröffentlichung, die Software flächendeckend zumindest läuft (wenn auch mit etwas Wartezeit/Lags verbunden) und spätestens 1 vielleicht 2 Jahre später dann auf der gängigen Hardware ohne Wartezeiten.

Und wenn man halt aufs Optimieren angewiesen war, weil beispielsweise die Hardware auf absehbare Zeit nicht die gewünschte Leistung erreichen wird, dann musste man sich was überlegen. Siehe Link


Das Problem ist viel mehr, dass der geforderte Umfang und Detailgrad immer mehr zunimmt. Das alleine bedingt schon, dass es immer mehr Stellen gibt an denen potentiell Fehler auftreten können. Daher bleibe ich lieber bei Nischenspielen oder welche wie das genannte StardewValley oder auch Hades die einfach ohne Zeitdruck mit viel Herzblut programmiert wurden.

Der Käfer läuft und und läuft und läuft, weil der Motor zum einen extrem niedrig verdichtet ist (ca. 6-7,5). So niedrig sind nicht mal moderne Turbomotoren mit jenseits der 700kW verdichtet. Zum anderen gibt es einfach keine großartigen Elektrischen Bauteile und Regelsysteme. Der hat einen Laderegler, Verteiler, Leuchten, Gebläse und Wischer. Der Stromlaufplan umfasst 2 DINA4 Seiten. Zum Vergleich, der Stromlaufplan zur Modellreihe (96-99) von meinem Dicken umfasst fast 600 Seiten. Bei meinem damaligen Ausbilder hing vom Topmodel F01/F02 ein Blockschaltbild der Steuergeräte und ihrer Vernetzung am Schrank bei den Testern. Der war auf ein DINA3 Blatt gedruckt und das war für mitlerweile um die 10 Jahre alte Fahrzeuge. Ich will nicht wissen was das mit den ganzen zusätzlichen Komfort- und Assistenzsystemen mitlerweile für Ausmaße angenommen hat.

McMoneysack91 schrieb:
Aus HTML/CSS kenne ich Situationen, die man auf unterschiedliche Weisen lösen könnte. Wenn ich eine Seite mit bestimmten Elementen auf eine bestimmte Weise erschaffen will, so gibt es mehrere Möglichkeiten. Alles als Tabellenzellen, Wrapper, Säulen, Boxen etc. Im Endeffekt kommt man visuell und haptisch zum etwa selben Ergebnis, die Anforderungen an die Hardware (im weitesten Sinne) oder auch an den Browser sind jedoch unterschiedlich.
@Nilson hatte schon den Thread verlinkt indem wir auf sowas mal eingegangen sind. Es gibt halt verschiedene Möglichkeiten zur Lösung eines Problems. Meist sind die sauber geordneten und gut lesbaren Codes langsammer als irgendwelche Optimierten.
 
McMoneysack91 schrieb:
Ein weiteres Beispiel sind moderne AAA Games. Ich bin KEIN AAA Gamer. Dennoch verfolge ich ein wenig die Entwicklungen der Hard- und Software. Mancherorts habe ich schon gehört, dass die exponentiell stärker werdende Hardware heutige Softwareentwickler "faul" ("lazy") mache und man sich nicht länger die Mühe mache, "sparsamer" oder ordentlicher zu programmieren. Man verlasse sich einfach darauf, dass die monströse Hardware die eigenen Patzer schon irgendwie ziehen werde. Dies resultiere in fürchterlich "bloated" und auch unnötig bloated Software, die eigentlich viel schlanker sein könnte.
AAA Spiele und Software allgemein muss man unterscheiden. Top Games müssen immer am Limit arbeiten und werden auch bezgl. Performance hart optimiert, an allen Ecken, ega ob es um die Modelle/Assets geht oder was den Code angeht.
Software wird oft nicht speziell so geschrieben, dass sie möglichst performant ist. Man kann Dinge tun, die sind ganz speziell wenig performant, aber davon abgesehen wird Software oft hauptsächlich darauf optimiert, dass die Wartung und Erweiterung möglichst einfach ist.
 
Rickmer schrieb:
gut kommentieren, dass ein anderer Programmierer eine Chance hat, zu verstehen, wie das Programm funktioniert
Das sagt man immer so lapidar dahin. Kommentare sind heutzutage durchaus stark verbreitet. Aber gute Kommentare bzw. gute Code-Dokumentationen sind eher Mangelware.
Also so die Klassiker a-la da wird erklärt, was der Code macht (ähm aber das sehe ich doch; sag mir lieber, wofür der gut ist) oder es wird erklärt, was in einer Variable gespeichert wird (dann benenn sie doch lieber entsprechend) oder oder oder.

Von daher würde ich das 'gut' in Deiner (völlig richtigen) Anmerkung sogar gern noch 2-3 Mal unterstreichen. :-)
 
Hier ein Paradebeispiel für schlechte Programmierung :-)

Gerne erkläre ich auch, warum es denn so programmiert wurde:

-Teil mit dem VBScript:
hatte diesen einfach vom Thread-Ersteller übernommen, da dieser funktionierte. Im weiteren Thread-Verlauf wurde dieser dann überflüssig => rausgeflogen, da nicht notwendig

-Wochentag mit Batch auslesen:
kompliziert. Also einen Hybriden mit Powershell eingebaut.
Die Frage, welche sich nun stellt : Warum nicht gleich alles in Powershell? => Kann Powershell einfach nicht & werde damit auch nicht warm. Mit Batch einfach Quick&Dirty erstellt, da wenig Zeit & schnelle Lösung her musste :-)

-Unnötige Ordner:
Wird das Skript ein zweites Mal gestartet, so werden zwei Ordner in schon vorhandenen Ordnern erstellt. Was natürlich nicht erwünscht ist.
Batch bzw. der DIR-Befehl bieten keinen Befehl an, um Ordner bei der Auflistung auszuschließen (irgendeinen Exclude-Parameter). Man müsste zwei FOR-Schleifen ineinander verschachteln, was natürlich sehr unübersichtlich wird.
Dann kommt noch hinzu : es ist Batch & Batch-For-Schleifen sind von Haus aus einfach unübersichtlich ^-^
Daher:
Batch läuft durch und erstellt die unnötigen Ordner & am Schluß werden diese einfach gelöscht. Statt sauber über irgendeinen Exclude erst gar nicht zu erstellen. Unsauber, aber funktioniert :-)

-Zu viele unnötige (Hilfs-)Variablen:
Es waren verschiedene Anforderungen vorgegeben. Man probiert nach und nach aus, wie welche Funktion dann auszusehen hat.
Dann kommt das große Zusammenfügen aller Teile. Statt dann sauber einmal die Variablen an die richtigen Stellen zu schreiben bzw. komplett anzupassen: Hilfsvariablen
Das Ergebnis der ersten Verarbeitung wird in eine Hilfs-Variable gesteckt. Diese ist dann wieder die Eingangs-Variable für die zweite Verarbeitung usw. usw.
Da könnte man um einiges optimieren. Aber : Zeit ist Geld ^-^

-Keinerlei LOG-Funktion und Fehlerbehandlung integriert:
was ist, wenn das Skript an einer Stelle hängt oder ein Fehler vorliegt?
Einfach zu faul, ein paar zusätzliche Zeilen entsprechend einzupflegen ^-^

Meine Programmierung würde ich daher nennen:
quick&dirty, funktional und wiederholen sich in Programmteilen auch oft (greife auf schon vorhandenen Sourcecode zurück). Was sich einmal bewährt, da bleibt man auch.
Da ich kein Programmierer bin, bin ich mit meinen Möglichkeiten beschränkt & einfach zu faul irgendwelche Dokumentationen bis ins Detail zu lesen.
Bei mir in der Arbeit sind die Anwender typische Blackbox-Anwender. Wie es funktioniert ist ihnen egal. Hauptsache es funktioniert. Es gibt keine Anforderungen an Hardware, Platz, etc.

Und denke, daß die AAA-Hersteller teilweise genauso verfahren.
 
Zuletzt bearbeitet:
BeBur schrieb:
AAA Spiele und Software allgemein muss man unterscheiden. Top Games müssen immer am Limit arbeiten und werden auch bezgl. Performance hart optimiert, an allen Ecken, ega ob es um die Modelle/Assets geht oder was den Code angeht.
Du meinst so wie der JSON Parser bei GTA5? :freak:
 
Zurück
Oben