Ist guter Code in der modernen Softwareentwicklung unmöglich? [geschlossen]

19

Es scheint, dass selbst Entwickler-Tools solider und robuster geworden sind und das Schreiben von gutem Code zu einer Herausforderung geworden ist. Auch wenn die Tools leistungsfähiger sind, hat sich die Codequalität nicht verbessert. Ich habe zwei wichtige Faktoren herausgefunden, es gibt weniger Zeit und die Projekte sind komplexer. Da die Tools, die wir heute verwenden, leistungsfähiger sind, ist es einfacher, komplexeren Code zu schreiben, aber keine Zeit zum Planen zu haben und ohne Rückblick die Codequalität zu verringern und die Anzahl der Fehler und die Wartung zu erhöhen. Es ist nicht so, dass wir vorher keinen komplexen Code geschrieben hätten. Es ist so, dass wir komplexeren Code schreiben.

Meine Frage lautet wie folgt: Angesichts der Tatsache, dass wir eine leistungsfähigere Sprache und leistungsfähigere Tools haben.

  • Warum ist es schwieriger, guten Code zu schreiben?
  • Tragen Faktoren, Zeit und Komplexität dazu bei?
  • Werden Methoden nicht richtig geübt?

Die Art von Projekt, die ich in Betracht ziehe, ist eine Unternehmensanwendung mit großer Komplexität und Geschäftslogik. Die Definition von "guter Code" ist individuell. Bitte bleiben Sie bei der Interpretation von "guter Code" nicht stecken.

Amir Rezaei
quelle

Antworten:

34

Wie vor 20 Jahren von DeMarco und Lister in Peopleware festgestellt wurde, scheitert die überwiegende Mehrheit der gescheiterten Softwareprojekte nicht an technischen Herausforderungen, sondern an soziologischen Problemen . Dies hat sich in den letzten Jahrzehnten nicht geändert, egal wie sehr sich unsere Werkzeuge verbessert haben.

Missmanagement, unrealistische Erwartungen, Versäumnis, die richtigen Leute für den Job zu finden und / oder sie nicht ihren Job machen zu lassen, was zur Folge hat, dass sie nicht gehalten werden; Arbeitsplätze und Werkzeuge, die nicht für SW-Entwicklungsarbeiten geeignet sind; unbehandelte persönliche Konflikte; Politik ; Dies sind nur einige der typischen Probleme, die dazu führen können, dass ein Projekt von Anfang an zum Scheitern verurteilt ist.

Warum ist es schwieriger, guten Code zu schreiben?

Ich bin nicht ganz davon überzeugt, dass es wirklich schwieriger ist, guten Code zu schreiben als noch vor Jahrzehnten. Im Vergleich zu Maschinencode oder Baugruppen ist alles, was wir jetzt im Mainstream haben, viel einfacher zu handhaben. Nur müssen wir möglicherweise mehr davon produzieren.

Liegt es nur an den genannten Faktoren, Zeit und Komplexität?

Ja, die erreichbare Komplexität hat mit zunehmender Leistung unserer Werkzeuge mit Sicherheit zugenommen (und nimmt auch weiterhin zu). Mit anderen Worten, wir gehen immer wieder neue Wege. Das bedeutet für mich, dass es genauso schwierig ist, die größten Herausforderungen von heute zu lösen wie vor 30 Jahren, die größten Herausforderungen dieses Tages zu lösen.

