Jak mam (taktownie) poinformować mojego kierownika projektu lub głównego programistę, że podstawa kodu projektu wymaga poważnej pracy?

Właśnie dołączyłem do (względnie) małego zespołu programistów, który pracuje nad projektem od kilku miesięcy, jeśli nie roku. Podobnie jak w przypadku większości programistów dołączających do projektu, pierwsze kilka dni spędziłem na przeglądaniu bazy kodu projektu.

Projekt (wewnętrzna i wewnętrzna linia aplikacji biznesowych ASP.NET WebForms) jest katastrofą z powodu braku bardziej opisowego terminu. Istnieją trzy natychmiast zauważalne problemy ze standardami kodowania:

1. Standard jest bardzo luźny. Opisuje on raczej czego nie robić (nie używać notacji węgierskiej, etc ..) niż to, co do zrobienia.
2. Standard nie zawsze jest przestrzegany. Wszędzie występują niespójności z formatowaniem kodu .
3. Standard nie jest zgodny ze wskazówkami stylu Microsoft. Moim zdaniem nie ma sensu odstępować od wytycznych, które zostały opracowane przez twórcę frameworka i największy wkład w specyfikację języka.

Co do punktu 3, może bardziej mi to przeszkadza, ponieważ poświęciłem trochę czasu na uzyskanie MCPD ze szczególnym uwzględnieniem aplikacji internetowych (w szczególności ASP.NET). Jestem także jedynym certyfikowanym specjalistą Microsoft w zespole. Ze względu na to, czego nauczyłem się podczas wszystkich moich szkoleń, samokształcenia i uczenia się w miejscu pracy (w tym moich przygotowań do egzaminów certyfikacyjnych), zauważyłem również kilka przypadków w kodzie projektu, w których po prostu nie robi się tego w Najlepszym sposobem.

Pracuję w tym zespole dopiero od tygodnia, ale widzę tyle problemów z bazą kodów, że wyobrażam sobie, że spędzę więcej czasu na walce z tym, co już napisano, aby robić rzeczy po swojemu, niż gdybym był pracując nad projektem, który na przykład przestrzegał ogólnie przyjętych standardów kodowania, wzorców architektury i najlepszych praktyk. To prowadzi mnie do mojego pytania:

Czy powinienem (a jeśli tak, jak to zrobić) zaproponować mojemu kierownikowi projektu i zespołowi, aby projekt wymagał gruntownej renowacji?

Nie chcę wchodzić do ich biura, wymachując moimi certyfikatami MCTS i MCPD, mówiąc, że baza kodów ich projektu to bzdura. Ale też nie chcą się zatrzymać cichy i trzeba pisać kodu kludgey szczycie ich kodem kludgey, bo rzeczywiście chcą oprogramowania jakości zapisu i chcę produkt końcowy jest stabilny i łatwy w utrzymaniu.

Możesz spędzać czas na argumentowaniu swojej sprawy; lub możesz spędzać czas na sprzątaniu.

Wybierz zasady, wzorce i praktyki opracowywania czystego kodu i zwinnego oprogramowania i zastosuj zdobytą wiedzę podczas pracy w systemie. W końcu ludzie zauważą (na lepsze lub gorsze).

Edytuj Sprawdź także Efektywna praca ze starszym kodem

Z twojego opisu wynika, że ​​problemy dotyczą głównie nieprzestrzegania standardów kodowania i problemów z nazewnictwem. Zdecydowanie nie jest to katastrofa . Dla porównania, to naprawdę katastrofa.

Może jesteś przyzwyczajony i wymaga wysokich standardów? W takim przypadku wszelkie odstępstwa od doskonałości można uznać za porażkę. Jest to pułapka, w którą łatwo wpaść, gdy twoje wymagania są wysokie, ale ważne jest, aby zachować perspektywę na różne rzeczy.

Sugeruję, abyś mówił o tym jako o ulepszeniu i pomógł zespołowi zaktualizować swoje wytyczne i wyszkolić ich, aby zaczęli używać go naprawdę. Naprawdę lubię używać Definicji Gotowości jako wzorca jakości, a jej stworzenie jest świetnym zespołem sam w sobie. Ale nie sądzę, że powinieneś robić o wiele więcej, przynajmniej nie jako nowy członek zespołu.

Zdecydowanie nie machaj swoim MCSD, ludzie po prostu śmieją się z ciebie całkiem szczerze, certyfikaty MS są miłe do zdobycia, ale w żadnym wypadku nie są to kwalifikacje zawodowe!

Wkrocz lekko do nowego zespołu, szukaj okazji do sugerowania zmian w miarę upływu czasu.

