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

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.

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.

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.

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.

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 ...

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 ....

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.

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.

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.