OTOH Da das Feld so enorm gewachsen ist, gibt es heute weit mehr "kleine" oder "bekannte" Probleme als vor 30 Jahren. Diese Probleme sind technisch (sollten) keine Herausforderung mehr sein, aber ... hier kommt die obige Maxime :-(

Auch die Zahl der Programmierer ist seitdem enorm gewachsen. Und zumindest meine persönliche Wahrnehmung ist, dass das durchschnittliche Niveau an Erfahrung und Wissen zurückgegangen ist, einfach weil immer mehr Junioren auf dem Feld sind, als Senioren, die sie ausbilden könnten.

Sind die Methoden nicht richtig geübt?

IMHO sicherlich nicht. DeMarco und Lister haben einige harte Worte zu Big-M-Methoden. Sie sagen, dass keine Methodik ein Projekt erfolgreich machen kann - nur die Leute im Team können. OTOH die Small-M-Methoden, die sie loben, sind ziemlich nahe an dem, was wir heute als "agil" kennen, was sich weit verbreitet (IMHO aus gutem Grund). Ganz zu schweigen von bewährten Praktiken wie Unit-Testing und Refactoring, die noch vor 10 Jahren nicht allgemein bekannt waren und die heutzutage selbst viele Absolventen kennen.

Péter Török
quelle
2
Nicht ein Grammatik-Nazi zu sein oder irgendetwas anderes als "irrealistisch" (im zweiten Absatz) ist kein Wort. Ich denke du meinst 'unrealistisch'.
Ich kann das "Junior" -Problem nur unterstützen. Ich bin einer von ihnen und ich wünschte, ich hätte einen Mentor, der mir hilft. Es ist dankbar, dass das Internet heute da ist und Amazon und SO helfen, aber immer noch ...
Matthieu M.
1
+1: Bemerkenswert ist auch, dass wir aufgrund des raschen Wandels und des Wachstums von Tools / Technologien / Methoden in gewissem Maße alle mindestens ein paar Mal im Jahr Junioren sind. Die Erfahrung erlaubt es nur einigen Tierärzten, schneller als manchen jrs auf dem Laufenden zu bleiben.
Steven Evers
Ich lehne es ab, diese Frage ernst zu nehmen, es sei denn, wir haben keine formalen Regeln, um schönen Code von hässlichem zu trennen.
Shabunc
17

Probleme im Zusammenhang mit der Kodierung unter unrealistischen Fristen und dem Umgang mit technischen Schulden sind seit Weinberg '71 und auch Brooks '72 bekannt. Vorher ist die Literatur nur schwer online zu finden, aber ich bin mir ziemlich sicher, dass es alte CDC-, IBM- und NASA-Berichte gibt, die dasselbe aussagen.

Paul Nathan
quelle
1
+ Für "technische Schulden" und Referenzen.
Amir Rezaei
10

Ich denke, wir haben alle unsere eigenen Ideen und Schwellenwerte für "Good Code". Es gibt jedoch eine Reihe von Themen, die alle dazu beitragen:

  • Eine fehlerhafte Anwendung von "Bring es zum Laufen, dann verbessere es" bedeutet, dass wir toten Code und 10 verschiedene Varianten derselben Methode lassen, von denen jede nur einmal in der Codebasis verwendet wird. Dieses Zeug scheint nie aufgeräumt zu werden.
  • Zeit- und Budgetmangel. Der Kunde möchte in 3 Monaten 100 neue Funktionen, von denen einige nicht trivial sind, und er möchte kein Geld für Dinge ausgeben, die er nicht direkt sehen kann.
  • Mangel an Fürsorge. Seien wir ehrlich, einige Entwickler kümmern sich mehr um das Aussehen und Verhalten des Codes als andere. Ein Beispiel finden Sie im ersten Aufzählungspunkt.
  • Wir wissen wirklich nicht, wie man "guten Code" erstellt. Mein Konzept von gutem Code entwickelt sich ständig weiter. Was ich vor einem Jahrzehnt für gut hielt, ist nicht mehr so ​​gut.
  • "Guter Code" ist ein Werturteil. Abgesehen von "es funktioniert" und es sind keine Fehler bekannt. Alle anderen Kriterien für guten Code sind im Wesentlichen Ansichtssache.

Am Ende denke ich, dass es am besten ist, besser zu verfolgen als "gut" oder "am besten". Wenn wir den besten Code da draußen sehen würden, würden wir ihn als solchen erkennen?

Berin Loritsch
quelle
1
+1 Guter Punkt. Mit "gutem Code" habe ich mich nicht auf perfekten Code bezogen. Perfekter Code existiert nicht. „Guter Code“ ist ein Code, der Ihnen keine Kopfschmerzen bereitet, zum Beispiel gut durchdacht.
Amir Rezaei
1
Hervorragender Punkt, dass "guter Code" ein sich bewegendes Ziel ist. Ich bin jedoch nicht damit einverstanden, dass es sich nur um ein Werturteil handelt. Ich glaube, dass sauberer Code einfacher zu testen, zu erweitern und zu warten ist als unordentlicher Code und daher auf lange Sicht messbar billiger ist. Natürlich, da wir in echten SW-Projekten normalerweise keine Doppelblindtests mit Kontrollgruppen durchführen ;-), gibt es nur vereinzelte Beweise dafür, keinen harten wissenschaftlichen Beweis.
Péter Török
Es sieht so aus, als ob unsere beiden aktuellen Definitionen von "gutem Code" übereinstimmen. Ich habe jedoch einige herausragende Beispiele für gutes API-Design gesehen, die mir das Leben sehr erleichtert haben - aber die Bibliothek hatte keine Komponententests. Das bedeutet nicht, dass es nicht getestet wurde, nur, dass es nichts gab, was das Testen automatisieren könnte. Dafür lasse ich Platz.
Berin Loritsch
8