Poczekaj, aż uzyskasz ukształtowanie terenu, zanim wprowadzisz kod drużyny.

Możesz uznać, że problemem jest ty. ŻADNA z trzech wymienionych przez ciebie rzeczy nie jest warta całkowitej przeróbki aplikacji. To są po prostu wątłe szczegóły.

Pamiętaj, że celem aplikacji nie jest piękny kod, lecz rozwiązanie problemu biznesowego. Jasne, że miło jest mieć spójny kod i zgodny z dobrym standardem, ale jego brak nie jest powodem do zniszczenia całej bazy kodu. To, że silnik jest oleisty, nie oznacza, że ​​należy go odbudować.

Słuchaj, wszyscy nienawidzą każdej bazy kodu, której nie napisali. W rzeczywistości, jeśli zaczekasz trzy lata i przyjrzysz się własnemu kodowi, również go nienawidzisz i myślisz, że wymaga on kompletnego przepisania. Prawda jest taka, że ​​nie. O ile nie możesz udowodnić, że spędzając miesiące na tworzeniu kodu, który jest dla ciebie przyjemny estetycznie zamiast budowania funkcji w celu zwiększenia wartości biznesowej, prawdopodobnie szczekasz na złe drzewo.

Nic nie mówi, że musisz pisać kludgy kod tylko dlatego, że może być trochę w bazie kodu. I nic nie mówi, że kod IS jest kludgy tylko dlatego, że nie jest zgodny z Twoim stylem zwierzaka. Po prostu dokonaj refaktoryzacji podczas pracy nad częściami, nad którymi pracujesz, i pisz dobry kod, gdy pracujesz nad nowymi rzeczami.

Te rzeczy są w porządku, aby się martwić, ale jeśli jesteś nowy w zespole, nie zakołysz jeszcze łodzią, dopóki nie zyskasz pewnej wiarygodności.

Wygląda na to, że wybrałeś trzy (względnie) drobne rzeczy, którymi się martwisz. Są inne rzeczy, o które martwię się bardziej:

• Czy kod jest dobrze udokumentowany?
• Czy kod jest zgodny ze specyfikacjami / dokumentacją projektową?
• Czy kod działa?
• Czy łatwo jest zrozumieć, co robi kod?
• Zastanawiasz się nad przesłaniem dużych części tej bazy kodów do TheDailyWTF?

Jesteś tam od tygodnia? Nie jestem pewien, czy wiesz wystarczająco dużo, aby składać propozycje kierownikowi projektu. Nawet jeśli masz podejrzenia, że ​​kodeks i praktyki tego zespołu są „złe”, najlepszym sposobem na wpływanie na te rzeczy z czasem jest stopniowe zdobywanie ich zaufania i szacunku. Wchodzenie do projektu i po tygodniu mówienie zespołowi, że jego kod wymaga przepisania, nie jest dobrym sposobem na zdobycie zaufania i szacunku.

Przez pierwsze kilka miesięcy skup się na dawaniu lepszego przykładu i zadawaniu pytań na temat tego, dlaczego zrobili to w określony sposób. Zadając te pytania, zachowaj ostrożność. Jeśli okaże się, że jest się nowym „znającym wszystko” facetem, nikt nie wysłucha twoich opinii w późniejszym czasie, kiedy naprawdę będziesz w stanie wpłynąć na sposób, w jaki wszystko jest zrobione.

Z czasem, jeśli twój kod naprawdę jest „lepszy”, inni programiści to zobaczą. Zaczną przychodzić do ciebie jako źródło pomocy, aby pomóc im naprawić swoje, a następnie poprosić o radę na temat tego, jak powinni to robić. W tym momencie będziesz w stanie przekazać zespołowi (i kierownictwu) swoje opinie na temat standardów kodowania i tym podobne. Czas trwania tego procesu zależy od organizacji. Może to być tylko kilka tygodni w bardzo elastycznym środowisku, lub miesiące lub lata w bardziej stoickiej kulturze. Buduj swój wpływ pojedynczo.

Nigdy nie przejdziesz do nowej pracy, w której uważasz, że baza kodu jest idealna, a wszystko zostało zrobione „we właściwy sposób”. Naucz się to akceptować. Wszystko, co możesz zrobić ze starszym kodem, to refaktoryzacja i krok po kroku do przodu. Niektóre rzeczy, których nie chcesz refaktoryzować, dopóki nie zrozumiesz, dlaczego zrobili to, co zrobili. Poza tym nikt w biznesie nie zapłaci ci za naprawienie działającego kodu, więc musisz zrobić uzasadnienie biznesowe, dlaczego potrzebuje pracy przed przyspieszeniem i poświęceniem czasu. Lepiej poczekaj na kod refaktoryzujący, gdy i tak będziesz musiał dokonać zmiany. Być może nie wybrałeś metody, którą zrobili dla niektórych rzeczy, ale jeśli to działa, bardzo ostrożnie zmieniaj ją i wprowadzaj nowe błędy. Zwłaszcza, gdy nie zostałeś poproszony o zmianę.

