Prowadzenie prezentacji na temat „stylu kodu i wzorców projektowych” [zamknięte]

Moja firma (mała, około 40 osób w 3 biurach) od czasu do czasu organizuje „warsztaty programistyczne” online, gdzie jeden z deweloperów prowadzi prezentację na jakiś temat techniczny. Niekoniecznie chodzi o naszą pracę, ale po to, aby pomóc wszystkim w doskonaleniu umiejętności i zrozumienia.

Poproszono mnie o zorganizowanie następnego, a tematem (wybranym z listy, którą podałem) jest styl kodu i wzorce projektowe. Wiem, że te rzeczy nie są tak ściśle powiązane, ale trzymajcie się mnie. W naszej bazie kodu widziałem wiele miejsc, które można ulepszyć, niektóre z nich mogą nawet kwalifikować się do DailyWTF, dlatego chcę, aby ta prezentacja była jak najbardziej efektywna. Problem polega na tym, że po prostu nie wiem dokładnie, co pokryć w ciągu godziny.

Moim pierwszym pomysłem jest użycie naszego własnego kodu jako przykładu, aby doprowadzić do tego, że „proszę zastosuj to do swojej pracy”. Ale temat jest tak szeroki.

Niektóre błędy w naszym kodzie (PHP) obejmują:

• Minimalne OO. Ostatnio się poprawia, ale wciąż jest mnóstwo globalnych funkcji. Znalezienie rzeczy zajmuje mi trochę czasu.
• Globalna konfiguracja (chyba opinia). $ GLOBALS ['bla'] można znaleźć w prawie każdym pliku.
• Niespójny styl klamry. Brzmi minimalnie, ale tak naprawdę spowodowało to, że błąd składni został wypchnięty pięć dni temu, co nadal nie zostało poprawione.
• Nieefektywne konstrukcje. Udało mi się wprowadzić kilka podstawowych ulepszeń, które skróciły czas pracy w niektórych obszarach o 70%.

Chcę, aby ta rzecz była tak użyteczna, jak to tylko możliwe, bez protekcjonizmu dla moich współpracowników. Więc na jakich aspektach „stylu” powinienem się skupić i które wzorce projektowe mogą być najbardziej przydatne do wyjaśnienia?

Zachowaj szczególną ostrożność, używając prawdziwego kodu w prezentacji przed osobami, które piszą ten kod.

W najlepszym razie zamierzasz zdenerwować swój zespół, wskazując palcem na wszystkich. Zamiast „Naprawdę otworzyłeś mi oczy” to „WTF przed wszystkimi? Czy nawet spojrzałeś na swój własny głupi kod…”

Weź prawdziwy przykład, ale zmodyfikuj go lub upewnij się, że nie można go przypisać do tego, kto go napisał. Lub weź prawdziwy kod od osób, które znasz, ale także zabierz trochę SWOJEGO kodu i baw się humorem i żartuj z tymi ludźmi, styl standup :)

Aby odpowiedzieć na oryginalne pytania: Wszystko, co dotyczy czytelności: funkcje z jak najmniejszą liczbą argumentów, OOP, długa i szczegółowa nazwa zmiennej oraz komentarze.

Zgaduję, że masz system śledzenia błędów w swojej organizacji. Wyciągnij niektóre z najgorszych błędów z repozytorium, zobacz raport o naprawie, dlaczego tak się stało (zmienne globalne poszły nie tak, funkcje robią rzeczy, do których nie były przeznaczone itp.), A następnie omów style kodowania i wzorce projektowe, które mogłyby pomóc uniknąć tego problemu .

To trochę ciężkiej pracy, aby przeprowadzić te badania, ale jest to najsilniejszy sposób, aby doprowadzić do domu to, co prezentujesz, naprawdę działa .

„wciąż mnóstwo funkcji globalnych”.

Najpierw zdobądź listę. Kompletny jest idealny.

Po drugie, podziel tę listę na potencjalne klasy. Pomyśl o definicjach klas.

Podczas rzeczywistej prezentacji wybierz największą, najbardziej oczywistą, najbardziej rażącą, najmniej dyskusyjną potencjalną klasę, która pochłonąłaby masę tych globalnych funkcji.

Jako temat do dyskusji. Masz pomysł Musisz uzyskać konsensus. I odpowiadaj na pytania po drodze. I pomóż im zrozumieć, dlaczego jest to jedna klasa obiektów, a nie grupa losowych funkcji współdzielących globale.

