Sind schlechte Programmierpraktiken typisch für die Softwareindustrie? [geschlossen]


140

Ich habe gerade meinen ersten Job als Softwareentwickler vor über einem Monat angefangen. Alles, was ich über OOP, SOLID , DRY , YAGNI, Designmuster, SRP usw. gelernt habe , kann aus dem Fenster geworfen werden.

Sie verwenden C # .NET-Webformulare und erledigen fast alles im Code Behind mit sehr wenigen externen Klassen, die definitiv nicht als Objekte bezeichnet werden. Sie verwenden benutzerdefinierte Steuerelemente und verwenden sie wieder. Es werden nur Objekte von Entity Framework verwendet . Sie verwenden die Code-Hintergründe für jeden Client erneut. Sie haben Methoden, die 400 Zeilen lang sind und alle Arten von Dingen erledigen. Für neue Kunden nehmen sie die Datei aspx und aspx.cs, entfernen den Clientcode und beginnen mit dem Hinzufügen des neuen clientspezifischen Codes.

Ihre erste Entschuldigung wäre, dass es zusätzliche Wartung hinzufügt und mehr Code mehr Wartung bedeutet. Es ist ein kleiner Laden von drei Entwicklern, darunter ich. Ein Entwickler hat über 30 Jahre Erfahrung und der andere über 20 Jahre. Der eine war ein Spieleentwickler und der andere hat immer in C und C ++ gearbeitet.

Wie häufig ist dies in der Softwareindustrie? Wie kann ich sicherstellen, dass ich den Überblick über OOP und die damit verbundenen Prinzipien habe? Ich übe in meiner Freizeit und ich habe das Gefühl, dass ich wirklich unter einem erfahrenen Entwickler arbeiten muss, um bei OOP besser zu werden.


Ich habe im Chat eine Diskussion über den Titel eröffnet: chat.stackexchange.com/transcript/message/40126879#40126879 Schließen Sie sich mir an.
Dcorking

1
Kommentare sind nicht für eine längere Diskussion gedacht. Diese Unterhaltung wurde in den Chat verschoben .
Weltingenieur

Antworten:


263
  1. Die Prinzipien, die Sie in Ihrer Frage zitiert haben, sind nur die ... Prinzipien. Sie sind keine Mandate, Gesetze oder Anordnungen.
  2. Die Leute, die sich diese Prinzipien ausgedacht haben, sind zwar sehr schlau, aber keine absoluten Autoritäten. Sie sind nur Menschen, die ihre Einsichten und ihre Führung anbieten .
  3. Es gibt keine "richtige" Art zu programmieren. Dies wird durch die Tatsache belegt, dass sich die "akzeptierte" Art und Weise, wie wir dies tun, im Laufe der Zeit radikal geändert hat und weiter ändert.
  4. Der Versand eines Produkts hat oft Vorrang vor dem "richtigen" Versand. Dies ist eine so weit verbreitete Praxis, dass sie einen Namen hat: Technische Schulden.
  5. Einige häufig verwendete Softwarearchitekturen sind nicht ideal. Best Practices entwickeln sich weg von großen, monolithischen Anwendungen hin zu lose gekoppelten Modulgruppen.

  6. Der Kontext ist wichtig. Viele Architekturprinzipien bewähren sich nur, wenn Sie mit großen Programmen oder bestimmten Domänen arbeiten. Beispielsweise ist die Vererbung vor allem für Benutzeroberflächenhierarchien und andere Strukturen nützlich, die von tief verschachtelten, eng gekoppelten Anordnungen profitieren.