Po upływie tygodnia nie jesteś wiarygodny, aby poczynić główne sugestie dotyczące sposobu prowadzenia działalności. Jeśli teraz poruszysz sprawy, ludzie będą się z ciebie śmiać i nigdy nie będą cię traktować poważnie. Udowodnij sobie najpierw dobry kod, a potem ludzie będą bardziej skłonni do słuchania.

I szczerze mówiąc, nikomu nie zależy na tym, że jesteś certyfikowanym specjalistą Microsoft. Każdy z dużym doświadczeniem widział tylu złych programistów, którzy mieli ten certyfikat jako dobrzy ludzie. Nie twierdzę, że źle wyglądasz w posiadaniu certyfikatu, mówię, że nie pokładamy w nich dużej wiarygodności, ponieważ nie widzieliśmy, gdzie są skuteczne, pokazuje nam, kto jest dobrym programistą.

Prawdopodobnie poszedłbym dalej, próbując dowiedzieć się, jak przedstawić propozycję z zamiarem, abyś mógł nie być w stanie odpowiednio uzasadnić swojego stanowiska. Kilka pytań do rozważenia przy tworzeniu tej propozycji:

• Jaką wartość biznesową zyskujesz, wprowadzając opisywane tutaj rodzaje zmian?
• Czy zastanawiałeś się nad takimi opcjami, jak ponowne napisanie aplikacji od zera, modyfikacja istniejącego kodu, aby przerobić go na tabakę, czy po prostu wprowadzanie niewielkich zmian w czasie?
• Czy wiesz, jakie funkcje i błędy są teraz potrzebne, które uniemożliwiłyby Ci dokonanie żądanych zmian?

Chociaż mogę docenić potrzebę naprawy słabej bazy kodu, należy to zważyć, aby było to uzasadnione z biznesowego punktu widzenia.

Obecnie nie jesteś w stanie zapobiec złemu kodowi, więc będziesz musiał wymyślić, jak go zatrzymać.

Szefowie zespołów i liderzy zespołów będą dbać tylko o to, że to nie działa. Kolejną troską będą, gdy poprosą cię o dokonanie zmian i zastanowią się, dlaczego „proste” rzeczy zabierają tyle czasu. Tam właśnie wejdziesz.

Zacznij teraz od problemu ze spójnością. Niezależnie od tego, jaka jest obecnie potencjalnie standardowa metoda, spróbuj ją zidentyfikować i sprawdź, czy nie możesz jej wymusić. Jeśli zaczniesz od metodologii, której nikt inny nie zna, dostaniesz mnóstwo odpowiedzi.

Inni członkowie zespołu mogą chcieć uzyskać certyfikat, a Ty będziesz świetnym źródłem informacji. Mam nadzieję, że przynajmniej będą chcieli poprawić i spojrzeć na ciebie, aby pokazać im drogę.

Narzekanie na notację węgierską nie da ci sympatii i jest prawdopodobnie jedną z ostatnich bitew na liście priorytetów.

Zgadzam się, że musisz być ostrożny. Musisz budować reputację w zespole, zanim będziesz mógł wyrazić krytykę i zaproponować głębokie zmiany w kodzie lub procesach. Na razie robiłbym notatki na temat moich ustaleń i sugestii, a także korzystałem z okazji, aby zapoznać się z członkami zespołu i kierownictwem, brać udział w bezpłatnych dyskusjach, ale nie odmawiać, jeśli rozmowa dotyczy kwestii jakości, kodować pytania itp., A czasem nawet rzucać niektóre z moich pytań do stawu (ale w ogólnej formie, nie wskazane zbytnio na żadne konkretne problemy, które widziałem w tej bazie kodu). W ten sposób mogę poznać opinię członków zespołu i znaleźć potencjalnych sojuszników.

W najlepszym przypadku może się okazać, że znaczna część zespołu (i / lub kierownictwa) widzi te same problemy, co Ty, tylko że nie podjęto żadnej inicjatywy, aby coś z nimi zrobić, lub żadnych zasobów przyznanych mu przez kierownictwo. Razem masz więcej do powiedzenia, aby przekonać zarząd w razie potrzeby.

