Jak przekonać mój zespół do korzystania z mniejszych klas / metod?

Oświadczenie: Jestem nowicjuszem (to mój trzeci dzień pracy), a większość moich kolegów z drużyny jest bardziej doświadczona niż ja.

Kiedy patrzę na nasz kod, widzę niektóre zapachy kodu i złe praktyki inżynierskie, takie jak:

• Nieco niespójne wytyczne dotyczące nazewnictwa
• W miarę możliwości właściwości nie są oznaczone jako tylko do odczytu
• Duże klasy - zauważyłem klasę użyteczności składającą się z setek metod rozszerzenia (dla wielu typów). Miał ponad 2500 linii!
• Duże metody - próbuję refaktoryzować metodę o długości 150 linii.

Te dwa ostatnie wydają się być prawdziwym problemem. Chcę przekonać moich kolegów z drużyny do korzystania z mniejszych klas i metod. Ale czy powinienem to zrobić? Jeśli tak, to jak?

Mój zespół otrzymał mentora od zespołu głównego (jesteśmy zespołem satelitarnym). Czy powinienem najpierw iść do niego?

AKTUALIZACJA : Ponieważ niektóre odpowiedzi dotyczyły projektu, pamiętaj, że jest to projekt działający. I IMHO, ogromne klasy / metody tego rozmiaru są zawsze złe.

W każdym razie nigdy nie chcę wkurzyć mojego zespołu. Właśnie dlatego zapytałem - czy powinienem to zrobić, a jeśli tak, to jak mam to zrobić delikatnie?

AKTUALIZACJA : Postanowiłem zrobić coś w oparciu o przyjętą odpowiedź: ponieważ jestem nowicjuszem, więc widzę wszystko w „świeżych oczach”, zanotuję wszystkie znalezione przeze mnie zapachy (pozycja, dlaczego to źle, jak możemy to zrobić lepiej ...), ale w tej chwili staram się zebrać szacunek od mojego zespołu: napisz „lepszy kod”, poznaj ludzi, dowiedz się, dlaczego to zrobiliśmy ... Kiedy nadejdzie właściwy czas, spróbuję zapytać mój zespół o nowe zasady dotyczące kodu (wytyczne dotyczące nazewnictwa, mniejsze klasy, mniejsze metody, ...) i, jeśli to możliwe, przebudować stary kod. Powinno działać, IMHO.

Dziękuję Ci.

Zaletą jest przeglądanie kodu świeżymi oczami. Rób notatki, aby udokumentować, co odkryłeś złych praktyk. Następnie, gdy załatwisz sprawę z zespołem, wyciągnij swoje notatki w odpowiednim momencie, na przykład kiedy nadejdzie czas na refaktoryzację.

Code Complete autorstwa Steve'a McConnella ma mnóstwo dobrych statystyk na ten sam temat, o którym mówisz. Nie pamiętam wszystkich liczb, ale mówi o tym, jak rośnie liczba błędów przy dłuższych metodach / klasach, ile czasu zajmuje debugowanie itp.

Możesz kupić egzemplarz książki i pokazać swoim współpracownikom niektóre z badań ... statystyki (choć cały czas kłamią) mają tendencję do przekonywania ludzi.

Oświadczenie: Jestem nowym przybyszem (to mój trzeci dzień pracy), a większość mojego zespołu jest bardziej doświadczona niż ja.

Możesz nieco zwolnić, posłuchać i uczyć się od swojego zespołu, zanim zaczniesz sugerować zbyt wiele zmian. Mogą istnieć dobre powody, dla których kod ma taką strukturę, ale w każdym razie poświęcenie czasu na słuchanie i naukę może tylko pomóc.

Następnie wszelkie sugestie, które możesz przedstawić, będą z pewnością postrzegane bardziej pozytywnie i spotkasz się z mniejszym oporem.

Twoje szanse na pomyślne wprowadzenie zmian są znacznie większe, jeśli najpierw zdobędziesz szacunek lub przynajmniej go nie stracisz.

Jak to szło? „Zmierz dwa razy raz ..” Coś w tym stylu.