Wie folgt man einem "richtigen" Weg, einem prinzipiellen Weg, um aus der Wildnis herauszukommen?

  1. Studieren Sie Angemessenheit und nicht Korrektheit. Der "richtige" Weg, etwas in der Softwareentwicklung zu tun, ist der, der Ihre spezifischen Anforderungen am effektivsten erfüllt.
  2. Studienkompromisse. Alles in der Softwareentwicklung ist ein Kompromiss. Möchten Sie mehr Geschwindigkeit oder weniger Speicherbedarf? Möchten Sie eine sehr ausdrucksstarke Programmiersprache mit wenigen Anwendern oder eine weniger ausdrucksstarke Sprache, die viele Entwickler kennen?
  3. Studiere Zeitlosigkeit. Einige Grundsätze haben sich bewährt und werden immer relevant sein. Typsysteme sind universell. Erstklassige Funktionen sind universell. Datenstrukturen sind universell.

  4. Pragmatismus lernen. Praktisch zu sein ist wichtig. Mathematische Reinheit, Kristallkathedralenarchitekturen und Elfenbeinturmprinzipien sind nutzlos, wenn Sie nicht versenden können.

  5. Sei ein Handwerker, kein Eiferer. Die allerbesten Softwareentwickler kennen die Regeln und wissen, wie sie zu brechen sind, wenn dies sinnvoll ist. Sie sind es, die immer noch wissen, wie sie Probleme lösen und für sich selbst denken. Sie verwenden Prinzipien, um ihre Entscheidungen zu informieren und zu leiten, nicht um sie zu diktieren.
  6. Code schreiben. Viel davon. Die Prinzipien des Software-Designs sind vorzeitige Optimierungen, bis Sie viel Code geschrieben und ein Gespür dafür entwickelt haben, wie Sie sie richtig anwenden.

1
Kommentare sind nicht für eine längere Diskussion gedacht. Diese Unterhaltung wurde in den Chat verschoben .
Yannis

Wo kann ich systematisch die Erkenntnisse gewinnen, von denen ich keine Anleitung habe?
Ooker

4
Verstehen Sie nicht nur, was die beste Vorgehensweise ist, sondern welche konkreten Vorteile eine bewährte Vorgehensweise bietet. Dies ermöglicht es Ihnen, die beste Praxis mit der Angemessenheit zu verbinden und stellt auch sicher , dass die Praxis effektiv angewendet wird, um die beste Wirkung zu erzielen. Wenn Sie nur rezitieren, dass eine bewährte Methode die "Trennung von Bedenken" bewirkt, können Sie wahrscheinlich nicht sicher sein, ob Sie den richtigen Weg finden, um die Vorteile der Methode zu nutzen.
AaronLS

51

Es ist nicht unüblich. Eine Sache zu erkennen ist, dass die Software-Branche unglaublich vielfältig ist. Einige Unternehmen sind auf dem neuesten Stand. Führende Universitäten und innovative Softwareunternehmen (auch einige große Labors!) Sowie gesegnete Personen oder Gruppen wie die vierköpfige Gruppe analysieren die Probleme, die bei der gemeinsamen Arbeitsweise auftreten, und erfinden neue Sprachen, Maschinen, Werkzeuge und Muster. Neue Unternehmen, oftmals Ausgründungen oder Abspaltungen, versuchen, diese kommerziell zu nutzen, und haben manchmal erstaunliche Erfolge. Denken Sie an Facebook oder Google.

Aber Software wird heutzutage fast überall eingesetzt, vielleicht meist in Unternehmen, die eigentlich keine Softwareunternehmen sind. Ich habe hauptsächlich in der Transportbranche gearbeitet (Automobil und Eisenbahn), und es gibt eine gemischte Menge an Erfahrungen. Aber keiner von ihnen war irgendwo in der Nähe der "Schneide". Manchmal können sie nicht sein; Sicherheitsrelevante Software hängt von gut getesteten Tools ab (wir verwenden derzeit einen validierten C ++ - Compiler aus den 1990er Jahren). Manchmal haben sie nicht die richtigen Leute. Oft wird die Software von Ingenieuren aus anderen Bereichen entwickelt, die zufällig in die Softwareentwicklung ihres Unternehmens eingetreten sind, als Software immer wichtiger wurde. Man kann nicht erwarten, dass sie Prinzipien der Softwareentwicklung kennen oder anwenden.