Warum ist es schwieriger, guten Code zu schreiben?

Weil Software zunehmend auf Abstraktionsebenen aufgebaut wird. Jede neue Technologie, die behauptet, die Entwicklung zu vereinfachen und zu beschleunigen, erhöht die Komplexität, die ein Entwickler verstehen muss. Diese Abstraktion kann einen großen Vorteil für die Produktivität haben. Wenn Sie jedoch nicht verstehen, was sie zu verbergen versucht, ist die Software anfälliger für Fehler und schlechte Qualität.

Pemdas
quelle
+1 Sehr guter Punkt, neue Tools erhöhen die Produktivität, was zu mehr Komplexität führen kann.
Amir Rezaei
1
+1. Alias ​​das "Gesetz der undichten Abstraktionen". :)
Bobby Tables
6

Ist guter Code in der modernen Softwareentwicklung unmöglich?

In der Tat ist es nicht möglich. Aber nicht aus irgendeinem Grund, den Sie schon gehört haben.

Der weitaus größte Teil der Projekte geht weit über die Möglichkeiten eines menschlichen Gehirns hinaus. Aus diesem Grund haben sich die Leute die Idee der Abstraktion ausgedacht , das heißt, sie verstecken ständig Details und klettern den Abstraktionsbaum höher, bis die Dichte der Zweige (Menge der zu verarbeitenden Informationen) auf ein akzeptables Maß abnimmt.

Wir haben das getan, wir haben das Komplexitätsproblem gelöst, aber das größere Problem, das wir zuvor hatten, wurde dadurch nicht behoben.

Es ist immer noch zu komplex für uns.

Um eine qualitativ hochwertige Lösung zu erstellen, müssen wir in der Lage sein, gleichzeitig alles zu sehen und zu verstehen, dh alle Module in großen und kleinen Implementierungsdetails. Um alle Diskrepanzen auf einmal zu sehen, sehen Sie jeden Code im Kontext aller möglichen Szenarien und optimieren Sie gleichzeitig die gesamte Codebasis.

Das werden wir nie schaffen.

Und wenn wir nicht können, werden wir niemals Qualitätscode produzieren.

Manager werden die Verwirrung von Modulen bemerken, kennen jedoch keine internen Probleme und Einschränkungen pro Modul.

Modulprogrammierer kennen lokale Einschränkungen, können diese jedoch im Kontext eines größeren Zusammenhangs nicht optimieren.

Es gibt keine Möglichkeit, Verständnis zwischen Managern und Programmierern (und sogar zwischen Programmierern) zu vermitteln. Und selbst wenn es welche gäbe, könnte die Kapazität des menschlichen Gehirns damit nicht umgehen.

Es gibt wenig, was wir tun können, außer es weiter zu versuchen (eine sinnlose Übung). Lassen Sie uns einfach den Code mehr oder weniger betriebsbereit halten und das Leben genießen.


quelle
Ich mag diese Antwort, wenn sie nur nicht in einem so pessimistischen, fatalistischen Ton geschrieben wäre ...
Timwi
1
@ Timwi: Nicht wirklich pessimistisch. Sollte Ihnen eine Entlastung bringen. :)
4

Ich bestreite die Prämisse Ihrer Frage. Es ist einfacher als je zuvor, guten Code zu schreiben, und aus diesem Grund gehen wir Probleme viel härter an, als wir es zuvor getan haben.