Jeśli nie zostałeś zatrudniony z konkretnym zamiarem przebudowania sposobu pisania kodu przez zespół, możesz ograniczyć entuzjazm do drastycznych przeróbek. Większość działającego kodu działa z jakiegoś powodu :) bez względu na śmieci, a czasem drastyczne przeglądy sprawiają, że te irytujące narożniki są jeszcze brzydsze.

Myślę, że najłatwiejszym sposobem na napisanie mniejszego kodu byłoby poproszenie programistów o skoncentrowanie się na testowaniu jednostkowym . Nic nie wymusza zwięzłego kodu, tak jak poproszenie go o przetestowanie ; to zadziwiające, jak programiści nagle mają niechęć do globalnych struktur danych, przekazując zbyt wiele obiektów zbyt wiele warstw głęboko, gdy wiedzą, że muszą napisać testy na to wszystko.

Nie jestem wielkim fanem TDD ale ja nie kocham fakt, że zmusza deweloperów do rozważenia, jak oni pisać testy. I że często dlatego, że kod jest lepsza, nie jakaś magia rzeczywiście o konieczności badań. (Chociaż to z pewnością przydaje się, gdy wprowadzisz zmiany później).

Powodzenia.

Nie powinieneś przekonywać swojego zespołu. Jako nowicjusz nie będziesz traktowany poważnie - stąd marnowanie czasu.

Zamiast tego napisz sam i napisz zwarty i czysty kod. Mamy nadzieję, że po pewnym czasie i kilku recenzjach kodu niektórzy członkowie drużyny mogą zacząć naśladować Twój styl.

Jeśli nie, nadal będziesz bardziej produktywny, a ciężka praca ostatecznie doprowadzi cię do wyższej pozycji, gdzie możesz zacząć egzekwować niektóre z tych zasad.

I tak, na pewno, pokaż wszystkim rzeczy z Code Complete.

Oto kilka sztuczek:

• Poznaj aktualny stan i historię zespołu - brzmi to tak, jakby mieli mentora, jaki wpływ ma mentor? A także, jak nowy jest mentor i czy był długo bez mentora? Kiedy powstaje kod problemu? Krytykowanie dziecka obecnego zespołu może być czymś innym niż krytykowanie starego kodu, którego nikt tak naprawdę nie pamięta.

• Jedna rzecz na raz - nie zrzucaj bomby na wszystkie swoje myśli na spotkaniu zespołu. Zacznij od kilku pytań, które pochodzą z Twojej konkretnej perspektywy. Na przykład - „Hej, jako nowy facet, zauważyłem, że niektóre klasy użyteczności są naprawdę duże, czy jest ku temu powód?”

• Sugeruj kroki dziecka - prawie nigdy nie można dokonać natychmiastowego całkowitego przeglądu, więc wymyśl kilka kroków początkowych, które zasugerują na wypadek, gdyby wszyscy zgodzili się, że jest to dobry plan.

• Zaproponuj przyszłe mechanizmy zapobiegania - na przykład zespół może zgodzić się na cel, którego nigdy nie doda do kilku największych największych klas, ale dokona refaktury, gdy zajdzie potrzeba dalszego ich rozwoju.

• Słuchaj obaw o ryzyko. Jeśli jest to naprawdę starszy kod, może istnieć wystarczająca liczba niewiadomych i zależności, że refaktoryzacja jest wyjątkowo ryzykowna. To może nie być powód do unikania refaktoryzacji, ale może to oznaczać, że potrzebujesz lepszych strategii testowych lub innego sposobu zmniejszenia ryzyka przed podjęciem prawdziwej przeróbki.

• Uważaj na mowę ciała i idź powoli. Przywołujesz problem w bazie kodu, z którym nie miałeś dużego doświadczenia. Masz teraz nowe okno dla faceta, w którym możesz zadawać naiwne pytania i uzyskiwać pomocne odpowiedzi, a następnie możesz użyć tych pytań do zbadania zespołu pod kątem własnych wyborów projektowych. Ale dzieje się to w obie strony - jako nowy facet nie masz jeszcze mnóstwo „wiarygodności”, więc idź powoli i bądź świadomy zamkniętych twarzy lub pozycji. Jeśli ludzie zaczną się zamykać, zasugeruj sposób na opóźnienie wszelkich decyzji i poszukaj sposobów na ich pozyskanie.