Eine andere zu berücksichtigende Sache ist, was in einem Ingenieur in der realen Welt wichtig ist. Oft ist die Aufgabe buchstäblich keine Raketenwissenschaft. Die Bread-and-Butter-Probleme in Nicht-Software-Unternehmen können mit bescheidenen Software-Mitteln gelöst werden. Was einen nützlichen, vielleicht sogar guten Softwareingenieur ausmacht, ist zum Teil das, was einen guten Generalingenieur ausmacht: Seien Sie zuverlässig; organisieren und dokumentieren Sie Ihre Arbeit verantwortungsbewusst; kooperativ sein; gute Kosten- und Zeitschätzungen vornehmen (die Gültigkeit der Schätzung ist wichtiger als die tatsächlichen Kosten und Zeiten!); Verstehe, was du kannst und was nicht. Auffällig fehlt hier "die Kenntnis und Verwendung modernster Werkzeuge und Verfahren". Was Sie beschreiben, ist ein Unternehmen, das ein Toolset und einen Prozess eingerichtet hat, die für sie funktionieren. Sie werden wahrscheinlich nie etwas Sexy oder Außergewöhnliches produzieren, Aber sie erfüllen die Kundenanforderungen gut genug, um einen stetigen Strom ausreichender Einnahmen zu generieren. Das könnte die Definition von Engineering sein ;-).

Also ja: Was Sie an der Universität lernen, ist auf vielen Gebieten eigentlich nicht üblich.


Ich möchte ein Stück Trost oder eine optimistischere Note hinzufügen. Was Sie gelernt haben, sollten Sie nicht aus dem Fenster werfen. Sie können bessere Prinzipien in Ihrer täglichen Arbeit anwenden, ohne dass die Dinge kaputt gehen. Vielleicht bietet sich die Gelegenheit, ein neues Werkzeug oder Entwurfsmuster einzuführen. Die Chancen stehen am besten, wenn die alte Arbeitsweise für die Kollegen unangenehm ist oder wenn sie auf Probleme mit der Verwaltung von Komplexität oder Wartung stoßen (die beiden größten Probleme, mit denen sich Innovationen befassen). Seien Sie bereit, Verbesserungen anzubieten, wenn sich eine Gelegenheit ergibt. Einen positiven Einfluss ausüben und Methoden und Instrumente schrittweise verbessern; Wissen verbreiten, wo es geschätzt wird.


2
@nocomprende: no entiendo ... Meinst du, das Gemeinsame ist häufiger und das Außergewöhnliche ist leider außergewöhnlich? Oder dass das Gemeinsame nicht außergewöhnlich gut ist? Nun ja.
Peter A. Schneider

3
"Was Sie an der Universität lernen, ist in weiten Teilen des Fachs eigentlich nicht üblich" - Das scheint der Schlüssel zu sein ...
Brian Knoblauch

1
Ich habe nur gemeint, dass es auf dem Gebiet der Software Menschen gibt, die über die gesamte Bandbreite menschlicher Fähigkeiten verfügen, über die gesamte Bandbreite an Fachkenntnissen, Unternehmen, die über die gesamte Bandbreite an Problemen verfügen und so weiter, wie der Rest der Welt. Software unterscheidet sich in dieser Hinsicht nicht von anderen Bereichen. Das Problem hätte an jeder SE-Stelle auftreten können.

1
"Sicherheitsrelevante Software hängt von gut getesteten Tools ab (wir verwenden derzeit einen validierten C ++ - Compiler aus den 1990er Jahren)" klingt für mich ziemlich modern!
Hovercouch

1
@PeterA.Schneider es war ein alberner Witz darüber, wie modern es ist, deine Werkzeuge tatsächlich zu überprüfen. ;)
Hovercouch

16

Sie verwenden C # .Net-Webformulare und erledigen fast alles im Code Behind mit sehr wenigen externen Klassen

Da ist deine Erklärung. Wenn Sie sich nicht bewusst sind, ist der fertige Web Forms-Code genau das Gegenteil von OOP, SOLID, DRY, YAGNI, Design Patterns, SRP usw. Sogar die offiziellen Beispiele von Microsoft aus einigen Jahren würde dich heute erschrecken lassen.

