Wskazówki na temat rozpowszechniania praktyk obiektowych [zamknięte]

Pracuję dla średniej firmy, która ma około 250 programistów. Niestety wiele z nich utknęło w proceduralnym sposobie myślenia, a niektóre zespoły stale dostarczają duże aplikacje skryptów transakcyjnych , podczas gdy w rzeczywistości aplikacja zawiera bogatą logikę. Nie potrafią również zarządzać zależnościami projektowymi i kończą się usługami, które zależą od kolejnej dużej liczby usług (czysty przykład Big Ball of Mud ).

Moje pytanie brzmi: czy możesz zasugerować, jak rozpowszechniać ten rodzaj wiedzy?

Wiem, że problem polega na tym, że aplikacje te mają słabą architekturę i wygląd. Inną kwestią jest to, że niektórzy programiści są przeciwni pisaniu jakiegokolwiek testu.

Kilka rzeczy, które robię, aby to zmienić (ale albo zawodzę, albo zmiana jest za mała, to)

• Prowadzenie prezentacji na temat zasad projektowania (SOLID, czysty kod itp.).
• Warsztaty o TDD i BDD.
• Zespoły trenerskie (w tym korzystanie z sonaru, findbugs, jdepend i innych narzędzi).
• IDE i rozmowy o refaktoryzacji.

Kilka rzeczy, które zamierzam zrobić w przyszłości (ale obawiam się, że mogą nie być dobre)

• Utwórz zespół ewangelistów OO, którzy rozpowszechniają sposób myślenia OO w różnych zespołach (ci ludzie będą musieli zmieniać zespoły co kilka miesięcy).
• Prowadzenie sesji przeglądu projektu, aby skrytykować projekt i zasugerować ulepszenia (nawet jeśli ulepszenia nie zostały wykonane z powodu ograniczeń czasowych, myślę, że może to być przydatne)

.

W zespołach, które trenuję, znalazłem coś, że jak tylko je opuszczę, wracają do starych praktyk. Wiem, że nie spędzam z nimi dużo czasu, zwykle tylko miesiąc. Więc cokolwiek robię, nie przykleja się.

Przykro mi, że to pytanie jest poplamione frustracją, ale alternatywą do napisania tego było uderzenie głową w ścianę, dopóki nie zemdlałem.

Nie próbuj naciskać OOP, tylko pogorszy to sytuację. Nie dlatego, że OOP jest ogólnie złym pomysłem: nie jest. Ale ponieważ wydaje się, że temu, kto jest odpowiedzialny za ten kod włosa, brakuje nie tylko narzędzi pozwalających uniknąć tych problemów, ale także doświadczenia i, co ważniejsze, motywacji.

Ludzie, którzy chcą napisać czysty kod, zrobią to w dowolnym paradygmacie, czy to OOP, proceduralnym, funkcjonalnym itp. Ale nie wszyscy programiści są tacy, i jeśli wrzucisz jakieś narzędzie do czyszczenia czystego kodu osobom, które tego nie robią rozumiem potrzebę, skończysz z tymi narzędziami wykorzystywanymi tak jak narzędzia, które już tam są. Zobaczysz niepowiązane metody pogrupowane w klasy, klasy dziedziczące po niepowiązanych klasach, zestaw widoczności metod oparty na debugowaniu metodą prób i błędów zamiast świadomego projektu, metody statyczne, które nie powinny być statyczne, i metody niestatyczne, które powinny w skrócie zmarnujesz swój czas.

Zamiast tego sprawdź, czy możesz zainwestować w podnoszenie świadomości w zakresie konserwacji i elegancji. W końcu podstawowe cele OOP nie różnią się niczym od żadnej innej strategii zarządzania złożonością (na tym naprawdę polegają paradygmaty programowania): enkapsulacja, modulizacja, luźne sprzęganie, niski stopień współzależności, utrzymanie stanu zmienności i jego zakresu do minimum itp. itd. OOP z pewnością nie jest jedynym paradygmatem, który zapewnia narzędzia potrzebne do osiągnięcia tego celu.

