Hallo allerseits! Im Rahmen unseres
Python-Entwicklerkurses haben wir eine weitere offene Lektion zum Thema „Wie man nicht in Python schreibt“ durchgeführt. Die Lektion wurde vom Lehrer und Schöpfer des Kurses
Stanislav Stupnikov unterrichtet , der über umfangreiche Erfahrung in der industriellen und wissenschaftlichen Entwicklung verfügt. Die Antimuster von Programmierung, schlechter Praxis und anderem Übel, über die Sie Bescheid wissen müssen und die beim Schreiben von Code vermieden werden sollten, wurden berücksichtigt.
Weitere Informationen finden Sie im Video und in der Zusammenfassung. Warnung: Es wird nicht empfohlen, einige Codebeispiele auf Ihrem Computer auszuführen!
Während der offenen Lektion zeigte der Lehrer Folien, die mit dem Jupyter-Notizbuch erstellt wurden.
Also fangen wir an!
Warum also nicht in Python schreiben?
Zur Vereinfachung der Einreichung von Material wurde eine Liste von Techniken erstellt, die im Programmierprozess nicht verwendet werden sollten. Jedes Beispiel wurde von einem übersichtlichen Codebeispiel begleitet (das kostenlos als Video angezeigt werden kann). Wir beschreiben kurz die wichtigsten Antimuster:
- Windelmuster. Es ging um das sogenannte "Windel" -Muster, was normalerweise einen zu breiten Versuch bedeutet - außer. Sie rufen beispielsweise eine Funktion auf, die ein Wrapper für etwas ist, z. B. eine Client-Bibliothek für eine Datenbank. In einem guten Fall (das System ist klein) ist in 99% der Fälle alles in Ordnung, aber wenn das System groß ist, werden die Wahrscheinlichkeiten eines Problems nicht optimal multipliziert. Infolgedessen fällt oder bricht ständig etwas.
- Antiglobalismus. Jeder weiß, dass globale Variablen ineffizient sind, außer in einigen Ausnahmefällen. Es ist viel besser, alles in Form von Attributen an Funktionen usw. usw. zu übergeben, um die gewünschten Ergebnisse zu erzielen. Einige haben jedoch eine „großartige Idee“ - veränderbare Objekte zu verwenden. Es besteht darin, nicht globale Variablen, sondern veränderbare Objekte an Funktionen zu übergeben, diese dann zu ändern und dann nichts zurückzugeben. Das ist so cool!) Tatsächlich ein Teil einer Programmiervorlage aus der C-Sprache, die in die Python-Welt übertragen wurde.
- Treppe zum Himmel. Wie Sie vielleicht erraten haben, ist dies eine „Treppe zum Himmel“. Dieses Problem lässt sich am besten durch ein einfaches Bild charakterisieren:
- Javatar. Fehler in diesem Plan werden häufig von Programmierern gemacht, die aus dem einen oder anderen Grund von Java zu Python gewechselt sind. Natürlich kommen sie mit ihrer eigenen Charta, so dass sie massenhaft gegen Python-Entwicklungsregeln verstoßen. Dies ist das Auftreten von wahnsinnigen Einrückungen und CamelCase und der Wunsch, mehr Klassen zu erstellen ... Infolgedessen wird die Codestruktur komplizierter. Wenn auf ein Skript mit einer Größe von 300 Zeilen verzichtet werden kann, werden 10 bis 20 Dateien angezeigt.
- Überentwicklung. Sehr oft wird die zweite Iteration eines Projekts entweder nie abgeschlossen oder zu kompliziert implementiert. Dies geschieht, wenn Sie einen vorhandenen, aber fehlerhaften Code neu schreiben möchten, um ihn ideal zu machen. Gleichzeitig vergisst du, dass das Beste der Feind des Guten ist. Infolgedessen gerät der Programmierer in die Standardfalle des Reengineerings, wenn die Implementierung teurer, schwerer und umständlicher wird als zur Lösung der Aufgaben erforderlich. Und in der Tat: Sollten Familienlimousinen Geschwindigkeiten von bis zu 350 km / h erreichen und Smartphones, deren Mode sich jedes Jahr ändert, 100 Jahre lang funktionieren?
- Oneliner Ein weiteres dringendes Problem ist die „einzelne Leitung“. Es geht um Programmierer, die mit beneidenswertem Eifer versuchen, alles in eine Zeile zu bringen, fünf Stockwerke mit Werbung)). Aufgrund der übermäßigen Komplexität des Codes und der Besonderheiten bei der Implementierung von maschinenregulären Ausdrücken in Python bleiben solche Skripte manchmal beim Parsen, sodass Sie ein spezielles Modul verwenden müssen, um das Problem zu beheben.
- Copy-on-Read. Dies ist weniger ein Fehler als vielmehr eine Funktion der Python-Programmierung. Viele sind mit dem Copy-On-Write-Ansatz vertraut. Seine Idee ist, dass beim Lesen eines Datenbereichs eine gemeinsam genutzte Kopie verwendet wird und beim Ändern eine neue Kopie erstellt wird, dh wir sprechen über die Optimierung von Leistungsprozessen. Wenn wir über Python sprechen, lesen wir in einigen Fällen nicht nur das Array aus den Elementen, sondern beziehen uns auf alle zugrunde liegenden Strukturen im Speicher, dh wir „schreiben“ den Speicher neu und ändern ihn. Anstelle von Copy-On-Write erhalten wir also Copy-On-Read, wenn wir scheinbar Speicher lesen, aber in Wirklichkeit müssen wir diese Informationen aus dem übergeordneten Bereich als untergeordneten Prozess in uns selbst kopieren, was es seit dem Ansatz traurig macht Optimierung funktioniert nicht und der Verbrauch wächst.
- Es gibt keine Gabel. Gabel - Klonen der Entstehung eines neuen Prozesses. Das Problem hängt mit den Besonderheiten der Arbeit mit Unix-Systemen und der Nicht-Offensichtlichkeit einiger Datenstrukturen zusammen, die in der Implementierung verborgen sind. Ein "gegabelter" Prozess ist ein Prozess, der in dem Moment beginnt, in dem der Thread das Protokoll in der Warteschlange erfasst hat, um etwas darin abzulegen. Das heißt, der neue Prozess, der aufgetreten ist, möchte auch etwas schreiben, aber dafür muss er das Protokoll aus dieser Warteschlange selbst holen, aber er kann dies nicht tun, da das Protokoll bereits erfasst ist. Als Ergebnis erhalten wir eine Sperre. All dies bestätigt nur noch einmal, dass es sich nicht lohnt, zu programmieren, ohne die Merkmale der Implementierung der Umgebung, in der Sie arbeiten, und die von Ihnen verwendeten Tools zu kennen.
Es gab noch viele interessante Dinge, also schau dir das Video besser an, weil Die Nacherzählung ist noch kurz.
Wie immer warten wir hier oder an
der offenen Tür auf Fragen, Kommentare und Vorschläge.