Web Forms drängt sich in Richtung eines prozeduralen Ablaufs, mit einigen gefälschten "Ereignissen", die durch Kontrollklicks und dergleichen ausgelöst werden. Entwickler, die viel Zeit damit verbracht haben, Web Forms zu erstellen, scheinen auch normalerweise nicht bereit zu sein, davon Abstand zu nehmen, wahrscheinlich, weil sie so viel Zeit in das Erlernen des Seitenlebenszyklus und in das Durchführen dynamisch gerenderter Steuerelemente gesteckt haben, dass sie dieses Wissen jetzt nur ungern wegwerfen angesichts neuerer / besserer Methoden. Eine unbewusste Version des Irrtums der versunkenen Kosten. Diese Entwickler haben jahrelang gelernt, wie man mit Web-Formularen umgeht, und werden jetzt nicht mehr so ​​einfach von diesem Fachwissen abweichen, weshalb sie über die "Wartungs" -Zeit sprechen.

Und das ist im .NET Web Forms-Bereich übrigens durchaus üblich.


6
Schön, den Tech-Stack die erwähnte Frage
anzusprechen

5
Wer möchte durch 20 Klassen schauen, die sich verschachteln und gegenseitig aufrufen, um herauszufinden, was passiert, wenn Sie ein Kontrollkästchen aktivieren oder deaktivieren? Nur verrückte Menschen oder Menschen, die College-Professoren für Götter halten.
Developerwjk

1
Als WebForm erstellt wurde, waren die branchenüblichen Vorgehensweisen unterschiedlich (oder nicht vorhanden), und bereits vorhandene Anwendungen erhielten nie ein Refactoring, wenn "die neue coole Art, Dinge zu tun" eingeführt wurde. Das ist der Grund, warum Sie eine Menge WebForm-Code sehen, der durcheinander ist. Die Programmierprinzipien sind nicht auf den von Ihnen verwendeten Tech-Stack abgestimmt, sodass sie auch in WebForms, Cobol, Assembly usw. angewendet werden können.
BgrWorker

1
Ja, es ist wahr. Wie viele MB war Ihr ViewState? Seltsamerweise ermutigten meines Erachtens serverseitige Steuerelemente die Geschäftslogik in der Benutzeroberfläche. Der Programmierer war jedoch sehr schuld daran, dass er den asp.net-Frachtkult-Programmiermist mitgemacht hatte. Also: so viele Ereignisse, dass Geschäftsobjekte nicht in den richtigen Zustand versetzt werden konnten. Bus. Objekte konnten sich wegen UI-Kopplung nicht gegenseitig aufrufen. Dann: oh, schau Mo! Wir können "unverbunden" arbeiten! jang, jang, jang. Das reale Datenvolumen brachte Ihre App zum Erliegen, da die asp.net-Klassen sich als Datenbank-Engine ausgaben. Aber wir haben Verbindungen vor dem Verschleiß bewahrt!
Radarbob

1
All diese Beschimpfungen sind wahr ... herzzerreißend wahr. Ich habe so viel von dem, was in diesem Beitrag über WebForms-Anwendungen beschrieben wird, gesehen, dass ich das Gefühl habe, dass diese Anwendungen nicht viel besser sind als einige PHP-Skripte, die von einem Highschooler zusammengestellt wurden, der auf Energy Drinks spezialisiert ist - und es galt als Unternehmenssoftware!
Greg Burghardt

12

Wie häufig ist dies in der Softwareindustrie?

Sehr gewöhnlich. In etwa der gleichen Weise, wie wenn ein Klempner Ihre Klempnerarbeiten zerstört, ein Zimmermann Müll liefert oder ein billiger Schneider einen schlecht sitzenden Anzug anfertigt. Dh es ist alles menschlich.

Es gibt einen guten Grund, warum dies passiert: Leute, die nicht wirklich geschult (oder nicht begeistert) sind, müssen etwas unter Druck umsetzen.

Dies ist nicht in erster Linie ein Problem dieser Personen, sondern in der Regel der Strukturen, die die Softwareentwicklung in diesem Unternehmen betreffen. In einem Unternehmen entwickeln beispielsweise einige Praktikanten ihre interne Software. Selbst wenn diese Praktikanten klug und sachkundig sind, werden sie nur einige Wochen oder Monate dort sein, und der Eigentümer wird häufig wechseln.

Oder eine Person, die in der Domäne großartig ist, aber kein Programmierer, kann eine VBA-Anwendung usw. hacken, weil sie am Anfang recht einfach zu sein scheint.