Mogę powiedzieć, że jako menedżer i członek zespołu cieszę się z New Guy Insights. Nie zaakceptowałem każdego konstruktywnego komentarza, który dał mi nowy członek zespołu, ale ogólnie byłem skłonny słuchać, jeśli krytyka została wyrażona jako szczera troska i ciekawość, a nie jako wykład. Znak szacunku dla nowego faceta przemija, gdy może dostarczyć wgląd, a następnie cofnąć się i poradzić sobie z tym, co przyjdzie - łatwo jest czuć się dobrze, gdy twoje decyzje są słyszane i podejmowane, trudniej, gdy zespół mówi ci „nie”. Nadal możesz mieć rację, sztuczka polega na tym, aby dowiedzieć się, co robić dalej ... zwykle czekanie trochę i szukanie dodatkowych informacji jest dobrym krokiem w takich przypadkach.

Jak przekonać mój zespół do korzystania z mniejszych klas / metod?

Nie rób

Kup sobie licencję Resharper i dawaj przykład. [Mocno opieraj się na refaktoryzacji „ Metody ekstrakcji ”.]

Z czasem inni powinni docenić twój bardziej czytelny kod i przekonać go, aby zrobił to samo. *

• Tak - istnieje szansa, że nie zostaną przekonani; ale nadal jest to najlepszy wybór.

IMO - nie warto sylab przekonywać kolegów z drużyny, aby stali się lepszymi programistami, czytać „ Code Complete ”, śledź @Uncle Bob. SOLIDNE zasady i stań się lepszymi programistami, jeśli nie zostaną jeszcze przekonani.

Pamiętaj: nie możesz użyć logiki, aby przekonać kogoś, kto nie znalazł się w pozycji, do której nie użył logiki, żeby się dostać.

Wydaje się, że jest to raczej pytanie zarządcze niż techniczne. Wszystko, co powiedziałeś, jest ważne, to, czego naprawdę potrzebuje Twój zespół, to dobry architekt, który może upewnić się, że wszyscy dostosowują się do jednego wzorca projektowego i egzekwują go, zespół musi stale i regularnie refaktoryzować kod.

Istnieje jednak inna zasada „nie będziesz jej potrzebować”, jeśli to, co kiedykolwiek istniało, działa dość długo, bez względu na to, jak brzydkie jest, zmiana tego nie zawsze jest dobrym pomysłem. Zamiast tego, jeśli Twój zespół musi odbudować całość lub odbudować jej część, przed przystąpieniem do kodowania należy zgromadzić dokument dotyczący złych praktyk i problemów.

Niektóre zespoły nie przeprowadzają żadnej kontroli jakości kodu, ponieważ nie znają odpowiednich narzędzi. Istnieje wiele narzędzi, które mogą pomóc w ulepszeniu kodu zespołu.

Visual Studio ma „Analizę kodu”, która może pomóc w konwencjach nazewnictwa.

Można również zastosować metryki kodu, takie jak złożoność cykliczna. Pomaga to wskazać zbyt złożone klasy i metody.

Prowadzenie dokumentacji jest również dobrym pomysłem. Jeśli członkowie zespołu wyrażą werbalnie, co należy zrobić, ludzie z pewnością zapomną. Ludzie mają bardzo słabe wspomnienia! =)

Nie robiłbym dużo hałasu na ten temat ... Zespół programistów jest jak jego własna rodzina ... Jeśli zauważysz błędy, ludzie mogą się na ciebie gniewać. Tego rodzaju zmiana kultury wymaga nie tylko dużo kodowania, ale także delikatnego kontaktu z ludźmi.

Jako menedżer chcę tylko dodać, że chcę, aby mój zespół napisał dobry kod za pierwszym razem. Recenzje kodu, TDD i tak dalej. Ale kiedy już zacznie się produkować i będzie działać, będziesz musiał się przekonać, żebyśmy wrócili.

