Vortrag über „Codestil und Designmuster“ [geschlossen]

Mein Unternehmen (klein, ungefähr 40 Personen in 3 Büros) führt gelegentlich online "Entwickler-Workshops" durch, in denen einer der Entwickler eine Präsentation zu einem technischen Thema veranstaltet. Es geht nicht unbedingt um unsere Arbeit, sondern nur darum, allen zu helfen, ihre Fähigkeiten und ihr Verständnis zu verbessern.

Ich wurde gebeten, das nächste zu hosten, und das Thema (ausgewählt aus einer von mir bereitgestellten Liste) ist Codestil und Entwurfsmuster. Ich weiß, dass diese Dinge nicht so eng miteinander verbunden sind, aber mit mir zu tun haben. Ich habe viele Stellen in unserer Codebasis gesehen, die verbessert werden könnten, einige davon könnten sich sogar für DailyWTF qualifizieren. Deshalb möchte ich, dass diese Präsentation so effektiv wie möglich ist. Das Problem ist, dass ich einfach nicht genau weiß, was ich in einer Stunde abdecken soll.

Meine erste Idee ist es, unseren eigenen Code als Beispiel zu verwenden, um den Punkt "Bitte wenden Sie dies tatsächlich auf Ihre Arbeit an" nach Hause zu fahren. Aber das Thema ist so weit gefasst.

Einige Dinge, die mit unserem Code (PHP) nicht stimmen, sind:

• Minimale OO. Es hat sich in letzter Zeit verbessert, aber es gibt immer noch Tonnen von globalen Funktionen. Ich brauche eine Weile, um Dinge zu finden.
• Globale Konfiguration (Meinung, denke ich). Sie können $ GLOBALS ['blah'] in fast jeder Datei finden.
• Inkonsistenter Klammerstil. Klingt minimal, aber dies hat tatsächlich dazu geführt, dass vor fünf Tagen ein Syntaxfehler auf den Ursprung gebracht wurde, der bis gestern noch nicht korrigiert wurde.
• Ineffiziente Konstrukte. Ich konnte einige grundlegende Verbesserungen vornehmen, die die Laufzeit in einigen Bereichen um 70% verkürzten.

Ich möchte, dass dieses Ding so nützlich wie möglich ist, ohne sich für meine Kollegen herablassend anzuhören. Auf welche Aspekte des "Stils" sollte ich mich konzentrieren und welche Entwurfsmuster könnten am nützlichsten zu erklären sein?

Seien Sie äußerst vorsichtig, wenn Sie echten Code in einer Präsentation vor den Personen verwenden, die diesen Code schreiben.

Bestenfalls werden Sie Ihr Team verärgern, indem Sie den Finger vor allen auf sie richten. Und was Sie anstelle von "Sie haben mir wirklich die Augen geöffnet" erhalten, ist "WTF vor allen? Haben Sie sich sogar Ihren eigenen Code dumm angesehen?"

Nehmen Sie ein echtes Beispiel, aber ändern Sie es oder stellen Sie sicher, dass es nicht auf den zurückgeführt werden kann, der es geschrieben hat. Oder nimm echten Code von Leuten, die du kennst, aber nimm auch etwas von DEINEM alten Code und spiele Humor und Insider-Witz mit diesen Leuten, Standup-Stil :)

So beantworten Sie Ihre ursprünglichen Fragen: Alles, was mit Lesbarkeit zu tun hat: Funktionen mit möglichst wenigen Argumenten, OOP, langer und detaillierter Variablenname und Kommentare.

Ich vermute, dass Sie ein Bug-Tracking-System in Ihrer Organisation haben. Ziehen Sie einige der schlimmsten Fehler aus dem Repository heraus, lesen Sie den Fixbericht darüber, warum dies passiert ist (globale Variablen sind schief gegangen, Funktionen, die Dinge tun, für die sie nicht gedacht waren usw.), und diskutieren Sie dann Codierungsstile und Entwurfsmuster, die zur Vermeidung dieses Problems hätten beitragen können .

Es ist einige harte Arbeit dieses wenig Forschung zu tun, aber das ist der stärkste Weg nach Hause zu fahren , was Sie präsentieren tut wirklich Arbeit .

"Immer noch Tonnen globaler Funktionen".

Holen Sie sich zuerst eine Liste. Komplett ist ideal.

Zweitens partitionieren Sie diese Liste in potenzielle Klassen. Denken Sie an die Klassendefinitionen.

Wählen Sie während der eigentlichen Präsentation die größte, offensichtlichste, auffälligste und am wenigsten umstrittene potenzielle Klasse aus, die eine Reihe dieser globalen Funktionen absorbieren würde.

Als Diskussionsthema. Du hast eine Idee. Sie müssen einen Konsens erzielen. Und beantworte unterwegs Fragen. Und helfen Sie ihnen zu verstehen, warum es sich um eine einzelne Klasse von Objekten handelt, nicht um eine Reihe zufälliger Funktionen, die sich globale Elemente teilen.

Dann, nachdem Sie dies bis zu dem Punkt besprochen haben, an dem sie nur diese Klasse verstehen und wie Sie zu den Inhalten gekommen sind ...

Schalten Sie den Projektor ein.

Beginne zu tippen.