Ich möchte mich nicht für einen bestimmten Anbieter entscheiden, sondern Windows 1.0 mit Windows 7 vergleichen. Letzteres enthält tausendmal mehr Code, aber die durchschnittliche Zeitspanne zwischen Abstürzen hat sich hundertfach erhöht. Wir sollten in der Lage sein, eine Excel-Tabelle in ein Word-Dokument einzubetten, seit Windows 3.1, aber heutzutage funktioniert es mehr oder weniger.

Ohne in die Sentimentalität "Sie Kinder heutzutage mit Ihrer Enten-Typisierung und VM" fallen zu wollen, würde ich vorschlagen, dass Sie keine Ahnung haben, wie schwierig es war, guten Code in den 80er Jahren zu schreiben: TINY-, SMALL- und HUGE-Speichermodelle, Overlays , nicht-eintretende OS-Aufrufe (Schauder). Gute Befreiung von all dem.

Charles E. Grant
quelle
Ich hasse es, vom Thema abzuweichen, aber persönlich würde ich behaupten, dass Windows 1.0 bis 3.11 tatsächlich sehr stabil waren, vermutlich aufgrund ihrer mangelnden Komplexität. Die am meisten abstürzenden Versionen von Windows waren 95, 98 und ME. Natürlich ist es eine andere Sache, welche Versionen auf andere Weise „gut“ waren.
Timwi
Was ist mit der Codierung auf Minicomputern oder Großrechnern anstelle von Systemen mit geringem Stromverbrauch? Die Probleme, auf die Sie verweisen, beziehen sich auf das Intel 8086-Modell ...
Paul Nathan
@Paul, die 8086-Probleme waren die, mit denen ich am meisten zu tun hatte. Allerdings waren die Werkzeuge zum Schreiben von Software auch auf Großrechnern für moderne Verhältnisse erstaunlich grob. Die Redakteure standen Edlin im Allgemeinen näher als Emacs. Noch 1982 verwendete ich NUROS (Nebraska University Remote Operating System) auf IBM-Hardware. Jobs wurden mit virtuellen Lochkarten programmiert und ausgeführt. Und lassen Sie uns nicht die Y2K-Fehler vergessen, die meist durch die wahrgenommenen Lagerungsbeschränkungen verursacht werden.
Charles E. Grant
2

Moderne Anwendungen sind komplexer als vor 20 bis 30 Jahren, da ihre Umgebung vielfältiger und vielseitiger ist.

Es war typisch für ein DOS-Programm, in einer engen Schleife zu sitzen und auf den nächsten Tastendruck des Benutzers zu warten, dann den entsprechenden Code aufzurufen und wieder auf den nächsten Tastendruck zu warten.

Jede moderne Anwendung, bei der Sie die Maus überhaupt nicht verwenden können, hat ein ernstes Erklärungsproblem. Und die Dinge können in beliebiger Reihenfolge geschehen, da der Benutzer tippen, mit der Maus klicken und weiter tippen kann, während die RSS-Feeds in der Anwendung aktualisiert werden und die neuesten Einträge für den Benutzer während der Eingabe angezeigt werden.

All diese Multitasking-Dinge sind wesentlich komplexer als wenn man nur an die Schlüssel des Benutzers denken musste. Das macht es schwieriger, wirklich guten Code zu schreiben.

Wenn die Forscher herausgefunden haben, wie wir Multitasking-Programme aus Entwicklersicht benutzerfreundlicher machen können, kann dies hoffentlich nachlassen, aber im Moment stecken wir fest, wenn alle versuchen, es gut zu machen, aber nicht genau wissen, wie sie es machen sollen es.


quelle
+1 "Moderne Anwendungen sind komplexer als vor 20 bis 30 Jahren"
Amir Rezaei
2

Es scheint mir, dass die Software erweitert wurde, um die verfügbare Prozessorgeschwindigkeit, Speicher, Festplatte und Programmierzeit zu füllen. Man könnte behaupten, dass das daran liegt, dass die Software viel mehr leistet. Nun, ich bin sicher, dass es viel mehr bewirkt, aber nicht genug, um das Aufblähen zu rechtfertigen.

