najlepszy sposób na „wprowadzenie” OOP / OOD do zespołu doświadczonych inżynierów C ++

Czy szukam skutecznego sposobu, który również nie jest obelgą, aby wprowadzić koncepcje OOP do istniejących członków zespołu? Moi koledzy z zespołu nie są nowi w językach OO. Robimy C ++ / C # od dawna, więc sama technologia jest znana.

Jednak rozglądam się i bez większego wysiłku (głównie w formie recenzji kodu), wydaje się, że produkujemy kod C, który zdarza się wewnątrz klas. Prawie nie ma zastosowania zasada pojedynczej odpowiedzialności, abstrakcje ani próby zminimalizowania sprzężenia, żeby wymienić tylko kilka. Widziałem klasy, które nie mają konstruktora, ale ustawiają memset na 0 za każdym razem, gdy są tworzone.

Ale za każdym razem, gdy uruchamiam OOP, wszyscy zawsze kiwa głową i sprawia wrażenie, jakby wiedzieli dokładnie, o czym mówię. Znajomość pojęć jest dobra, ale wydaje się, że my (niektórzy bardziej niż inni) bardzo ciężko jest je zastosować, jeśli chodzi o wykonanie rzeczywistej pracy.

Recenzje kodu są bardzo pomocne, ale problem z recenzjami kodu polega na tym, że pojawiają się one dopiero po fakcie, więc niektórym wydaje się, że ostatecznie przepisujemy (to głównie refaktoryzacja, ale wciąż zajmuje dużo czasu) napisany właśnie kod. Również recenzje kodu przekazują opinie tylko innemu inżynierowi, a nie całemu zespołowi.

Bawię się pomysłem robienia prezentacji (lub serii) i próbuję ponownie przywołać OOP wraz z kilkoma przykładami istniejącego kodu, który mógł zostać napisany lepiej i który mógłby zostać ponownie opracowany. Mógłbym użyć naprawdę starych projektów, których nikt już nie ma, więc przynajmniej ta część nie powinna być delikatną kwestią. Czy to jednak zadziała? Jak powiedziałem, większość ludzi używa C ++ od dawna, więc zgaduję, że a) usiądą i zastanowią się, dlaczego mówię im rzeczy, które już znają lub b) mogą uznać to za zniewagę, ponieważ jestem mówiąc im, że nie wiedzą, jak wykonać pracę, którą wykonują od lat, jeśli nie od dziesięcioleci.

Czy istnieje inne podejście, które dotarłoby do szerszego grona odbiorców niż przegląd kodu, ale jednocześnie nie czułoby się jak wykład karny?

Nie jestem świeżo upieczonym studentem college'u, który ma utopijne ideały doskonale zaprojektowanego kodu i nie oczekuję tego od nikogo. Piszę to dlatego, że właśnie dokonałem przeglądu osoby, która rzeczywiście miała przyzwoity projekt na wysokim poziomie na papierze. Jeśli jednak wyobrażasz sobie klasy: A -> B -> C -> D, w kodzie B, C i D wszystkie implementują prawie ten sam interfejs publiczny, a B / C mają jedną funkcję liniową, dzięki czemu najwyższa klasa A robi absolutnie cała praca (do zarządzania pamięcią, parsowania ciągów, negocjacji konfiguracji ...) przede wszystkim w 4 metodach mongo i, dla wszystkich celów i celów, wywołuje prawie bezpośrednio do D.

Aktualizacja: Jestem liderem technologicznym (6 miesięcy w tej roli) i mam pełne wsparcie kierownika grupy. Pracujemy nad bardzo dojrzałym produktem, a koszty utrzymania zdecydowanie dają się poznać.

Dlaczego nie opracujesz krótkiego szkolenia w zakresie zasad SOLID i nie zapewnisz im tego szkolenia? Wydaje się, że w mojej obecnej organizacji działało całkiem nieźle i uważam, że krótkie szkolenia są naprawdę zabawne (dla wszystkich zaangażowanych).

Kiedy prowadziłem szkolenie, poświęciłem trochę czasu na poszukiwanie patologicznych „złych” przykładów w istniejącym kodzie (różnych projektów) i ponownie je ułożyłem w prezentacji, krok po kroku, stosując zasady. To pokazało

1. Te refaktoryzacje nie są trudne
2. To nie zajmuje dużo czasu
3. Wynik końcowy (starannie wybrany ;-)) jest wyraźnie lepszy niż oryginalny kod.

Recenzje kodu są bardzo pomocne, ale problem z recenzjami kodu polega na tym, że pojawiają się one dopiero po fakcie.

W ramach jednego projektu wykonaliśmy recenzje projektowe.

15 minut. Na białej tablicy. Omów projekt przed kodowaniem.

Najważniejszą częścią jest zaplanowanie przeglądu projektu przed prac wdrożeniowych.

Mieliśmy również „Krytyczne recenzje projektowe”, które były dużą, spoconą transakcją. Wymagały one wielu dokumentów i długiej prezentacji. Były trudne do zaplanowania i prawie zawsze były wypychane aż do momentu rozpoczęcia kodowania, zmniejszając ich wartość do zera.

Nieformalne przeglądy projektu - przed kodowaniem - brak nacisku - brak dokumentacji - pozwala na lepszą dyskusję na temat przypisywania obowiązków i współpracy obiektów.

Zakładam, że jesteś młodszy od niektórych programistów, ale wyżej w łańcuchu pokarmowym.

Ryzykując pogrzebanie się w negatywnych opiniach, może być tak, że „doświadczeni inżynierowie” faktycznie postępują właściwie - lub ponieważ jest to dojrzały produkt, który może istnieć już od dziesięcioleci, co kiedyś było słuszne.

Starsze kody są zazwyczaj zoptymalizowane pod kątem szybkiego działania na sprzęcie tamtych czasów; oznacza to między innymi obniżenie poziomów dziedziczenia i unikanie wywołań funkcji / metod dla trywialnych operacji.

Kompilatory stały się znacznie mądrzejsze na przestrzeni lat, więc nie wszystko, co kiedyś było prawdą, jest na przykład - na przykład kompilator może zdecydować się na wprowadzenie niewielkiej funkcji.

Być może drogą do przodu byłoby przyjęcie innego podejścia - poproś programistów o wyjaśnienie, dlaczego / dlaczego ich metoda jest lepsza niż teoria, której cię nauczono - i bądź szczery.

Naciskanie na testy jednostkowe przy 100% zasięgu każdej nowej / zmienionej metody nie doprowadziłoby do zminimalizowania sprzężenia między metodami.

Możesz wziąć książkę „Wzory projektowe” z Gangu Czterech. Nie jest on specyficzny dla C ++, więc nie krytykujesz wiedzy swoich kolegów w C ++, kiedy się do niej odwołujesz. Jednocześnie zajmuje się tematami, które uważasz za istotne. Książka jest również powszechnie uznawana za odpowiednią, dlatego nie można jej łatwo odrzucić jako teoretycznej lub niepraktycznej.

Z drugiej strony weź pod uwagę, że C ++ nie jest czystym językiem OO, ani w designie, ani w praktyce. Cała historia konstruktora / memsetu powinna brzmieć, że powinieneś przedstawić RAII, która wcale nie jest techniką OO, ale jest specyficzna dla C ++ (niestety - IDispose .Net pokazuje, co się dzieje, gdy RAII jest refleksją). Odpowiednie książki tutaj to (Więcej) Skuteczne C ++ i (Więcej) Wyjątkowe C ++.