Meine Lieblingswege, um schlechtes Python zu schreiben

Haben Sie sich jemals Code angesehen, den Sie vor sechs Monaten oder drei Jahren geschrieben haben, und sich gefragt: „Was in aller Welt habe ich mir dabei gedacht?“ Wir alle haben.

Beim Nachdenken über meine eigenen pythonischen Abscheulichkeiten habe ich ein paar Trends bemerkt. Ich möchte nicht sagen, dass sie meine „Favoriten“ sind, aber ich scheine sie oft zu tun:

Zu komplexe Algorithmen

Dies ist ein großer. Ich schaue mir den Code an, den ich geschrieben habe – die Klassen, Module usw. – und kann sehen, dass er gut funktioniert.

Aber es könnte VIEL einfacher sein.

Einfacher bedeutet oft lesbarer, wartbarer und – überraschend oft – weniger zerbrechlich. Ich meine, der Code muss noch richtig funktionieren. Aber korrekter, einfacher Code ist fast immer besser als korrekter, komplexer Code.

Wenn ich eine Weile weggehe und mir die Codebasis später noch einmal mit frischen Augen ansehe, sehe ich oft eine viel sauberere Lösung.

Code „Versehentlich arbeiten“

Dieser ist irgendwie lustig.

Wenn ich den Code lese, kann ich sehen, was ich damals gedacht habe. Und es funktioniert tatsächlich – das heißt, es erfüllt die Anforderungen, besteht die Komponententests und verhält sich so, wie es soll.

Aber es ist klar, dass ich, als ich diesen Code schrieb, das Problem, das ich schrieb, um es zu lösen, völlig falsch verstanden habe.

Eigentlich sollte es NICHT funktionieren. Weil ich Code schrieb, um ein völlig fiktives Problem zu lösen, nicht das eigentliche Problem! Aber irgendwie löst es beides.

Ich gebe zu, dass mir das peinlich ist.

Trotzdem bin ich erstaunt, dass dies überhaupt passiert, und noch mehr erstaunt, dass es immer wieder zu passieren scheint.

Irreführende Bezeichnernamen

Ich habe mir viel Mühe gegeben, gute Namen für Dinge zu wählen. Variablen, Typ- und Klassennamen, Methoden, Module usw.

Das liegt daran, dass unsere Klarheit darüber, was vor sich geht, in direktem Verhältnis dazu steht, wie klar wir die Rolle jeder Komponente verstehen. Und die Auswahl guter Namen für all diese kann sehr hilfreich sein.

Aber:

Obwohl ich dies seit Jahren zu einer zentralen Priorität mache, gehe ich oft zurück, um Code zu refaktorieren oder ein neues Feature oder so etwas hinzuzufügen, und denke „Ich hätte das wirklich SomeOtherName nennen sollen“.

Die Lektion ist vielleicht, dass die Verbesserung der Lesbarkeit ein nie endender Prozess ist. Wir können uns immer verbessern.

Verpassen

Dieser ist ziemlich interessant.

Was ich gefunden habe, ist, dass ich mir eine Codebasis ansehen kann, die ich vor einiger Zeit geschrieben habe. Und ich werde sehen, dass ich eine Technik hätte verwenden können, um die Qualität des Codes wirklich zu verbessern. Aber ich tat es nicht.

Diese „Technik“ kann ein Entwurfsmuster sein; eine Redewendung; oder vielleicht sogar ein Merkmal der Sprache. Fast immer nur, weil ich es damals noch nicht wusste.

Mit meiner jetzigen Weisheit wäre es viel einfacher gewesen. Und es wäre wahrscheinlich robuster, wartbarer, lesbarer usw.

Das Tolle, wenn man das merkt: Es ist ein Zeichen, dass Sie sich als Programmierer verbessert haben.

Feiern Sie also, wenn Sie all dies bemerken, und lernen Sie weiterhin daraus.



Source by Aaron Maxwell

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.