Oder eine gut gemachte Anwendung endet in der Wartungsphase, alle guten Entwickler ziehen weiter und sie wird dann von wenigen Leuten (im schlimmsten Fall von einem), die wenig darüber wissen, keine Dokumentation usw. weiterentwickelt.

Wie kann ich sicherstellen, dass ich den Überblick über OOP und die damit verbundenen Prinzipien habe? Ich übe in meiner Freizeit und ich habe das Gefühl, dass ich wirklich unter einem erfahrenen Entwickler arbeiten muss, um bei OOP besser zu werden.

Es gibt zwei mögliche Antworten:

  • Entweder: Besprechen Sie dies mit Ihrem Chef und stellen Sie sicher, dass Sie an sauberen Projekten teilnehmen. Wenn nicht möglich, finden Sie einen neuen Chef.
  • Oder: Verantwortung dafür selbst übernehmen. Das bedeutet, dass Sie es alleine machen - in Ihrer Freizeit oder, wenn Sie können, in der Firma, aber von Ihnen selbst angetrieben (unwahrscheinlich).

Wenn die zweite Antwort für Sie zu zynisch klingt, können Sie mir versichern, dass dies nicht der Fall ist. Ein Tischler, der eine Holzwerkstatt zu Hause hat , wird die meisten sicherlich ein besserer Schreiner als denjenigen sein, der das nicht tut.

Zum Beispiel ist es durchaus möglich , und eine Menge Spaß für einige Menschen, zum Beispiel gräbt in eine neue Sprache wie Ruby, nicht nur lernen , die Syntax, sondern auch indepth spezielle OO Aspekte dieser Sprache, und wirklich tief tauchen. Alles in Ihrer Freizeit, ohne Verbindung zu Ihrer Arbeit. Es wird nur ein Hobby sein, aber als ausgebildeter Profi kann es genauso effektiv (oder noch effektiver) sein, wie neben einem leitenden Entwickler zu sitzen und zu versuchen, dem zu folgen, was er tut. Dies dient dann ausschließlich Ihrer persönlichen Entwicklung und Ihrem eigenen Spaß. Wenn Sie dabei keinen Spaß haben oder feststellen, dass Sie einfach kein Verständnis erzielen können, kratzen Sie daran und kehren Sie zur ersten Antwort zurück.

Der Lead - Entwickler , die Dich trainiert hat ziemlich wahrscheinlich , dass Sachen in genau diese Weise gelernt ...


2
Stellen Sie also nur gut ausgebildete, voll ausgebildete und begeisterte Leute ein, um ... alles zu tun. Warum machen wir das nicht? Es stellt sich die Frage: Wie sollen die nicht gut qualifizierten, nicht gut ausgebildeten und nicht begeisterten Menschen leben? Charles Dickens meldete die Antwort darauf: nicht sehr gut, wenn überhaupt.

@nocomprende, du projizierst deine Meinung, ich habe nicht angedeutet, was du in irgendeiner Weise geschrieben hast. Ich erkläre Gründe für die Tatsache, dass das OP es bemerkt hat.
AnoE

Ich halte nur über Kurt Vonnegut Frage denken von God Bless You Herr Kelterman : „Was zum Teufel sind die Menschen für ?“

2
@nocomprende, wenn ich über eine "nicht ausgebildete Person" spreche, sage ich nicht, dass Leute dumm sind, ich sage, dass aus irgendeinem Grund eine Person eine Arbeit gemacht hat, die für diese Arbeit nicht gut ausgebildet war. Die Schuld könnte wohl bei seinem Vorgesetzten liegen, der ihm den falschen Job gegeben hat; oder unter Umständen (zB wenn ein Mitarbeiter krank wird) oder aus welchen Gründen auch immer Sie sich das vorstellen können. Es hat überhaupt nichts damit zu tun, dass wir nur großartige Leute einstellen sollten. Wenn ich die Klempnerarbeiten in meinem Haus reparieren muss, können Sie sich ziemlich sicher sein, dass ich ein Chaos anrichten werde, obwohl ich großartig in allem bin, was ich sonst noch tun könnte.
AnoE