Jak sugerował @Mike, z pewnością konieczne jest samodzielne wykonanie części czyszczenia, ale lepiej bądź cierpliwy. Jeśli zaczniesz zbyt szybko, możesz zrazić innych członków zespołu, którzy mogą potraktować to jako osobistą krytykę. Menedżer może również wziąć pod uwagę obszerne czyszczenie / refaktoryzowanie kodu jako znak, że nie jesteś wystarczająco skoncentrowany na rzeczywistym zadaniu. Powinieneś więc uzyskać mandat do refaktoryzacji, zanim zaczniesz na poważniejszym poziomie. Małe lokalne zmiany są jednak prawdopodobnie OK.

Ponadto, aby przekonać zarząd, potrzebujesz uzasadnienia biznesowego. Zarządzanie rzadko poruszane jest opisami niespójnego stylu kodowania. Musisz pokazać im, jaką wartość proponowane zmiany mogą przynieść firmie - dolna linia to gotówka. Jeśli potrafisz zebrać przekonująco wyglądające obliczenia dotyczące kosztów w porównaniu z długoterminowymi korzyściami różnych proponowanych zmian i pokazać, że ogólny bilans jest wyraźnie na plus, to znacznie zwiększyłeś swoje szanse.

Zrób to sam. Jeśli cenisz niektóre style kodowania, pracuj nad kodem, który narusza style kodowania . Pobierz fragment obraźliwego kodu z kontroli źródła, ponownie sformatuj kod zgodnie z wymaganiami białych znaków stylu (na przykład) i zatwierdź zaktualizowany kod z komunikatem „Zgodny z zasadą przewodnika po stylach w białych znakach”.

Po tygodniu najgorsze, co możesz zrobić, to przejść bezpośrednio do zarządzania. Najprawdopodobniej poświęcili dużo czasu na kod i są z niego dumni. Prawdopodobnie wyszedłbyś na jaw jako „wiedzieć wszystko”.

Co bym zrobił, gdybym był tobą, to ulepszyć to w miarę postępów. W miarę zapoznawania się z nim i pracy nad nim będziesz miał szansę go ulepszyć. W tym momencie zacznę pokazywać korzyści z tego, co robisz innym współpracownikom. Następnie, gdy spotkania projektowe wymyślą nowe moduły, przedstaw argument za tym, co postrzegasz jako najlepszy sposób.

I szczerze mówiąc, standardy istnieją z jakiegoś powodu, ale jeśli to działa i działa dobrze, to jest warte 100 razy więcej w mojej książce (szczególnie po tygodniu). Byłbym bardziej zaniepokojony, gdybyś otworzył kod i zobaczył mnóstwo błędów logicznych lub coś takiego.

Nie idź bezpośrednio do zarządzania z tym „problemem”.

Po pierwsze, porozmawiaj ze swoimi współpracownikami i dowiedz się od nich, dlaczego są takie, jakie są. Następnie możesz lepiej ocenić, czy występuje problem, czy nie. Możesz być zaskoczony tym, czego się uczysz. Możesz także znaleźć sojuszników, którzy chcą, aby został oczyszczony.

Jeśli nie masz pojęcia, w jaki sposób dotarłeś do miejsca, w którym jesteś, znacznie trudniej się wydostać.

Wiele dobrych sugestii już tutaj, a ja jestem zdania, że ​​nie wypalaj swoich mostów, dopóki nie udowodnisz sobie pierwszej opinii, podobnie jak inni. Chciałbym dodać, aby przedyskutować sprawy z kolegami z zespołu na długo przed wyobcowaniem ich, kierując się najpierw do kierownika projektu lub kierownika zespołu. I na pewno pokaż im wcześniej, że powinieneś być traktowany poważnie.

Brzmi również, że jest to bardziej problem stylistyczny związany z kodem. Przejęcie kodu innej osoby i przytrzymanie nosa podczas przyzwyczajania się do sposobu, w jaki go napisano, to tylko część pracy, nawet jeśli jest to trywialna rzecz, jak sposób, w jaki go formatują. Przekazanie jednego z twoich „dzieci” komuś innemu, aby pomieszały je brudnymi rękami, jest jeszcze gorsze ...

Jeśli ostatecznie jest to coś więcej - a problem jest bardziej funkcjonalny niż tylko stylistyczny - jeśli idziesz do kierownika zespołu / pm, najlepiej zaspokoić potrzebę przeróbek pod kątem miejsca, w którym zaoszczędziłoby to pieniądze i wysiłek w przyszłości projekt rozwojowy. Dobra stara refaktoryzacja.