Share
Code-Gerüche und ihre Refactorings können für Neulinge sehr entmutigend und einschüchternd sein. In dieser Serie habe ich versucht, sie für leicht erfahrene Ruby-Entwickler und Anfänger gleichermaßen verständlich zu machen.
In diesem abschließenden Artikel werden einige Gerüche erwähnt, auf die Sie achten sollten, und fasst zusammen, was diese Kleinserie erreichen wollte. Ein letzter Hauch, wenn du magst…
Der letzte Artikel dieser Serie ist so etwas wie eine Bonusrunde. Ich wollte Ihnen einige weitere Gerüche vorstellen, die schnell und ohne großen Aufwand angesprochen werden können. Eine für die Straße, sozusagen. Ich denke, mit dem Wissen, das Sie aus den vorherigen Artikeln gesammelt haben, werden die meisten nicht einmal Codebeispiele benötigen, um Ihren Kopf zu wickeln.
Wenn Sie ein Buch über Refactoring öffnen, werden Sie leicht mehr Gerüche finden, als wir besprochen haben. Mit diesen großen unter Ihnen sind Sie jedoch gut gerüstet, um mit jedem von ihnen fertig zu werden.
Großzügig angewandte Kommentare sind selten eine gute Idee - wahrscheinlich nie. Warum nicht? Weil dies möglicherweise darauf hindeutet, dass Ihr Design nicht für sich selbst spricht. Das bedeutet, dass Ihr Code wahrscheinlich so kompliziert zu verstehen ist, dass er wörtliche Erklärungen benötigt.
Zuallererst, wer durch Ihren Code eine Vielzahl von Texten durchgehen möchte - oder, noch schlimmer, durch Code, der schwer zu verstehen ist. Jackpot, wenn beides häufig vorkommt. Das ist nur eine schlechte Form und nicht sehr rücksichtsvoll von Menschen, die nach Ihnen kommen - keine Beleidigung, Masochisten, quälen Sie Ihr zukünftiges Selbst, so viel Sie wollen.
Sie möchten Code schreiben, der in sich selbst ausreicht. Erstellen Sie Klassen und Methoden, die für sich selbst sprechen. Im besten Fall erzählen sie eine Geschichte, die leicht zu verfolgen ist. Das ist wahrscheinlich einer der Gründe Konventionen über Konfigurationen wurde so einflussreich. Das Rad neu zu erfinden ist sicherlich manchmal eine gute Methode, um Ihr Verständnis zu verbessern und neue Gebiete zu erkunden. In schnelllebigen Entwicklungsumgebungen suchen Ihre Kollegen jedoch nach Klarheit und schneller Navigation - nicht nur in Ihren Dateien, sondern auch in der von Ihnen erstellten Mental Map in Ihrem Code.
Ich möchte nicht in ein ganz neues Thema eintauchen, aber die Namensgebung spielt dabei eine große Rolle. Exzessive Kommentare innerhalb Ihres Codes widersprechen ein wenig der guten Benennungspraxis und Konventionen. Verstehen Sie mich nicht falsch, es ist in Ordnung, Kommentare hinzuzufügen. Bleiben Sie einfach auf dem Pfad, der Ihren Code „beleuchtet“, anstatt davon abzulenken. Kommentare sollten auf keinen Fall Anweisungen für schlauen Code sein, den Sie meistens entschlüsseln können, weil Sie sich zeigen wollten. Wenn Sie Ihre Methoden einfach halten, wie Sie sollten, und alles mit Bedacht benennen, dann müssen Sie zwischen Ihrem Code keine ganzen Romane schreiben.
Halten Sie sich von folgendem fern:
Es ist auch nützlich, Teile von Methoden über zu extrahieren Methode extrahieren und diesem Teil einer Methode einen Namen zu geben, der uns von ihrer Verantwortung erzählt - anstatt alle Details auf ein höheres Verständnis der Vorgänge im Körper der Methode zu bringen.
def create_new_agent… end… # Neuen Agenten erstellen. Besuchen Sie root_path click_on 'Create Agent' fill_in 'Agent Name', mit: 'Jinx' fill_in 'Email', mit: '[email protected]' fill_in 'Password', mit: 'secretphrase 'click_button' absenden '…
Was ist leichter zu lesen? Ein Kinderspiel natürlich! Nutzen Sie den kostenlosen Kilometerstand, indem Sie die Dinge über extrahierte Methoden richtig benennen. Es macht Ihren Code so viel intelligenter und leichter zu verdauen - und natürlich die Vorteile des Refactorings an einem Ort, wenn er wiederverwendet wird. Ich wette, das wird dazu beitragen, Ihre Kommentare um einiges zu reduzieren.
Dies ist ein einfaches. Verwenden Sie keine Rückrufe, die sich nicht auf Persistenzlogik beziehen! Ihre Objekte verfügen über einen persistenten Lebenszyklus, der sozusagen Objekte erzeugt, speichert und löscht, und Sie möchten diese Logik nicht mit anderem Verhalten wie der Geschäftslogik Ihrer Klassen "verschmutzen".
Halten Sie es einfach, erinnern Sie sich? Typische Beispiele, die vermieden werden sollten, sind das Versenden von E-Mails, die Verarbeitung von Zahlungen und dergleichen. Warum? Da das Debuggen und Refactoring Ihres Codes so einfach wie möglich sein sollte und unübersichtliche Rückrufe den Ruf haben, diese Pläne zu beeinträchtigen. Rückrufe machen es ein bisschen zu einfach, das Wasser zu trüben und sich mehrmals in den Fuß zu schießen.
Ein weiterer problematischer Punkt bei Rückrufen ist, dass sie die Implementierung von Geschäftslogik in Methoden wie verbergen können #sparen oder #erstellen. Seien Sie also nicht faul und missbrauchen Sie sie, nur weil es praktisch erscheint!
Die größte Sorge ist natürlich die Kopplung von Bedenken. Warum lassen Sie die Methode erstellen SpectreAgent, zum Beispiel mit der Lieferung von a #mission_assignment oder so? Wie so oft, nur weil wir es einfach machen können, heißt das nicht, dass wir es sollten. Es ist ein garantierter Biss im Arsch, der darauf wartet, geschehen zu können. Die Lösung ist eigentlich ziemlich unkompliziert. Wenn das Verhalten eines Rückrufs nichts mit Beharrlichkeit zu tun hat, erstellen Sie einfach eine andere Methode, und Sie sind fertig.
Eine schlechte Namenswahl hat schwerwiegende Folgen. Tatsächlich verschwenden Sie die Zeit anderer Leute - oder sogar Ihre eigene, wenn Sie diesen Code in Zukunft erneut besuchen müssen. Der Code, den Sie schreiben, ist ein Satz von Anweisungen, die von Ihnen und anderen gelesen werden müssen. Eine rein logische, super prosaische, zu kluge oder, schlimmer, einfache, faule Herangehensweise, Dinge zu benennen, ist eines der schlimmsten Dinge, die Sie zurücklassen können. Bemühen Sie sich, Ihren Code verständlicher zu machen, indem Sie bessere Namen angeben.
Klarheit übertrifft an jedem Tag der Woche falsche Klugheit oder unnötige Prägnanz! Arbeiten Sie hart an der Benennung von Methoden, Variablen und Klassen, die es leicht machen, einem Thread zu folgen.
Ich möchte nicht so weit gehen und sagen, dass Sie versuchen sollten, eine Geschichte zu erzählen, aber wenn Sie können, versuchen Sie es! Maschinen sind nicht diejenigen, die Ihren Code „lesen“ müssen - er wird natürlich von ihnen ausgeführt. Vielleicht ist das der Grund, warum der Begriff "Software Writer" in letzter Zeit ein wenig auf mich zugenommen hat. Ich sage nicht, dass der Engineering-Aspekt gemindert werden sollte, aber das Schreiben von Software ist mehr als das Schreiben seelenloser Anweisungen für Maschinen. Zumindest eine Software, die elegant ist und Freude beim Arbeiten macht.
Faul dich nicht aus, wenn sich herausstellt, dass dies viel schwieriger ist, als du gedacht hast. Die Benennung ist bekanntermaßen schwer!
Mixins sind ein Geruch? Nehmen wir an, sie können stinken. Mehrfachvererbung durch Mixins kann nützlich sein, aber es gibt ein paar Dinge, die sie weniger nützlich machen, als Sie gedacht haben, als Sie mit OOP angefangen haben:
Ich schlage vor, Sie lesen ein wenig über "Zusammensetzung über Erbschaft". Das Wesentliche dabei ist, dass Sie sich mehr auf die Wiederverwendung eigener, getrennt zusammengestellter Klassen als auf Vererbung oder Unterklassifizierung verlassen sollten. Mixins sind eine Form der Vererbung, die gut genutzt werden kann, aber auch etwas, bei dem Sie etwas misstrauisch sein sollten.
Achten Sie auf wiederholte Übergabe derselben Argumente in Ihre Methoden. Dies deutet oft darauf hin, dass sie eine Beziehung haben, die in eine eigene Klasse extrahiert werden kann. Dies wiederum kann die Eingabe dieser Methoden mit Daten drastisch vereinfachen, indem die Größe der Argumente reduziert wird. Ob es sich lohnt, eine neue Abhängigkeit einzuführen, müssen Sie jedoch abwägen.
Dieser Geruch ist eine andere Form subtiler Vervielfältigung, mit der wir besser umgehen können. Ein gutes Beispiel ist das Übergeben einer langen Liste von Argumenten, aus denen eine Adresse und Kreditkarteninformationen bestehen. Warum nicht alles in eine vorhandene Klasse packen oder zuerst eine neue Klasse extrahieren und stattdessen die Adress- und Kreditkartenobjekte übergeben? Eine andere Möglichkeit, darüber nachzudenken, besteht darin, ein Entfernungsobjekt anstelle von Anfang und Ende zu haben. Wenn Sie Instanzvariablen haben, die auf diesen Geruch fallen, ist das Extrahieren einer Klasse eine Überlegung wert. In anderen Fällen a Parameterobjekt könnte die gleiche Qualität der Abstraktion bieten.
Sie wissen, dass Sie einen kleinen Gewinn erzielt haben, wenn Ihr System einfacher zu verstehen ist und Sie ein neues Konzept wie eine Kreditkarte gefunden haben, das Sie in ein Objekt kapseln könnten.
Herzliche Glückwünsche! Sie haben Ihre OOP-Fähigkeiten erheblich verbessert! Der Status auf Boss-Ebene nähert sich. Nein, im Ernst, großartige Arbeit, wenn dieses Thema für Sie eher neu war!
Als letzte Empfehlung möchte ich, dass Sie eine Sache mitnehmen. Bitte denken Sie daran, dass es kein Rezept gibt, das immer funktionieren wird. Sie müssen jedes Problem anders abwägen und oft verschiedene Techniken kombinieren, um Ihre Anforderungen zu erfüllen. Auch für den Rest Ihrer Karriere ist dies höchstwahrscheinlich etwas, mit dem Sie nie aufhören werden, zu kämpfen. Ich denke, ein guter Kampf ist ein kreativer und herausfordernder Kampf.
Dies ist eine kleine Vermutung, aber ich glaube, wenn Sie die meisten der von uns behandelten Themen verstanden haben, sind Sie auf dem besten Weg, Code zu schreiben, den andere Entwickler gerne entdecken. Vielen Dank für Ihre Zeit beim Lesen dieser kleinen Serie und viel Glück, ein glücklicher Hacker zu werden!
Accentsconagua