Ich denke, es gibt ein altes Gesetz der Wissenschaft, an das man sich erinnern sollte:

Die Natur verabscheut ein Vakuum.

Francois Rabelas (französischer Mönch und Satiriker 1494-1553)

Mike Dunlavey
quelle
1

Tatsächlich denke ich, dass es im letzten Jahrzehnt einfacher geworden ist, guten Code zu schreiben, dh Programme, die wie erwartet funktionieren und wartbar sind. Die verfügbaren Tools sind jetzt besser, die Bibliotheken sind ausgereifter und umfassender, die Hardware ist viel schneller geworden, sodass wir keine Optimierungstricks anwenden müssen.

Warum also nicht wir?

IMO ist der Hauptgrund, dass wir ständig nach Wegen und Entschuldigungen suchen, um Dinge zu missbrauchen. Anstatt den altmodischen, einfachen, wahrscheinlich langweiligen Weg zu gehen, wie das Erstellen einer ausführbaren Windows-Datei, gehen wir an die Grenzen des Möglichen und suchen nach Möglichkeiten, um z. B. etwas wie PhotoShop als Webanwendung neu zu erstellen. Warum? Weil wir können. Zumindest glauben wir das.

user281377
quelle
1
Ich bin mit der Schlussfolgerung nicht einverstanden, dass Innovationen vermieden und altmodische Technologien oder Methoden niemals überholt werden sollten. Könnte genauso gut aufhören zu schreiben alle dann Programme und einfach zu verwenden , was wir haben ...
Timwi
Timwi: Ich argumentiere nicht gegen Innovation. Das ist nur der Grund, warum es so schwer zu sein scheint, guten Code zu schreiben.
user281377
1

Wann hat das letzte Mal JEMAND keinen Exploit geschrieben oder studiert, um dies mit Assembly zu tun (ohne Kernel-Hacker und ASIC-Leute)? Wie viele Bugs wurden in C-Core-Bibliotheken entdeckt? Fast keine und ein paar. Ich sage nur, dass die Leute in der Lage sind, exzellenten Code zu schreiben. Bessere Tools und Sprachen machen es weniger "erforderlich" und mehr "optional". Nicht, dass ich denke, wir sollten alle wirklich schrecklichen Code schreiben, aber wenn ich an komplizierte logische Konstrukte denke ... hätte niemand davon geträumt, etwas mit Hash-Arrays in Assembler zu schreiben. Es musste einen besseren Weg geben, mit der Logik umzugehen, anstatt ein kompliziertes Konstrukt zu verwenden. Auch wenn der Code schön ist, ist der Ansatz manchmal nicht so elegant. Ich denke, es geht irgendwie um das Problem, das Sie angesprochen haben. Guter Code ist nicht immer nur organisiert,

RobotHumans
quelle
Embedded-System-Leute schreiben eine anständige Menge an Assembler.
Paul Nathan
@ Paul Nathan True
RobotHumans
0

Ich denke, das liegt daran, dass bessere Tools und schnellere, reaktionsfreudigere Computer dazu führen, dass wir voraussichtlich viel mehr Zeit für die endgültige Komplexität des Produkts haben als vor einigen Jahren (oder Jahrzehnten). Die Komplexität der Apps nimmt also weiter zu, und unsere Annahmen darüber, wie hoch ein angemessenes Maß an Produktivität ist, nehmen weiter zu.

Wo ich arbeite, haben Entwickler es immer eilig (weil es immer mehr Dinge gibt, die Kunden wünschen, als sie Zeit haben). So werden viele Codeblöcke mit minimalem Bearbeitungsaufwand und ohne großen Aufwand kopiert. Und natürlich werden Fehler gemacht. Ich habe gerade gesehen, wie ein Fehler behoben wurde, bei dem ein Entwickler einen von mir optimierten Code kopiert hatte, ohne zu bemerken, dass die Annahmen, die die Optimierung gültig machten, nicht wahr waren, wo er sie platziert hatte.

Dies alles hängt von den internen (unseren eigenen) Erwartungen und von unseren Organisationen ab. Wir versuchen so schnell wie möglich so viel wie möglich zu tun. Und es kommt unweigerlich zu Fehlern.