Co prowadzi mnie do ostatniego punktu: OOP to świetny pomysł i działa dobrze na niektóre rodzaje problemów, ale (i mówię zarówno z własnego doświadczenia, jak i parafrazując opinie niektórych wielkich umysłów tutaj) dla wielu rodzajów problemy, jest to całkowicie nieodpowiednie. Kiedy zaczynasz przygodę z OOP, a półprocesowy kod spaghetti jest jedyną znaną Ci alternatywą, OOP naturalnie pojawia się jako podarunek z nieba (i w pewien względny sposób) i prawdopodobnie zbliżysz się wszystkie problemy jak gwoździe do młotka OOP. To tylko naturalne, a doprowadzenie OOP do (i poza) jego ograniczeń jest dobrym sposobem na rozwinięcie umiejętności OOP, więc nie wszystko jest negatywne. Ale może (tylko może) ta konkretna baza kodów nie potrzebuje przecież OOP. Może przydałoby się znacznie więcej architektury proceduralnej,

TL; DR: Jeśli w ogóle chcesz coś ewangelizować, niech to będą (niezależne od platformy) dobre praktyki kodowania, a nie jakikolwiek konkretny paradygmat lub metodologia.

Nie możesz nikogo zmienić, kto już nie chce się zmienić. Dlatego zespoły, które trenowałeś, powróciły do ​​swoich dawnych zwyczajów.

Tak naprawdę twoje pytanie powinno brzmieć „jak sprawić, by programiści chcieli przejść na metody OO?”

Zacznij od prostych, od małych, niech stamtąd zacznie się budować. Pokaż korzyści indywidualnemu deweloperowi zamiast abstrakcyjnych lub filozoficznych korzyści dla kodu, innych programistów lub firmy.

Pokaż, w jaki sposób różne techniki OO doprowadzą do zmniejszenia ilości kodu, który muszą pisać, a także do szybszych czasów programowania. Prawie każdy programista wysłucha propozycji, która ułatwi ich pracę.

Następnie zacznij demonstrować, w jaki sposób techniki OO doprowadzą do łatwiejszego do utrzymania kodu. Wszyscy w tego rodzaju środowisku żyją w strachu przed dokonaniem „ zmiany ”, która zatraca jedną trzecią aplikacji produkcyjnej. Hermetyzacja jest kluczem do uniknięcia tego ryzyka i umożliwia każdej (wkrótce) warstwie aplikacji utrzymanie kontraktu z innymi warstwami.

Spojrzałbym na sposób przekazywania danych. Jeśli jest to długa lista zmiennych za każdym razem, rozważ zawinięcie niektórych z nich w strukturę (lub wstrzymaj klasę !!!) jako wstępny krok. Po prostu zawijanie danych w obiekcie jest początkiem kontraktów między warstwami.

Na szerszym poziomie - jeśli jeszcze tego nie zrobiłeś, rozważ uzyskanie zgody zarządu na ten wysiłek. Kierownictwo musi dostrzec konkretne korzyści wynikające ze zmniejszonych wad i mniejsze ryzyko wprowadzenia zmian. Ostatecznie proces refaktoryzacji powinien doprowadzić do skrócenia czasu programowania, ale jest to długoterminowa korzyść.

Twoje pomysły na zespoły recenzujące i ewangelistów OO są dobre. To musi być coś więcej niż tylko Ty, który realizuje ten program.

Z mojego doświadczenia wynika, że ​​przejście od sposobu myślenia proceduralnego do sposobu myślenia OO stanowi dużą przeszkodę. Wymaga wytrwałości, której wielu programistów nie wytrzymuje. Wynika to głównie z tego, że przeanalizowano podstawy OO.