1
Es gibt eine alte Idee aus der Anthropologie, wonach Sklavengesellschaften wie die alten Ägypter weitaus weniger von den Menschen profitieren als Gesellschaften, die den Menschen dabei helfen, zu „gedeihen“. Deshalb war der Kapitalismus besser als die mittelalterliche Kultur. Im Idealfall würde jeder in der Lage sein, sich zu entfalten, und dann würden wir den vollen Nutzen für jeden Menschen und jeden Menschen den vollen Nutzen für die Gesellschaft erzielen. Der Kapitalismus ist nicht gut genug, um dies zu gewährleisten, also brauchen wir etwas mehr. Dass es Menschen gibt, die weniger als optimale Arbeit leisten, ist der Beweis, denn wenn der Kapitalismus perfekt wäre, würde dies nicht eintreten.

11

Ich denke, dass in Spanien eine Konstante ist, denn wenn ein Entwickler viele Jahre in einem Unternehmen verbracht hat, wird er (oder sie) normalerweise in mehr Managementbereiche wie Analyse und Projektmanagement befördert. Infolgedessen wird kein Peer Review durchgeführt und der Code wird normalerweise von weniger erfahrenen Personen geschrieben.

Das Versagen dieser erfahrenen Leute wird nie korrigiert, sondern sie konzentrieren sich nur darauf, die Arbeit zu erledigen. Infolgedessen häufen sich im Code immer mehr falsche Vorgehensweisen an.

Irgendwann sagt jemand, dass die beste "Lösung" darin besteht, auf eine aufstrebende Technologie umzusteigen, die saubereren und besser wartbaren Code generiert und eine neue Anwendung erstellt. Als ob die Technologie das alleine könnte.

Wieder werden unerfahrene Programmierer mit dieser neuen Technologie beauftragt, niemand überprüft den Code und der Kreis schließt sich wieder .... für immer und ewig ....


16
Mit Spanien nichts zu tun. Es ist das Peter-Prinzip - die Leute werden aus den Positionen heraus befördert, in denen sie gut abschneiden, bis sie eine Position erreichen, in der sie nicht sind, und bleiben dort hängen, weil es nichts gibt, wofür sie befördert werden könnten.
Jan Hudec

3
Es gibt auch die Tatsache, dass die Softwareindustrie immer noch wächst, so dass mehr Menschen mit relativ wenig Erfahrung anwesend sind. Und dass viele Unternehmen überhaupt keine erfahrenen Leute haben, weil sie neu und zu billig sind, um einen Veteranen einzustellen.
Jan Hudec

1
@JanHudec Ich weiß nicht, Mann, ich habe das Gefühl, ich hätte lieber einen jungen Mann vom College als einen der über 20-jährigen Leute, über die das Originalplakat spricht
Mikey Mouse

9
@MikeyMouse, stimmt, es gibt viele Leute, die nicht 20 Jahre Erfahrung haben, sondern 20 mal 1 Jahr Erfahrung. Und sie bringen wirklich große Probleme mit sich.
Jan Hudec

".. Peter Prinzip .."; insbesondere in einer Regierungsbehörde, in der es sich um ein bewussteres Phänomen handelt. Ich nenne es ihr Management-Inzuchtprogramm. Während es oft ein Gleichgewicht zwischen guten und schlechten Programmierern gibt, ist das Entsetzen, wenn der MIP die Inkompetenz verstärkt. Jahre später, als diese bestimmten jr. Programmierer sind jetzt Abteilungsleiter, die wiederum niemanden besser fördern werden als sie, gute Leute und Ideen verlassen oder werden vertrieben. Der Laden ist zu einem Korb voller Inkompetenzen geworden; stecken in der "remnant background radiation mindset" der Programmierung auf Großrechnern in einer Kultur des Mitmachens.
Radarbob

7

Einige der "Best Practices", die Sie in der Schule lernen, sind in realen Projekten nicht praktikabel oder kostengünstig. Eine der größten Änderungen, die mir aufgefallen ist, waren Formatierungen und Kommentare. Die meisten meiner Professoren betonten, wie wichtig es ist, Ihren Code ausführlich zu dokumentieren, aber in der Realität ist guter Code oft (nicht immer!) Selbsterklärend, und was noch wichtiger ist, viele Chefs möchten nicht dafür bezahlen, dass Sie zusätzliche Zeit für das Schreiben aufwenden Bemerkungen.