Następnie, po omówieniu tego do tego stopnia, że ​​rozumieją tylko tę klasę i jak doszedłeś do treści ...

Włącz projektor.

Zacznij pisać.

Napraw kod. Uruchom ponownie testy jednostkowe.

Projektuj wzory, styl kodowania i pracę. Wszystko w jednym pakiecie.

w ciągu 1 godziny poradzisz sobie dobrze, jeśli tylko zrozumiesz podstawy.

proponuję wybrać 3 rzeczy z każdego tematu i skupić się na nich; ogranicz slajdy do 5-7 słów, aby ludzie słuchali cię zamiast czytać slajdy; używaj gotowych przykładów (aby nie nadepnąć ludziom na palce, zgodnie z sugestiami innych); podaj na końcu odnośniki (adresy URL są lepsze niż książki) jako ćwiczenie dla tych, którzy chcą dowiedzieć się więcej; opublikuj slajdy w intranecie po prezentacji. (Jeśli chodzi o problem nawiasów klamrowych, użyj formatera kodu; prawdopodobnie nie jest to bitwa warta walki)

Sugerowane tematy:

• Styl kodowania

  • Zen OOP w PHP: Kodowanie ze stylem!
  • 5 powodów, dla których globalne funkcje powodują raka kodu
  • Co jest w imieniu? Konwencje i zdrowy rozsądek (lub nie każ mi myśleć!)

• Wzorce projektowe

  • Niektóre wzorce GoF w naszym kodzie; wstęp
  • Wzory są tylko narzędziami, a nie ewangelią
  • Najlepsze i najgorsze: wzory i anty-wzory

Uwaga: globalne konfiguracje są czasem trudne do uniknięcia; jednym prostym lekarstwem jest umieszczenie wszystkich odniesień do nich w funkcji init

zastrzeżenie: Wiem tylko tyle PHP, by złamać wordpress i wykonać drobne poprawki strony

O użyciu prawdziwego kodu w prezentacji - jeśli jest używany, używaj go tylko do dobrych przykładów, NIGDY nie do złych przykładów. Na złe, stwórz własny lub znajdź go w sieci. Dzięki temu Twoi współpracownicy mogą być dumni ze swojej pracy i uzyskać jej uznanie. Pozwala to również uniknąć scenariusza, w którym mogą być rozgniewani / zawstydzeni za to, że zostali uznani za złych programistów.

Style kodowania to złe nawyki. Trudno się go pozbyć. Najlepszy sposób, aby pozwolić komuś porzucić zły nawyk? Niech zobaczy z pierwszej ręki, jak brzydka, obrzydliwa lub szkodliwa.

Pokaż im zły kod, zapytaj, co jest w tym złego. Niech pomyślą o tym przez chwilę, a następnie daj im „Aaahaaa!” moment, pokazując im skrzynkę na krawędzi (być może problem z płotem?) lub skrzynkę, w której ich zły projekt zawala wszystko inne.

Wygląda na to, że twoi faceci mają regularne problemy z projektowaniem. Pokaż im jeden przykład tego, jak funkcja globalna zmieniła się w niewinny sposób, uszkadzając inne funkcje w zależności od niej, ale nie wiedząc, że została zmieniona. Pokaż im klasyczny problem synchronizacji ze zmienną globalną.

Zrób to w zabawny sposób, aby ich zaangażować, zamiast ich nudzić lub zmuszać do zajmowania pozycji obronnych (kto to ten facet nas krytykuje?); na przykład pokaż im funkcję, która wykonuje swoje zadanie w dwóch krokach (1- wprowadź imię żony) (2-przechowuj w globalnym) (3-wprowadź imię męża i weź imię żony z globalnego do przechowywania w bazie danych) (4- śmiej się jak zła synchronizacja powoduje, że mężczyźni mają „nowe” żony), ponieważ żart proponuje napisanie funkcji statystyki rozwodów.

Można wierzyć w styl programowania, ponieważ programujemy to, co myślimy, a kiedy krytykuje się projektowanie programów, niektórzy ludzie traktują to jako obrazę ich sposobu myślenia, a co za tym idzie ich inteligencji, więc musisz się do tego dobrze bawić.

Wciel się w swoje złe funkcje, ukryj je z pewnymi zmianami, aby nie zawstydzić właściciela kodu, i współpracuj z publicznością, aby to poprawić. Wynik: Twój system kontroli kodu źródłowego będzie tak zajęty, więc napij się kawy i uśmiechnij się do dzienników zmian.