Utwórz zespół ewangelistów OO, którzy rozpowszechniają sposób myślenia OO w różnych zespołach (ci ludzie będą musieli zmieniać zespoły co kilka miesięcy).

to dobry pomysł. To powinno być dokładne, a OO powinno być omawiane od podstaw. Kiedy uczyłem się historycznych anegdot OO bardzo mi pomogło.

Sugerowałbym również

• Ponieważ motywacja jest kluczem, motywuj ich, szczegółowo opisując, w jaki sposób OO może usprawnić swoją pracę, w szczególności możliwość utrzymania kodu.
• Dokonaj przeglądu kodu i pokaż, jak refaktoryzować stosując kompozycję, dziedziczenie, polimorfizm i wzorce.
• Wprowadź dobry proces, taki jak SCRUM, i zaangażuj w to programistów.
• Obowiązkowe jest czytanie książek takich jak „Refaktoryzacja” i „Refaktoryzacja do wzorów”.

Zgadzam się z Shuvo Naser. To wielka przeszkoda, więc traktuj to bardziej jak wspinaczkę. Nauka projektowania całej aplikacji przy użyciu OOP zajmie trochę czasu.

1. Zidentyfikuj tych, którzy rozumieją OOP i przenieś ich bliżej liderów zespołów, trenerów, projektantów, recenzentów kodu itp.
2. Użyj istniejącego projektu jako odniesienia do szkolenia. Być może ci z nr 1 byli w tym zespole.
3. Refaktoryzuj niektóre istniejące projekty. Może to pomóc niektórym osobom zbudować pomost między kodem proceduralnym a kodem OO. Zacznij od podstaw. Muszą zobaczyć, kiedy, gdzie i dlaczego stosujesz te zasady.
4. Zaangażuj ich w sesje projektowe z ludźmi, którzy wiedzą, co robią.
5. Umieść ich w zespołach deweloperskich z kimś, kto może udzielić wskazówek projektowych i upewnij się, że projekt jest zgodny z zasadami OO (Zakładając, że chcesz to zrobić, to przede wszystkim dlatego, że poprawi to rozwój).

Adopcja rzadko poprzedza dostrzeżenie korzyści. Mówimy o złożonym projekcie i nie korzystamy z Arkuszy okładek raportów TPS .

Masz już dobre pomysły

Pomysły zarysowane w pytaniu brzmią doskonale. To wielka niespodzianka, że ​​nie odnosisz sukcesu. Jest rok 2012, a rewolucja zorientowana obiektowo od dawna przeszła od najnowocześniejszych do najnowocześniejszych praktyk. Wydaje się, że jeśli nie masz bardzo niskich obrotów i bardzo małej liczby osób zatrudnionych, trudno byłoby ci zdobyć kilkadziesiąt, a nawet sto dobrych programistów zorientowanych na obiekty stałe.

Zwinny czy obiektowy?

Wspominasz o niektórych zwinnych technologiach, takich jak TDD i nowszych koncepcjach, więc nie bądź zbyt surowy dla ludzi, ponieważ nie obejmują czegoś, co wciąż jest aktywnie zwalczane przez niektóre zespoły zarządzające. Niektórzy twierdzą, że obejmują Agile, ale kiedy o tym mówią, oznacza to, co mówią, że to znaczy. Organizacja nie charakteryzuje się zespołami, które podejmują decyzje i dostosowują się, lecz silną hierarchiczną kontrolą w stylu kontraktu.

Ale wracając do obiektu. Nie wspominasz o analizie lub projektowaniu obiektowym i nie jestem całkiem pewien, który język programowania ustępuje temu, który język programowania zorientowanego obiektowo. Wiem, że UML ma problemy z popularnością wśród wielu programistów obiektowych. Po dokładnym przeszkoleniu w OOAD uważam, że może to być jak nauka kultury i historii kraju, którego naturalnego języka chcesz się nauczyć. Na przykład, gdybym chciał nauczyć się greckiego, mógłbym nauczyć się alfabetu, słownictwa i gramatyki, ale gdybym zignorował bogatą historię i kulturę, bardzo bym tęsknił. W każdym razie, jeśli nauczysz się wszystkiego o zorientowanym obiektowo języku programowania, ale nic o OOAD, myślę, że utracono ważną szansę.