Korrigieren Sie den Code. Führen Sie Ihre Unit-Tests erneut aus.

Entwerfen Sie Muster und Codierungsstil und arbeiten Sie. Alles in einem Paket.

In 1 Stunde sind Sie gut darin, ein Minimum an Verständnis für die Grundlagen zu vermitteln.

Ich schlage vor, 3 Dinge aus jedem Thema auszuwählen und mich auf diese zu konzentrieren. Beschränken Sie die Folien auf 5-7 Wörter, damit die Leute Ihnen zuhören, anstatt die Folien zu lesen. Verwenden Sie erfundene Beispiele (damit Sie den Menschen nicht gemäß den Vorschlägen anderer auf die Zehen treten). Geben Sie am Ende Referenzen an (URLs sind besser als Bücher) als Übung für diejenigen, die mehr lernen möchten. Veröffentlichen Sie Ihre Folien nach Ihrer Präsentation in Ihrem Intranet . (Verwenden Sie für das Problem mit geschweiften Klammern einen Code-Formatierer. Dies ist wahrscheinlich keine Schlacht, die es wert ist, gekämpft zu werden.)

Vorgeschlagene Themen:

• Codierungsstil

  • Das Zen von OOP in PHP: Codieren mit Stil!
  • 5 Gründe, warum globale Funktionen Code-Krebs verursachen
  • Was ist in einem Namen? Konventionen und gesunder Menschenverstand (oder bringen Sie mich nicht zum Nachdenken!)

• Designmuster

  • Einige GoF-Muster in unserem Code; eine Einleitung
  • Muster sind nur Werkzeuge, kein Evangelium
  • Das Beste und das Schlimmste: Muster und Anti-Muster

Hinweis: Globale Konfigurationen sind manchmal schwer zu vermeiden. Eine einfache Lösung besteht darin, alle Verweise auf sie in eine Init-Funktion zu setzen

Vorbehalt: Ich kenne nur genug PHP, um WordPress zu brechen und kleinere Website-Korrekturen durchzuführen

Informationen zur Verwendung von echtem Code in der Präsentation - falls verwendet, verwenden Sie ihn nur für die guten Beispiele, NIEMALS für die schlechten Beispiele. Für die Schlechten, machen Sie Ihre eigenen oder finden Sie es im Internet. Dies ermöglicht Ihren Mitarbeitern, stolz auf ihre Arbeit zu sein und Anerkennung dafür zu erhalten. Es vermeidet auch das Szenario, in dem sie möglicherweise verärgert / verlegen sind, weil sie als schlechter Entwickler herausgegriffen wurden.

Codierungsstile sind schlechte Gewohnheiten. Schwer loszuwerden. Der beste Weg, jemanden eine schlechte Angewohnheit fallen zu lassen? Lassen Sie ihn aus erster Hand sehen, wie hässlich, widerlich oder schädlich es ist.

Zeigen Sie ihnen schlechten Code, fragen Sie sie, was daran schlecht ist. Lassen Sie sie eine Sekunde darüber nachdenken und geben Sie ihnen dann ein "Aaahaaa!" Moment, indem wir ihnen einen Randfall zeigen (Fencepost-Problem vielleicht?) oder einen Fall, in dem ihr schlechtes Design alles andere zusammenbricht.

Ihre Jungs leiden anscheinend regelmäßig unter schlechten Designproblemen. Zeigen Sie ihnen ein Beispiel dafür, wie eine globale Funktion, die sich auf unschuldige Weise geändert hat, andere Funktionen abhängig davon schädigt, ohne zu wissen, dass sie geändert wurde. Zeigen Sie ihnen ein klassisches Synchronisationsproblem mit der globalen Variablen.

Mach es auf eine lustige Art, sie zu engagieren, anstatt sie zu langweilen oder sie dazu zu bringen, Verteidigungspositionen einzunehmen (wer ist dieser Typ, der uns kritisiert?); Zeigen Sie ihnen beispielsweise eine Funktion, die ihre Arbeit in zwei Schritten erledigt (1 - geben Sie den Namen der Frau ein) (2 - speichern Sie sie in global) (3 - geben Sie den Namen des Mannes ein und nehmen Sie den Namen der Frau von global, um sie in der Datenbank zu speichern) (4 - lachen Sie als Eine schlechte Synchronisation führt dazu, dass Männer „neue“ Frauen haben. Ein Witz schlägt vor, eine Scheidungsstatistikfunktion zu schreiben.

Der Glaube kann den Programmierstil beeinträchtigen, weil wir programmieren, was wir denken, und wenn das Programmdesign kritisiert wird, nehmen einige Leute es als Beleidigung für ihre Denkweise und damit für ihre Intelligenz, also müssen Sie einen unterhaltsamen Ansatz wählen.

Übernehmen Sie Ihre schlechten Funktionen, verbergen Sie sie mit einigen Änderungen, um den Codebesitzer nicht in Verlegenheit zu bringen, und arbeiten und interagieren Sie mit dem Publikum, um sie zu verbessern. Ergebnis: Ihr Quellcode-Kontrollsystem ist am nächsten Morgen so beschäftigt, dass Sie sich einen Kaffee holen und über die Änderungsprotokolle lächeln.