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

17

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ć.

DXM
źródło
3
Czy jesteś w jakikolwiek sposób ich przełożonym lub szefem? Jeśli nie, czy masz wsparcie dyrektora technicznego, który jest szefem was wszystkich? Jeśli jesteś tylko jednym z facetów, a rozwój był stały i produktywny od lat bez korzystania z głębokich projektów OOP, czeka Cię ciężka bitwa, aby przekonać programistów, że działający kod nie działa, a zarządzanie nie marnuje go. lepiej wydane pieniądze na generowanie kodu.
Patrick Hughes,
Po zrobiłem ten post, związanych z tym pojawiło się, że to brzmi bardzo podobnie do mojej sytuacji: programmers.stackexchange.com/questions/43214/... . Martwię się o dokładnie to samo. Problem polega na tym, że ich zespół miał 2 programistów i zdecydowanie mogłem to zrobić za pomocą recenzji kodu. Szukam podejścia, które pasowałoby do naszego zespołu (10+) Po prostu nie mogę komunikować się z każdym programistą jeden na jednego tak bardzo, jak bym tego chciał.
DXM

Odpowiedzi:

5

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.
Joris Timmermans
źródło
5

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.

S.Lott
źródło
tak, robimy już recenzje projektowe dokładnie tak, jak je opisałeś. Problemem są zadania średniej wielkości. Jeśli zadanie jest wystarczająco duże, generalnie poświęcam czas na opracowanie początkowego schematu klas, który następnie zostaje dopracowany przez zespół. Jeśli zadanie jest małe, to istniejący projekt wysokiego poziomu jest już wystarczająco dobry. Jednak w przypadku średnich zadań nie jestem w stanie wystarczająco dobrze przemyśleć projektu, więc podstawową zasadą jest „kieruj się rozsądkiem i postępuj zgodnie z OOP”. Gdybym miał wykonać te zadania sam, zacznę od kodowania i przeplatam to z ciągłym refaktoryzowaniem i ...
DXM,
... pozwól kodowi zdecydować, jak będzie wyglądał ostateczny projekt. Jednak, gdy zostawiam te zadania niektórym członkom zespołu, to, co czasami znajduję w przeglądzie kodu, to takie rzeczy, które opisałem w moim pierwszym poście.
DXM
1
@DXM: Co? Robisz je? A może ich nie robisz? Jeśli duże, to nie robisz recenzji projektów - projektujesz dla kogoś innego - kto uczy się, kiedy projektujesz? Jeśli małe, to nie robisz recenzji projektów - „istniejący projekt jest wystarczająco dobry” - kto pochyla się, gdy ignorujesz projekt? Jeśli średnie, nie projektujesz i nie oceniasz ich projektów? To nie brzmi tak, jakbyś faktycznie robił recenzje projektów. Dlaczego mówisz, że jesteś, a następnie podajesz trzy przykłady, których nie ma?
S.Lott,
@Lott: po refleksji nad twoją odpowiedzią, mój jedyny wniosek jest taki, że masz absolutną rację. Chyba powinienem powiedzieć, że co najmniej 8 razy przywołałem ten dokładny pomysł i wszyscy zawsze się z tym zgadzali, ale tak, jeśli spojrzę wstecz na rytm, na którym się zdecydowaliśmy, tak naprawdę nie robimy tego. Chciałbym omówić to dalej, ale już zdyscyplinowano mnie modami za prowadzenie dyskusji na stronie o czysto pytań i odpowiedzi. Czy możemy przejść do czatu? Chciałbym bardziej wyjaśnić sytuację i być może wybrać mózg (lub kogoś, kto chce się przyłączyć). Nigdy nie robiłem czatu, wiesz jak to działa?
DXM
@DXM: Czat jest trywialny. I nie jest zbyt pomocny. Jeśli masz dodatkowe pytania - bardziej szczegółowe niż to pytanie początkowe - powinieneś zadać te bardziej szczegółowe pytania. O to chodzi. W kilku przypadkach „dalsza dyskusja” oznacza „Nie podoba mi się twoja odpowiedź na moje pytanie z następujących powodów ...”, co jest trochę głupie. Nie lubienie odpowiedzi to po prostu nie lubienie odpowiedzi i nie wymaga dyskusji. W kilku przypadkach dyskusja sprowadza się do: „moje pytanie nie jest niejasne, po prostu nie umiesz czytać”. Naprawdę nieprzydatne. Zadaj pytania. Jako pytania
S.Lott,
4

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.

Phil Lello
źródło
0

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

Ian
źródło
UT to dobry pomysł, ale nie jestem przekonany, czy osiągnie to pożądany efekt. Poza tym jedną z podstawowych zasad OO jest to, że sprzężenie między funkcjami jest nieuniknione, więc lepiej uczyń to jawnym i pogrupuj takie sprzężone funkcje w jednej klasie.
MSalters
Zgadzam się, że „łączenie każdej funkcji jest nieuniknione”. Jednak dobry projekt zmniejsza liczbę innych funkcji, z którymi każda funkcja jest również połączona. (Klasa jest tylko środkiem do osiągnięcia tego celu)
Ian
0

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 ++.

MSalters
źródło
2
Ale autorzy wyraźnie stwierdzają, że wzorce projektowe nie są ogólnie wprowadzeniem do OOP / OOD! Publiczność powinna najpierw zapoznać się z technikami oferowanymi przez OOP, zanim zacznie nurkować w katalogu wzorców projektowania kodu twardego! „Head First Design Patterns” będzie dobrym wprowadzeniem.
Falcon
2
Z opisu PO wynika, że ​​znają OOP / OOD, po prostu go nie używają (być może z obawy, że byłoby to zbyt skomplikowane), w którym to przypadku książka wyjaśniająca, dlaczego jest przydatna, może motywować najlepiej niż przykłady kodu.
wildpeaks
@wildpeaks: OP jest przeciwny. Nie znają OOP / OOD. Programują OOP w sposób proceduralny. Potrzebują czegoś, aby wprowadzić je w techniki projektowania, a książka GoF nie pasuje do tego scenariusza imho.
Falcon
Odniosłem się do zdań But every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking abouti My teammates are not new to OO languages, ale widzę, jak to jest trochę niejasne, ponieważ mogą kłamać na temat poznania OOP, kiedy OP mówi im o tym.
wildpeaks
1
@MSalters - Wstęp do wzorców projektowych: „Ta książka nie jest wstępem do technologii lub projektowania obiektowego. Wiele książek już dobrze sobie z tym radzi. W tych książkach założono, że jesteś dość biegły w przynajmniej jednym języku programowania obiektowego, a ty powinien mieć także doświadczenie w projektowaniu obiektowym ”. Ta książka nie spełnia wymagań. Powinni przeczytać podstawowe informacje OOD.
Falcon