Wenn Softwareentwickler einen Code betrachten, ist die erste Frage, die sie sich stellen: „Was macht er?“ Die nächste Frage ist: „Warum macht er das?“ Tatsächlich besteht eine tiefe Verbindung zwischen diesen beiden – warum wird was auf der nächsten Abstraktionsebene. Das heißt, Was und Warum sind Spiegelbilder voneinander über eine Abstraktionsgrenze hinweg. Dieses Verständnis kann Ingenieuren dabei helfen, besser wartbare und lesbare Software zu schreiben.
Ein Beispiel soll das obige Prinzip verdeutlichen. Angenommen, wir arbeiten an einer Django-Webanwendung und möchten Benutzer, die sich schon länger nicht mehr angemeldet haben, daran erinnern, wie großartig unsere Webanwendung ist. Angenommen, wir haben den folgenden Code:
def remind_users_we_are_awesome(): users = User.objects.filter( last_login__lte=timezone.now() - timedelta(days=7), last_login__gte=timezone.now() - timedelta(days=14) ) for u in users: message = EmailMessage( subject='Diese Website ist super', message='Du verpasst was!', from='from@example.com', to=user.email, ) message.send()
Was macht dieser Code? Zunächst führt er eine Datenbankabfrage aus. Warum? Es sieht so aus, als würde er die Ergebnisse durchlaufen und eine E-Mail-Nachricht erstellen. Der Grund ist unklar.
Wir können erkennen, dass dieser Code Abstraktionsebenen vermischt, da es keine klare Trennung zwischen Was und Warum gibt, keinen klaren Punkt, an dem aus einem Warum ein Was wird. Betrachten Sie stattdessen diesen Code:
Klasse UserQuerySet (Modelle.QuerySet): def idle(): return self.filter (last_login__lte=timezone.now() – timedelta(Tage=7), last_login__gte=timezone.now() – timedelta(Tage=14))
Was macht dieser Code? Er führt eine Datenbankabfrage aus. Warum? Der Methodenname verrät es uns: um inaktive Benutzer abzurufen. Schauen wir uns nun die nächste Ebene an:
def remind_users_we_are_awesome(): für u in User.objects.idle(): send_reminder_email(u)
Was macht dieser Code? Er listet die inaktiven Benutzer auf. Warum? Um ihnen Erinnerungs-E-Mails zu senden. Beachten Sie, wie der warum Antwort von vorhin wurde die was Nun – auf der vorherigen Ebene haben wir Datenbankabfragen gesehen. Auf dieser Ebene sehen wir inaktive Benutzer. Daran erkennen wir, dass wir eine Abstraktionsgrenze überschritten haben – Was und Warum tauschen die Plätze. Diese Konzepte weisen eine schöne Symmetrie auf.
Dieser Code ist auch wiederverwendbarer. Wir haben ein Konzept entwickelt, Leerlauf, das immer dann verwendet werden kann, wenn wir inaktive Benutzer betrachten.
Wenn wir dieses Was/Warum-Framework zum Schreiben von Methoden verwenden, sagt uns jeder Methodenname warum Die Methode führt die Aufgaben in ihrem Hauptteil aus. Beachten Sie jedoch, dass jede Methode aus anderen Methoden besteht. Wenn diese Methoden dieser Regel folgen, erhalten wir eine Reihe von Anweisungen, die die Ziele der darunterliegenden Methoden zusammenfassen. Dies führt zu einer selbsterklärenden Codebasis; Entwickler müssen kein mentales Modell der Computeraktionen haben, um den Code zu lesen. Sie können einige aussagekräftige mentale Symbole verwenden, wie z. B. Leerlauf Konzept oben. Das bedeutet weniger kognitive Belastung und weniger Entwicklungsaufwand für die Änderung des Codes und das Schreiben neuer Funktionen.
Diese Methodentrennung würde sich aus Sandi Metz' 5-Linien-Methode, wobei wir uns auf Methoden beschränken, die maximal fünf Zeilen lang sind. Die Verwendung so kurzer Methoden zwingt Entwickler dazu, jede Aktion zu kapseln und zusammenzusetzen; die hier gemachten Beobachtungen über warum und was sollte hoffentlich eine anschauliche Theorie liefern, warum solche kurzen Methoden nützlich sind.