Es kann vorkommen, dass Programmierer aufgrund von Verknüpfungen und Anti-Patterns, für die weniger Kesselplatten benötigt werden als für Qualitätslösungen, unter Zeitdruck stehen.

Eines der größten Probleme, das ich bei vielen Teams und Projekten festgestellt habe, ist jedoch die mangelnde Bereitschaft, neue Dinge zu lernen. Viele der älteren Programmierer, mit denen ich gesprochen habe, haben ihre Karriere in einer Phase der Softwareentwicklung im Wilden Westen begonnen, als die Qualifizierung mit der Bereitschaft begann und endete, Code zu schreiben. Sie haben sich oft auf ganz andere Gebiete spezialisiert und sind mit wenig oder keiner formalen Ausbildung in die Programmierung eingestiegen, wenn sich eine Gelegenheit ergab (z. B. ihr Arbeitgeber hatte keinen Programmierer und brauchte jemanden zum Lernen, um firmeninterne Software zu erstellen). Einige dieser autodidaktischen Programmierer der alten Schule bemühen sich nie, moderne Codierungspraktiken zu erlernen, und codieren weiterhin in etwa dem Stil, den sie vor Jahrzehnten gelernt haben. Wenn sie aufgrund ihres Dienstalters für neue Projekte verantwortlich sind, halten sie die Projekte in der Regel zurück und beeinträchtigen die allgemeine Codequalität.

Natürlich gilt das Obige nicht für alle älteren Programmierer, und Codierer der neueren Generation können ebenso schuldig sein. Ich habe mit vielen jüngeren Programmierern zusammengearbeitet, die sich ein paar Werkzeuge und Bibliotheken aus dem College geholt und dann ganz aufgehört haben zu lernen. Sie laden eine IDE oder Bibliothek einmal herunter und aktualisieren sie nie, es sei denn, ihre Firma verlangt dies (Sie können manchmal erraten, in welchem ​​Jahr ein Programmierer seinen Abschluss gemacht hat, je nachdem, wie veraltet seine Bibliotheken sind). Sie halten sich nicht mit neuen Funktionen in den von ihnen gewählten Sprachen auf dem Laufenden und lernen nie neue Sprachen. Sie lernen keine neuen Programmierstrategien und können Muster oder Paradigmen missbrauchen, weil sie keine angemesseneren Alternativen kennen (oh MVC, wie stark werden Sie missbraucht). Im Laufe der Zeit werden ihre Arbeitsabläufe immer veralteter und sie werden mehr zu einer Verbindlichkeit als zu einem Vermögenswert.

Zusammenfassend lässt sich sagen, dass zwei der Hauptgründe für unübersichtliche Codebasen überstürzte Fristen und Programmierer mit veraltetem oder unvollständigem Wissen sind. Leider kann die Verantwortung für beide Themen in hohem Maße beim Chef oder CTO liegen, der dafür sorgen muss, dass die Fristen realistisch sind und die Mitarbeiter in Bezug auf ihre Kenntnisse und Fähigkeiten auf dem neuesten Stand sind. Wenn der Chef nichts über gute Programmierpraktiken weiß, ist das Beste, was Sie tun können, Änderungen vorzuschlagen und zu hoffen, dass sie für Vorschläge offen sind. Leider neigen sie dazu, dem Wort eines erfahreneren Programmierers zu vertrauen, der OOP nicht versteht und gerne 10.000 Zeilenklassen schreibt.


19
Ich mag diesen Mythos nicht, dass guter Code selbsterklärend ist und Kommentare überholt sind. Bestenfalls sagt Ihnen ein guter Code genau, was gerade passiert. Es gibt jedoch keinen Hinweis darauf, warum es etwas tut oder auch wenn es korrekt ist. Kommentieren Sie Ihren Code, damit der zukünftige Betreuer nicht erraten muss, warum Sie foo fobricieren, aber nicht bar .
user369450

13
Ich bin mit Ihrem ersten Absatz nicht einverstanden. Das Dokumentieren Ihres Codes (zum Beispiel mit Kommentaren) ist mindestens genauso wichtig wie an der Uni. Der Unterschied besteht darin, dass kein Fachmann kommentiert, was eine Zeile tut - er dokumentiert WARUM. Was gerade passiert, kann aus dem Quellcode gelesen werden. Warum ist oft das Ergebnis von mehreren Minuten bis Stunden des Denkens.
Araho