Postępuję zgodnie z radą wuja Boba, aby zawsze zostawiać kod lepiej niż go znalazłeś. Więc jeśli mamy błędy do naprawienia lub małe ulepszenia, mam nadzieję, że przeprowadziliśmy wtedy trochę czyszczenia.

Ale na obecnym etapie firma naprawdę obserwuje, że to pieniądze. Muszę im wytłumaczyć, że refaktoryzacja przynosi im wystarczająco dużo, aby dać zespołowi czas i zasoby. Nie wystarczy po prostu nie podobać się wyglądowi kodu.

Więc jeśli to działa, nawet jeśli możesz go nienawidzić, być może będziesz musiał zostawić go w spokoju.

Teraz nowy kod, to jest inne. To powinien być dobry kod.

Metody zawierające 150 linii ... Widziałem metody z 10.000 linii kodu.

Dwa z twoich problemów można rozwiązać za pomocą zewnętrznych narzędzi :

• Nieco niespójne wytyczne dotyczące nazewnictwa
• W miarę możliwości właściwości nie są oznaczone jako tylko do odczytu

W C # Resharper może sprawdzić oba problemy. Nazwy niezgodne z wytycznymi są oznaczone jako błędy. Właściwości nieoznaczone jako tylko do odczytu są również wyświetlane jako błędy. FxCop może być również pomocny.

Narzędzia te mogą również pomóc w podzieleniu ogromnych metod na wiele mniejszych dzięki refaktoryzacji.

Nie wiem, czy duże klasy są zawsze takie złe, jeśli są dobrze skonstruowane przy użyciu dobrze nazwanych metod. Używam Eclipse jako mojego IDE, więc ma coś, co nazywa się widokiem „konspektu”, co jest wszystkim, co wszystkie IDE mają po prostu pod inną nazwą, najprawdopodobniej, która podaje nazwę i link do każdej metody w klasie, możesz sortować alfabetycznie itp. Używając tego, łatwo jest poruszać się po dużej klasie, tym bardziej, że posiadanie naprawdę długich metod byłoby złe, myślę, ponieważ trudniej jest inteligentnie nawigować w ramach tej metody, chyba że naprawdę się z nią zaznajomisz. Nie opowiadam się za długimi zajęciami, ale myślę, że w niektórych przypadkach można nimi zarządzać i niekoniecznie muszą być one podzielone na wiele klas.

Porozmawiaj na ten temat z niektórymi członkami swojego zespołu i uzyskaj ich opinię na temat wielkości metod. Możesz być zaskoczony, gdy się z tobą zgadzają. To, co widzisz, może być wynikiem złych wcześniejszych praktyk, dawnych programistów nie było już w firmie lub ta część była pośpieszną pracą, a teraz zatrudnili kogoś, kto ma czas, aby to zmienić;)

Nadal jesteś nowym facetem. Buduj reputację, podejmując trudne zadania i wykonując je szybko i bez błędów. Jeśli spróbujesz zacząć zmieniać rzeczy, zanim zdobędziesz szacunek rówieśników, możesz mieć o wiele trudniejszy czas na zdobycie wpisu (i być może zrazić swoich współpracowników).

Jeśli potrafisz znaleźć sposoby na wprowadzenie lepszych nawyków kodowania w swojej pracy, które skutecznie pokazują, w jaki sposób skracają czas opracowywania i dają bardziej niezawodne rozwiązania, możesz nawet poprosić ich o sprawdzenie, jak to osiągnąłeś.

Oprócz wszystkich innych wspaniałych odpowiedzi, być może możesz zabić dwa ptaki jednym kamieniem i zrobić porządek w kodzie jako projekt mający na celu lepsze zrozumienie podstawy kodu. Możesz sprzedać go zespołowi / menedżerowi jako okazję do nauki, a dostaniesz opinię od swoich kolegów, gdy przejrzą twoje zmiany, które poprowadzą cię do najlepszego podejścia do rozwiązania problemu złego projektu.