Problemy do przezwyciężenia?

Most za daleko? Jeśli poprosisz ludzi, aby nauczyli się jednej małej rzeczy tygodniowo, za rok, wśród osób, które uczestniczą, będzie wiele zmian. Jeśli poprosisz ich o zmianę wszystkiego, co wiedzą, zostanie przyjęty przez niektórych, trudny dla wielu, a niemożliwy dla innych. Niektóre zmiany, takie jak kontrola źródła, są zlokalizowane. Przechodzisz od nie robienia tego wcześniej, miałeś trening, który nie podkreślał granic pamięci, ktoś przeprowadził cię przez nią po raz pierwszy, a potem codzienność była dość łatwa.

Inne zmiany są wszechobecne. Na przykład zrzucenie C i przejście na Javę wymaga znacznego przeszkolenia, konfiguracji i dużych zmian w codziennym życiu w celu przyjęcia nowego IDE, nowego kompilatora, nowego języka, nowego API, nowego modelu wdrażania itp. To jest ten rodzaj co dzieje się najczęściej w połączeniu z programem pilotażowym lub restrukturyzacją przedsiębiorstw.

Prowadzić rewolucję? Jeśli ludzie, którzy obecnie wykonują tę pracę, mają w przeszłości swoją nagrodę, a firmie nie grozi awaria, jaka jest ich motywacja do zmiany? Jeśli wydajesz się być osobą z zewnątrz, która chce wskazać kierunek i obciąża ich odpowiedzialnością za wyniki, których nie są w stanie przewidzieć, może się wydawać, że to całe ryzyko, a nie nagroda.

Pozycja Władza czy Idea Przywództwo? Wiele organizacji działa w oparciu o siłę pozycji. Jeśli brakuje ci widocznego wsparcia ze strony kierowników, kierowników sekcji, dyrektorów i wiceprezesów, jesteś jedynie liderem pomysłów. Niektóre osoby znajdują się w niebezpiecznej sytuacji, gdy mają jeden pomysł i nie są w stanie zająć się drugim. Jeśli potrafisz je pokazać zamiast im mówić, przejdzie to długą drogę do wyciszenia sceptyków i zainteresowania utalentowanych sojuszników.

Baza wsparcia jest zbyt mała? Zrób triage wśród tych 250 osób i podziel je na trzy kategorie: gotowe do przyjęcia, chętne do nauki i niechętne do nauki. Masz powody do frustracji niektórymi ludźmi, którzy nie są zainteresowani wprowadzaniem zmian. Równie dobrze możesz naciskać na linę. To zmarnowany wysiłek. Jeśli masz wyczucie, kto wspiera zmiany, możesz dowiedzieć się, co ich interesuje.

W przeciwieństwie do segregacji medycznej, w której etycznym i praktycznym wyborem jest pomoc grupie środkowej, która może to zrobić z pomocą, możesz zainwestować swoją energię i czas w oparciu o swoją ocenę i preferencje. Aby osiągnąć sukces, dlaczego nie kultywować grupy gotowej na przyjęcie nowych pomysłów? Może to być kilka pierwszych, ale jak śnieżka, Twoja widoczność i wiarygodność jako adwokata wzrośnie. Wkrótce ludzie będą pytać, kiedy odbędzie się następny trening.

