"Hassen Sie keine Menschen, hassen Sie Code."
Hat jeder die Erfahrung, mehr als einmal so zu denken? Auf welche Art von Code wurde Umi-sensei wütend? Und was soll ich machen?
Wenn ich einen solchen Code geschrieben habe, möchte ich auf meinen Code und meine Aktionen zurückblicken und ihn zusammenfassen, damit ich einen Code schreiben kann, der Professor Ohara nicht beleidigt. Es ist für alle unkompliziert geschrieben, aber ich würde es begrüßen, wenn Sie mir vergeben könnten.
Ist es nicht so?
Der Arbeitsaufwand, der sonst gering wäre, wird durch die zusätzliche Arbeit aufgeblasen, "komplizierten, mysteriösen und schwer lesbaren Code zu verstehen", was zu verpassten Gelegenheiten führt. Darüber hinaus können ** hinzugefügte Funktionen und vorhandene Funktionen bei einer chemischen Reaktion zu neuen Fehlern führen **. Und lesen Sie den Code noch einmal, um den Fehler zu beheben ... nur ** negative Spirale! !! ** ** **
Wenn Sie als persönliches Hobby schreiben, wäre es schön, wenn Sie sich selbst befriedigen könnten, aber wenn Sie es als Team entwickeln oder nach der Lieferung verwalten, ist das Verbrechen von schwer lesbarem Code sehr tief.
In einem Smartphone-Spiel gibt es beispielsweise Quests, die jedoch gerade gestartet werden.
(Ich denke, es gibt andere, je nach Spiel). Wenn Sie diese verschiedenen Prozesse so wie sie sind in einer Methode schreiben, können Sie Code erstellen, der schwer zu lesen ist. Eigentlich ist es ** ja **, diese Prozesse in einer Methode zu schreiben (weil Sie es zu einer Quest-Controller-Rolle machen und dies mit API aufrufen können), aber es ist gefährlich, es zu gehorsam zu schreiben.
Folgendes mache ich derzeit, um meinen Code so zu reparieren, dass er nicht zu einem negativen Erbe wird.
Der Code ist lang, da er verschiedene Funktionen implementiert. Schreiben Sie den Code also nicht so wie er ist, sondern für jede Funktion
-Ist es eine Quest während der Periode? => check_quest_period ()
Erstellen Sie eine Methode wie diese und rufen Sie sie auf.
Auf diese Weise können Sie beispielsweise schnell mit der Arbeit beginnen, wenn Sie "der Lotteriemethode des Feindes eine neue Spezifikation hinzufügen" müssen, da Sie nur select_enemy () betrachten müssen, ohne andere Prozesse zu lesen. Wenn select_enemy () lang ist, ist es sehr wahrscheinlich, dass mehrere Funktionen so implementiert werden, wie sie sind. Teilen wir sie daher für jede Funktion in Methoden auf.
Die Bedingung der if-Anweisung ist lang und es gibt abhängig von den Spezifikationen viele Verzweigungen. Wenn Sie in diesem Fall die if-Anweisung zu einer Methode machen, können Sie verstehen, was Sie tun, indem Sie sich nur den Methodennamen ansehen, um die if-Anweisung zu entschlüsseln.
Zum Beispiel Questverarbeitung
quest_start.py
class QuestStartManager(object):
@classmethod
def quest_start(cls, player, quest, now_datetime)
#Überprüfen Sie, ob die Quest ausgeführt wird
if quest.start_datetime > now_datetime or now_datetime > quest.end_datetime:
raise OutOfPeriodError
#Überprüfen Sie, ob die Questspielbedingungen erfüllt sind
if player.level < quest.need_level or quest.need_clear_quest_id not in player.clear_quest_ids oder (weggelassen, weil es nicht geschrieben werden kann):
raise PlayerQuestStatusIsNotPlayableError
(Im Folgenden wird der Code weggelassen.)
Ich möchte es nicht mehr nur durch einen Blick darauf lesen ... es sind nur ein paar Zeilen! if Aussage ... ein gruseliges Kind!
quest_start
class QuestStartManager(object):
@classmethod
def quest_start(cls, player, quest, now_datetime):
check_quest_period(quest, now_datetime)
is_playable_quest(player, quest)
Wie wäre es damit? Ist es nicht einfacher zu lesen, als wenn die if-Anweisung direkt geschrieben wird? In jeder Methode ist eine if-Anweisung geschrieben, aber Sie können sich aus dem Methodennamen "Es ist eine Periodenprüfung" oder "Prüft, ob Sie die Quest spielen können" vorstellen.
Ich denke, dass ein kurzer Code wie der folgende akzeptabel ist (dies ist nur ein Beispiel, und ich schreibe ihn tatsächlich als Versuch ... außer. Ich entschuldige ihn nur für den Fall).
quest.py
class Quest(models.Model):
@classmethod
def get_quest(cls, quest_id):
obj = cls.objects.get(quest_id)
if obj:
return obj
else:
return None
Aber was ist, wenn Sie diesen Variablennamen obj in einem langen Prozess schreiben? Sie werden besorgt sein, wenn dieses "Objekt" beim Scrollen an vielen Stellen erscheint. ** "Welches Objekt ist es !!" ** Du wirst einen Tsukkomi einsetzen wollen.
Wenn der Methodenname nur get_obj () oder update_obj () lautet, wissen Sie nicht, welches Objekt Sie abrufen oder aktualisieren möchten, und Sie werden die Zuverlässigkeit dieses Codes bezweifeln.
Wenn Sie sich für einen Namen entscheiden, ** ist der Name ungewöhnlich lang (es gibt mehrere Verben) ** oder ** Ich denke an einen Namen, aber wenn ich mich frage, welche Art von Namen passt **, ist fast ** zu viel Funktionalität in die Methode gepackt ** Also lasst uns die Funktion ausschneiden.
Syndrome, die Sie detailliert schreiben möchten, treten häufig auf. Ich analysiere, dass dies daran liegt, dass der psychologische Zustand, in dem andere Verantwortliche den Inhalt des von mir geschriebenen Codes nicht verstehen, aufgedeckt wird (ich bin es).
Es ist lächerlich, es so zu lassen, wie es ist! !!
Lassen Sie uns überlegen, ob es für jede Funktion in Methoden unterteilt werden kann.
** Es ist ein komplizierter Prozess, daher kann nicht geholfen werden, wenn er schwer zu lesen ist **. Überlegen Sie in diesem Fall, ob Sie ein Entwurfsmuster verwenden können. Möglicherweise gibt es dort eine Lösung. damit. Wenn es ein Designmuster ist.
Erinnern Sie sich an die Prüfungen, die Sie als Student hatten. Hat der Lehrer nicht "Bitte überprüfen" gesagt? Egal wie gut die Schüler sind, sie werden Fehler machen. Es war eine Überprüfung, um dies zu verhindern.
Dies gilt auch für die Code-Implementierung. Manchmal fand ich es gut, als ich es entwarf und implementierte, aber im Verlauf der Arbeit wurde es zu etwas Schlechtem. Sogar die Person, die schrieb, dass es schrecklich war, hat möglicherweise einen Code wie "Was ist das? Was ist das?"
Lassen Sie uns dem Direktor den Aufwand für die Überprüfung des geschätzten Implementierungsaufwands mitteilen.
Ich denke, dass "sich einfach ohne Probleme bewegen" nur im Rahmen persönlicher Hobbys erlaubt ist. (Sag es dir (blutige Tränen)) Erweiterungen und Fehlerbehebungen werden durchgeführt, solange der Dienst fortgesetzt wird. ** Kannst du sagen, dass der Code für immer für dich sorgen wird? ** ** **
** Wichtige Bewertung. ** ** **
Wenn Sie von Anfang an einfach zu lesenden Code schreiben können, brauchen Sie diese Art von Arbeit möglicherweise nicht ... Nein, egal wie Sie testen, Sie müssen nacharbeiten (ich möchte glauben).
Wenn Sie den bisher funktionierenden Prozess ändern, kann dies zu einem Fehler führen.
Aber es wäre sicher, einen Testcode zu haben. Ich erhalte eine Fehlermeldung, wenn ich den Test durchführe! !! Und wenn der Test erfolgreich ist, können Sie ihn vom Debugger mit Vertrauen debuggen lassen.
Der Unit-Test wird auch hier in unserem Adventskalender behandelt. Bitte lesen Sie ihn auch.
Bis Sie Unit-Tests automatisieren können
Auch mein Beitrag ist auch w Über den Test
Nach der Veröffentlichung müssen wir die Maßnahmen umsetzen, so dass diese Bemühungen ziemlich schwierig werden. Außerdem ist Code, der vor seiner Veröffentlichung leicht zu lesen war, mit der Zeit schwieriger zu lesen. Wenn Sie den Service für eine lange und solide Zeit bereitstellen möchten, sollten Sie die Zeit für das Refactoring und die Zeit für die Implementierung von Komponententests auch nach der Veröffentlichung einplanen. Und lasst uns ** allmählich ** verbessern.
Wenn Sie das System an einen Kunden liefern und einen Fehler beheben müssen, führt der schwer lesbare Code zu einer ungenauen Schätzung (ich fürchte, ich möchte zusätzliche Arbeit sparen, aber der Kunde wird dem sicherlich nicht zustimmen. Wenn das passiert, ist der Geist des Verkaufspersonals passend ...). Schwer zu lesender Code ist wirklich sündig.
Ich möchte daran arbeiten, damit der Code, den ich geschrieben habe, zumindest "nicht schwer zu lesen" ist.