Auch die Reaktionsfähigkeit des Computers fördert ein schnelles Bearbeiten, Kompilieren und Testen. In den alten Tagen (wie vor 35 Jahren) war der Turnaround so langsam, dass ich den Code ausdrucken (Quelle waren damals Lochkarten) und den Code manuell durcharbeiten konnte, bevor ich mein Deck einreichte. Jetzt bearbeiten wir einfach das Kompilieren und führen es aus. So viele Fehler, die wir durch methodisches Code-Walkthrough entdeckt hätten, können wir jetzt auf den Compiler und / oder die Unit-Testsuite zählen, die stattdessen abgefangen werden sollen.

Omega Centauri
quelle
Klingt nach einer jungen Firma, die noch nicht gelernt hat, dass der Billigste es beim ersten Mal richtig macht ...
Thorbjorn: Erstaunlicherweise gibt es das seit fast drei Jahrzehnten. Und es geht eigentlich ganz gut. Natürlich gibt es Geschäftsmodelle, die sehr auf Kundenwünsche eingehen (uns), und einige, die sehr qualitätsorientiert sind. Es ist wirklich schwer, beides zu sein.
Omega Centauri
0

Wie sind die Leute schlechter darin geworden, guten Code zu produzieren?

Wenn Sie .NET und eine Sprache wie C # nehmen, zum Beispiel (und ich weiß , es ist nicht die einzige Plattform / Sprache), würde ich argumentieren , dass die Codierung auch weit worden ist, viel leichter durch die Automatisierung vieler Dinge innerhalb des Visual Studios Umgebung.

Wenn überhaupt, erleichtert die Tatsache, dass wir jetzt über sehr ausgefeilte IDEs verfügen, die uns durch den Kodierungs- und Entwicklungsprozess führen, das Erreichen von "gutem Code".

Programmierer können sich jetzt darauf konzentrieren, eine gute Struktur zu erzeugen, anstatt so viel Zeit damit zu verbringen, Klammern und neue Zeilen einzugeben und sich Methodenaufrufe und Klassennamen zu merken.

Meine zwei Cent.

Nick Bedford
quelle
-2

Die Qualität des Codes ist nicht besser geworden

Bitte bleiben Sie nicht in der Interpretation von „gutem Code“ stecken

Tolle logische Tautologie.

Code wird nicht besser, weil die Leute die Definition von "gut" in Bewegung halten.

Wenn Sie "guten Code" diskutieren können, können Sie ihn nicht vergleichen und Sie können sich wirklich nicht entscheiden, ob es sich um eine "Herausforderung" handelt oder nicht.

S.Lott
quelle
Für mich ist "guter Code" so, dass er die Anzahl der Fehler verringert. Dies kann nun auf viele Arten erreicht werden.
Amir Rezaei
@Amir Rezaei: "Die Definition von" gutem Code "ist individuell". "'Guter Code' verringert die Anzahl der Fehler." Bitte wählen Sie nur eine Definition aus und aktualisieren Sie Ihre Frage so, dass sie nur eine Definition enthält.
S.Lott
Nun, "guter Code ist so, dass er die Anzahl der Fehler verringert", ist meine persönliche Vorstellung von "gutem Code". Ich denke, jeder weiß, wann das Projekt aufgeräumt werden muss oder nicht .
Amir Rezaei
@Amir Rezaei: Das ist mein Punkt. Wenn Sie in der Frage nicht "gut" definieren können (oder wollen), können wir das nicht vergleichen. Sie können behaupten, dass die Anzahl der Fehler gleich ist. Andere können behaupten, dass die Kosten für Fehler sinken. Ein anderer kann behaupten, dass das Geschäftsrisiko aufgrund der Planung von Fehlern steigt. Ohne eine einzige Definition von "gut" können wir alle über verschiedene Dinge sprechen. Bitte aktualisieren Sie die Frage.
S.Lott
Guter Code: Er wurde kompiliert, hat Tests bestanden, die Benutzergenehmigung erhalten und wurde in Produktion genommen. Hoffe nur, dass niemand daran etwas ändern will.
JeffO