Czy to w perspektywie długoterminowej? Dopóki nie wyhodujesz bohatera, który będzie nosił po sobie przedmioty, powinieneś oczekiwać zainwestowania czasu w budowanie relacji. Być może będziesz musiał pozostać w drużynach, które trenujesz przez ponad miesiąc. Dopóki zespół nie opracuje dla siebie ulepszonych praktyk, jesteś tylko gliną technologii lub metodologii. Mentoring to proces, który może potrwać lata. Jest wiele rzeczy, których Twoi programiści nie chcą robić, a które według ciebie są ważne (szczególnie wspomniałem o testowaniu jednostkowym). Stworzenie wspólnej wizji wartości, jaką to przynosi, może chwilę potrwać. Znam to z doświadczenia, ponieważ kiedyś opowiadałem się za narzędziem do pokrycia kodu w firmie z listy Fortune 500, która cieszyła się dobrą opinią pod względem jakości, ale menedżerowie i rówieśnicy obawiali się tego.

Ekspert czy oddolni? O wiele szybsze niż mentoring byłoby wspieranie wsparcia oddolnego każdego członka zespołu. Zaczynając od zespołu dziesięciu specjalistów ds. Oprogramowania, gdybym miał wybór, aby jedna osoba cały czas pracowała nad procesem lub dziesięć osób nad procesem pracowała przez dziesięć procent, wybrałbym drugą. Proces oddolny pozwala adwokatom poczuć wpływ tego podejścia, a podejście powinno być dostosowane do najlepszego rozwiązania problemów zespołu, który jest właścicielem pracy.

Czy widzisz linię wolności? Częścią wprowadzenia „najlepszych praktyk” jest skłonienie ludzi do rezygnacji z pewnej swobody robienia rzeczy we wspólny sposób. Rezygnacja z uznania programisty będzie bardziej przyjemna, jeśli będziesz szukał możliwości pozostawienia wielu możliwości programistom. To, co wybierają, jest określone na podstawie tego, co nakazuje partycja, którą możemy nazwać linią wolności. Konieczne mogą być podobne, dobrze uzasadnione podziały dotyczące praktyk organizacyjnych, regionalnych / dotyczących miejsca, zespołu i osobistych.

To powinien być komentarz, ale ponieważ najwyraźniej nie jestem jeszcze w stanie komentować różnych rzeczy, równie dobrze może być odpowiedzią.

Najważniejszą rzeczą w tego rodzaju przełomach (czy to OOP, czy jakakolwiek inna zmiana paradygmatu, powiedzmy, programowanie funkcjonalne lub cokolwiek, co wyjdzie w przyszłym roku), to ZRÓB RECENZJE KODÓW I PROGRAMOWANIE PEER . Towarzysz im, wprowadzaj zespoły w inny sposób robienia rzeczy, które im pomogą.

Moja osobista ścieżka do programowania obiektowego zaczęła się, gdy niektóre przypadkowe próby robienia przeglądów kodu karały mnie za robienie rzeczy w sposób modułowy i utrzymywanie stanu bez pełnego C ++ OO; myśl kod jak

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(zauważ, że klienci_total mogą być całkowicie zbędne, co jest szczególnie źle zaplanowanym przykładem)

Skończyło się to na tym, że więcej starszych współpracowników właśnie wskazało mój ekran i powiedział: „spójrz, jeśli napiszesz to samo więcej niż raz, użyj procedury lub funkcji i po prostu wywołuj to w kółko”.

Rozmowy i spotkania oraz opcjonalne praktyki nie zmuszą ich do zmiany paradygmatu lub wprowadzenia nowej praktyki, ponieważ nie ma prawdziwej motywacji do tego, poza czystą ciekawością. Z drugiej strony, nie robienie z tego źle lub po prostu marszczenie brwi na rzeczy bardzo dobrze zwiększa współczynnik adopcji.

Bądź przygotowany na marudzenie i rozwój zorientowany na klasę, który nastąpi, dopóki nie włączą odpowiedniego projektu do tego, co robią. Zobaczysz wiele rzeczy, które sprawią, że umrzesz trochę, ale tak wygląda ścieżka do nauki.