1
Es gibt nur sehr wenige Gründe, um zu schreiben, warum der Code etwas tut, und meistens könnte er mit einem besseren Methodennamen erklärt werden. Seien wir ehrlich, der Großteil des Codes, den wir normalerweise alle schreiben, ist so einfach, dass er keine Kommentare verdient.
BgrWorker

1
Wie geht das nochmal? Code wird einmal geschrieben und viele Male gelesen. Schreiben Sie Kommentare und Sie sparen auf lange Sicht Zeit. @ BgrWorker Kommt auf die Person an, denke ich. Ich schreibe regelmäßig Algorithmen und ich denke, sie verdienen Kommentare (zuletzt ein symbolischer Mathe-Parser ... braucht definitiv Kommentare)
Person27

1
Ich denke, Unit-Tests sind weitaus wertvoller als Kommentare. Zu oft habe ich Situationen gesehen, in denen der Code aktualisiert wurde und die Kommentare nicht mehr zutreffen. In diesem Fall erschweren die veralteten Kommentare das Herausfinden der Vorgänge. Unit-Tests dokumentieren die Absicht des ursprünglichen Programmierers. Wenn Ihr CI-System beim Einchecken Unit-Tests durchführt, müssen Sie diese beibehalten.
Bikeman868

2

Einige der schlechten Programmierpraktiken resultieren aus der Arbeit mit Legacy-Software, mit deren Entwicklung vor Jahrzehnten begonnen wurde. Wenn es sich um eine sehr komplexe Software handelt, ist es möglicherweise nicht möglich, alles neu zu schreiben. Es kann sogar äußerst schwierig sein, alles zu verstehen, was der Code tatsächlich tut. Am besten kopieren Sie einfach das, was funktioniert, und versuchen gleichzeitig, bessere Programmierpraktiken zu integrieren, wenn Sie dies tun können, ohne etwas zu beschädigen.


Ein Ausfall ist normalerweise auch keine Option.

1

Ich denke, es ist wichtig, nicht nur richtig von falsch zu unterscheiden, sondern die Gründe für jedes Richtig und Falsch zu kennen. Wenn Sie Gründe kennen, können Sie Konsequenzen vorhersagen. Warum dieses oder jenes Prinzip nicht verwenden, weil es in einem Buch beschrieben wurde, sondern weil wir wissen, wie es hilft und was genau passiert, wenn wir es brechen. Wenn Sie wissen, was wann passiert, können Sie Vor- und Nachteile abwägen und eine Entscheidung treffen. Dies hilft Ihnen auch, Ihre Position jedes Mal zu argumentieren. SOLID und OOP können auch die Wartung reduzieren, wenn sie ordnungsgemäß verwendet werden.

SOLID, wenn zu dogmatisch verwendet, führt zu zu vielen Klassen und Methoden, was auch nicht so gut ist. Übertreib es nicht. Dies ist zum Teil ein großes Problem bei unseren Lehrbüchern und Tutorials, da sie häufig versuchen, Ideen ohne angemessene Begründung zu fördern. OOP hat auch seine Nachteile. Viele Prinzipien und Paradigmen widersprechen sich. Sie müssen nicht an der Spitze stehen, Sie müssen alles vernünftig, gerechtfertigt, elegant und einfach machen.

Da dies Ihre erste Arbeit ist, ist die Wahrscheinlichkeit groß, dass diese Programmierer nicht sehr erfahren sind. Andererseits werden ihnen wahrscheinlich nicht sehr schwere Aufgaben anvertraut, die von weniger erfahrenen, billigeren Programmierern ohne viel Geschick und für weniger Lohn erledigt werden können. So funktioniert Wirtschaft. Jeder Arbeitsplatz ist anders.

Ich verstehe, wie Sie sich fühlen. Keine Panik . Sie brauchen, was Sie wissen, vielleicht nicht sofort, aber es wird Ihnen helfen. Vielleicht an einem anderen Arbeitsplatz, vielleicht manchmal. Sie haben Zeit vor sich, um weiter zu gehen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.