Jaki jest / Czy istnieje właściwy sposób poinformowania kierownictwa, że ​​nasz kod jest do bani?

Nasz kod jest zły. Nie zawsze było to uważane za złe, ale jest złe i idzie tylko w dół. Zacząłem świeżo po studiach mniej niż rok temu, a wiele rzeczy w naszym kodzie łamie mi głowę nie do uwierzenia. Na początku pomyślałem, że jako nowy facet powinienem trzymać gębę na kłódkę, dopóki nie dowiem się trochę więcej o naszej bazie kodu, ale widziałem wiele, aby wiedzieć, że to źle.

Niektóre z najważniejszych wydarzeń:

• Nadal używamy ramek (spróbuj uzyskać coś z quistystring, prawie niemożliwe)
• VBScript
• Źródło Bezpieczne
• „Używamy” .NET - mam na myśli to, że mamy opakowania .NET, które wywołują biblioteki DLL COM, co sprawia, że ​​prawie niemożliwe jest łatwe debugowanie
• Wszystko jest w zasadzie jedną gigantyczną funkcją
• Kod nie jest możliwy do utrzymania. Każda strona ma wiele plików, które są tworzone za każdym razem, gdy tworzona jest nowa strona. Strona główna w zasadzie robi Response.Write () kilka razy, aby renderować HTML (runat = "server"? Nie ma mowy). Po tym może być dużo logiki po stronie klienta (VBScript), a na koniec strona sama się poddaje (często przechowuje wiele rzeczy w ukrytych polach), gdzie następnie publikuje na stronie przetwarzania, która może np. Zapisać dane do bazy danych.
• Otrzymane specyfikacje są śmieszne. Często wzywają do takich rzeczy, jak „automatyczne wypełnianie pola X polem Y lub Z” bez wskazania, kiedy wybrać pole Y lub pole Z.

Jestem pewien, że część tego wynika z braku zatrudnienia w firmie programistycznej, ale wydaje mi się, że ludzie piszący oprogramowanie powinni przynajmniej dbać o jakość swojego kodu. Nie mogę sobie nawet wyobrazić, że gdybym coś wymyślił, wszystko by się wkrótce stało, ponieważ zbliża się długi termin, ale nadal piszemy zły kod i stosujemy złe praktyki.

Co mogę zrobić? Jak w ogóle poruszyć te problemy? 75% mojego zespołu zgadza się ze mną i poruszało te problemy w przeszłości, ale nic się nie zmienia.

Upewnij się, że nie przesadzasz. Jesteś świeży, prawdopodobnie nie pracowałeś w wielu (żadnych?) Innych miejscach, a więc nie jesteś przygotowany na świat „prawdziwego kodu”. Kod z życia jest okropną rzeczą. To jest jak twój fajny szkolny kod i twój obsesyjnie ulepszony osobisty kod projektu uprawiał seks w piwnicy reaktora jądrowego, a dziecko dorastało w kanale toksycznych odpadów; to ohydny mutant.

Ale zakładając, że masz rację, a kod jest tak zły, jak mówisz (tj. Gorszy niż zwykły zły kod), masz rację. Porozmawiaj ze swoim zespołem i ustal, czy wszyscy inni są po stronie. Zajmie to pracę nad poprawą sytuacji - jeśli reszta zespołu rozpozna problem, ale nie przejmuj się, zmarnujesz swój czas.

Będąc juniorem, prawdopodobnie nie jesteś w stanie prowadzić. Jeśli sam pójdziesz do zarządzania, jako nowy pracownik, który jest również młodszy, Twoja opinia prawdopodobnie zostanie zignorowana. Zaangażuj swojego głównego programistę lub jednego z najbardziej zaangażowanych pracowników. Ponownie, jeśli żadna z osób starszych nie jest zainteresowana, tracisz czas.

Zakładając, że możesz zainteresować kilka starszych osób technicznych, pracuję nad identyfikacją obszarów problemowych i możliwych rozwiązań. Na przykład, jeśli „wszystko jest w zasadzie jedną gigantyczną funkcją”, następnym razem, gdy będziesz pracować w tej „gigantycznej funkcji”, może powinieneś trochę przebudować. Ponownie musisz zachęcić wszystkich do działania. Jeśli odłupiesz małe fragmenty swojego problemu i poprawisz kawałek po kawałku, ostatecznie staną się znacznie mniejszym problemem. Za każdym razem, gdy dotkniesz fragmentu kodu, zastanów się, czy można go ulepszyć.

Nie zamierzasz siadać z zarządem i mówić „wszystko jest złe i trzeba je przepisać”. To nie ma dla nich sensu - kosztuje dużo i jest potencjalnie bardzo ryzykowne. Zamiast tego należy uświadomić im, że występują problemy i że planuje się powoli poprawiać wraz z wprowadzaniem zmian. Powinny być edukowane na temat korzyści z utrzymywalnego kodu. Powinno to pochodzić od osoby starszej, której ufa technicznie i zawodowo - a nie od ciebie.

Kompletne przepisanie? Prawie zawsze zły pomysł.

Ostatecznie niewiele możesz zrobić, ponieważ jesteś nowy. Jeśli nikt nie chce poprawiać rzeczy, zbierasz swoje doświadczenia i przenosisz się do następnego miejsca.

Przeczytaj Joel On Software - rzeczy, których nigdy nie powinieneś robić. Zapoznaj się z jego uzasadnieniem, a następnie przeczytaj kilka innych artykułów na temat złego oprogramowania i sposobów jego naprawy, napisanych przez menedżerów, a nie programistów. Uzbrojeni w te informacje będziesz w stanie przedstawić sprawę do ich naprawy, w sposób zrozumiały dla menedżerów. Wskazówka: dobrzy menedżerowie nie spędzają czasu i pieniędzy wyłącznie na podstawie opinii i odczuć programistów na temat tego, co należy zrobić.

„Ten kod jest badziewny i wymaga przepisania” z pewnością zostanie odrzucony, nawet jeśli masz techniczną rację.

„Możemy odjąć kilka miesięcy od bieżącego harmonogramu projektu, kosztując mniej i czyniąc go bardziej niezawodnym.” zwróci ich uwagę (zauważ brak wzmianki o tym, JAK zamierzasz to zrobić na jego etapie.

Cokolwiek powiesz, bądź pewien, że masz rację. Jeśli powiesz, że to źle, twoje przepisywanie musi być cholernie dobre. Jeśli powiesz, że zajmie to tydzień, lepiej upewnij się, że będzie to tydzień, i bądź dobry. Wszelkie wady w przerobionym kodzie będą cię osobiście, drogo kosztować, niezależnie od tego, co by się stało, gdybyś nie zrobił przeróbki. Jeśli ktoś był tu przed tobą i spieprzył lub sprzedał przepisywanie, zrezygnuj, menedżerowie nie lubią, gdy oszukują cię i nie pozwolą, by stało się to dwa razy. W tym momencie, nie spieprz tego dla facetów, którzy podążą za tobą, dostaniesz tylko jeden strzał w to ...

Znajdź sposoby na rozłożenie kosztów na okres lub liczbę projektów. Menedżerowie nienawidzą ryzyka, inwestycji spekulacyjnych i ujemnych przepływów pieniężnych - pracuj w granicach tolerancji dla nich. Zacznij od małej sugestii o niskim ryzyku i niskich kosztach. Gdy okaże się, że masz rację, możesz wybrać większą rybę.

Po pierwsze, głupie, starsze rzeczy znajdziesz wszędzie, gdzie pracujesz jako programista, chyba że pracujesz na starcie i to ty tworzysz oryginalny, głupi, starszy kod. Jeśli planujesz karierę programistyczną, musisz być w stanie rzucić się na te ciosy.

Po drugie, często trzeba brać pod uwagę koszty ulepszenia starych systemów. Na przykład widziałem więcej niż jedną firmę, w której wciąż działało 10-letnie VB6 i klasyczne aplikacje ASP. W niektórych przypadkach było to spowodowane tym, że duży projekt przeniesienia platformy .NET nie powiódł się. W innych powodem było „jeśli się nie zepsuło, nie naprawiaj go”. Ale w innych koszt przeniesienia jest uzasadniony, ponieważ problemy spowodowane przez starszy system są zbyt duże, aby je zignorować.

W sytuacjach, w których w przeszłości doszło do dużej awarii, zmiana jest prawie niemożliwa. W takim przypadku dopracuj swoje CV i zacznij szukać nowej pracy. Jeśli nie zostanie zepsuty, prawdopodobnie nie będziesz miał powodów do narzekań na sam kod, ale nie byłeś na satysfakcjonującej i rozwijającej się ścieżce kariery. Jeśli jest zepsuty i wygląda na to, że tak jest w twoim przypadku, wtedy masz szansę na zmianę.

Najlepsze podejście, jakie widziałem, to nie gryźć zbyt wiele, ale zacząć od zmian przyrostowych, które będą miały najbardziej pozytywny wpływ. Na podstawie Twojego opisu lepiej zacząć od zarządzania wnioskami o zmianę. Gdy będzie to pod kontrolą, możesz zacząć szukać struktury usług lub innych przyrostowych ulepszeń projektu / kodu.

Najgorsze podejście, jakie widziałem, to zrobić wielki skok bezpośrednio ze starszego systemu do najnowszego i największego, na przykład, skacząc z działającego, ale niezgrabnego systemu VB6 / Classic ASP / COM + do systemu MVC / Entity Framework.

„Hej, szefie, po Big Project ja i zespół chcieliby trochę czasu, najlepiej X miesięcy, na uporządkowanie naszego kodu. Rzeczy, które powinny być możliwe do wykonania w ciągu kilku minut, wymagają godzin, ponieważ wszystko jest bardzo zdezorganizowane. Jeśli nie jest to możliwe zaraz po Big Project chcielibyśmy zaplanować realistyczny harmonogram ”.

(częściowo sparafrazowany z komentarza Azkara do pytania)

Zacznij czytać Joel on Software (Joel Spolsky / Założyciel Stack Exchange) ...

PIERWSZĄ rzeczą, którą bym zrobił, to wykonanie testu Joela .

Pozwoli ci to przedstawić to jako „Gdy szukałem sposobów na ulepszenie jako programista ... Natknąłem się na ten 12 pytań testowych na temat środowisk programistycznych, więc dla zabawy odpowiedziałem im, gdzie pracuję”. ... To z kolei sprawia, że ​​strona trzecia objaśnia, co jest nie tak z twoim kodem, a nie ty osobiście.

Gdy przeczytasz więcej o Pragmatic Practices , będziesz się doskonalić i wdrażać takie rzeczy, jak czerwony / zielony / refaktor, a to z kolei pozwoli ci wyczyścić bazę kodu, aby stała się łatwa do utrzymania. (z biegiem czasu)

Mam nadzieję, że to pomaga! Witamy w Programowaniu (wczorajszy kod zwykle jest do bani) ;-)

Szybka wskazówka: jeśli zaproponujesz zarządzanie z listą powodów, dla których powinieneś kodować inaczej, dołącz jako argument „Poprawione morale / warunki pracy dla programistów”.

Wyjaśnij, że zespół technologiczny będzie pisał więcej treści i utrzymywał czysty kod niż obecny bałagan, a to z pewnością poprawi twoje podejście do pracy. Może to być przydatny argument.

• Czy kierownictwo faktycznie dyktuje projekt? Jeśli masz za sobą większość zespołu, co Cię powstrzymuje? Bądź proaktywny i decyduj jako grupa. Wymyśl plan, aby wprowadzić go stopniowo . Więc zrób to.
• Czy kierownictwo dyktuje narzędzia programistyczne, których używasz? O ile zamiana zarządzania narzędziami nie jest czasochłonna, zwykle to nie obchodzi. Bądź proaktywny i wspólnie decyduj, jakich narzędzi programistycznych chcesz użyć. Jeśli potrzebujesz wykupić od zarządu, pokaż im plan migracji i analizę kosztów i korzyści. Więc zrób to.
• Czy kierownictwo narzuca języki, których używasz? Bądź proaktywny i zdecyduj jako grupa, czego użyć zamiast VBScript. Wymyśl plan jego stopniowego wdrożenia i zrób to. Jeśli potrzebujesz wykupienia zarządzania, pokaż im plan. Więc zrób to.
• Nie mam nic dla specyfikacji. Jest to zazwyczaj bardzo zależne od ludzi i procesów w twojej pracy. Określenie, co jest zepsute i minimalne zmiany wymagane do naprawienia procesu, wymaga czasu, analizy i zrozumienia tego, jak obecnie działają rzeczy i jak powinny one działać. Jeśli wiesz, że możesz wymyślić plan i spróbować przekonać kierownictwo.

Dostajesz więcej zmian i szacunku, jeśli zaproponujesz sposoby zmiany, które nie wymagają dużej ilości poświęconego czasu bez żadnej (lub miękkiej) wartości biznesowej do pokazania za to.

Mówiąc z doświadczenia: to nie jest łatwe. To prawie niemożliwe. Kierownictwo nie dba o to, aby kod był do bani i bardziej niż prawdopodobne jest to, że są całkowicie nieświadomi i / lub nieświadomi problemów, z którymi się borykają, bo inaczej rozwiązaliby go dawno temu i nie utknąłbyś z nim dzisiaj. Najlepszą rzeczą, jaką możesz zrobić, jest sporządzenie listy powodów, dla których kod jest do bani, a następnie uzasadnienie, dlaczego jest do bani, aby wykazać rzeczywistą wartość biznesową podczas refaktoryzacji / przepisywania.

Przykładem może być „Kod nie do utrzymania”:

Obecny kod nie jest możliwy do utrzymania z powodu X , Y i Z (podaj powody, dla których nie można go utrzymać ). To sprawia, że ​​żądania zmian i nowe funkcje są bardzo trudne, ponieważ X , Y , Z (powody, dla których wprowadzanie zmian jest trudne). Ponieważ zmiany są trudne, zespół programistów nie może łatwo reagować na poprawki i ulepszenia błędów.

Jedyną nadzieją jest to, że szef i kierownictwo wyższego szczebla nie są zbyt głupi, aby zrozumieć, jakie są konsekwencje dla kodu, i są gotowi przestać wysyłać nowe prośby o nowe funkcje, aby rozwiązać problemy, w przeciwnym razie twoje wysiłki będą daremne . Mówiąc z wcześniejszych doświadczeń, jest bardzo prawdopodobne, że nie zobaczą nic złego w kodzie i / lub twoi współpracownicy są zbyt bezrozumni, aby wnieść swoje obawy do kierownictwa.

Powodzenia. Będziesz tego potrzebować.

„Zacząłem świeżo po studiach” - powinienem odpowiedzieć na twoje pytanie.

Kierownictwo prawdopodobnie wie, że kod nie jest optymalny. Większość kodu jest, chyba że zatrudniłeś Raya Goslinga, Guido Van Rossuma lub kogoś naprawdę dobrego i drogiego do napisania.

Kierownictwo wie również, że działa, niezależnie od tego, która definicja „działa” dotyczy Twojej firmy (nie ulega awarii, sprzedaje, dostarcza raporty itp.).

Chcą, abyś utrzymał kod „działający” przy minimalnych kosztach. Nie chcą, aby propozycja drogiego projektu przepisała wszystko od nowa.

Taki przypadek biznesowy jest prawie niemożliwy do wykonania, ponieważ twój produkt to działające oprogramowanie (co już mają) nie elegancki kod.

Dodaj fakt, że w oprogramowaniu pojawienie się na rynku z pierwszymi funkcjami wiąże się z dużymi kosztami alternatywnymi. Jeśli naprawdę się nad tym zastanowisz, nie ma gwarancji długoterminowego zwrotu z inwestycji w czas.

To powiedziawszy, nadal dobrym pomysłem jest refaktoryzacja i naprawa drobnych rzeczy (takich jak uzyskanie dobrego VSS) po drodze w zarządzalnych kęsach. Ostatecznie jest to kwestia techniczna, a nie problem zarządzania. Po prostu rób to, co trzeba zrobić, jednocześnie spełniając obietnicę, a wszystko będzie dobrze. Kierownictwo prawdopodobnie nie będzie zainteresowane drobiazgowymi szczegółami jakości kodu, nawet jeśli zrobisz to solidnie.

Po prostu odejdź tak szybko, jak to możliwe (może nie odejdź zbyt wcześnie, ponieważ nie chcesz wyglądać na lejka). Fakt, że kodują, to bałagan, a ludzie tam przebywają, co oznacza, że ​​prawdopodobnie współpracujesz ze słabymi programistami. Każdy porządny programista, który dba o swoją pracę, nie będzie długo pracował nad takimi bzdurami.

Szansa, że ​​przepisanie nastąpi dość nisko, chyba że możesz bardzo wyraźnie wykazać, że warto zainwestować $$$.

Kierownictwo nie dba o kod. Dbają o to, żeby produkt mógł sprzedać.

Jeśli starszy system jest naprawdę, naprawdę zły i dodaje niedorzecznej kwoty narzutów dla większości zespołu (mówię większość, ponieważ zawsze jest facet, który albo koduje duże fragmenty, albo całość, i zna go jak tył jego dłoń), a następnie podejdź do nich i powiedz, że kosztuje to pieniądze biznesowe w czasie programowania, a to przyniesie satysfakcję klienta.

Ale po raz kolejny wciąż nie dbają o kod, dbają o produkt, więc chociaż ta odpowiedź może sprawić, że powiedzą „Tak, zróbmy to”, równie dobrze możesz uporządkować kod bez uzyskania zgody menedżera. Nie przesadzaj, upewnij się, że najpierw porozmawiasz z zespołem, nikt nie lubi przyjść i spróbuj użyć tej funkcji, której napisanie zajęło Ci 3 miesiące, a teraz wydaje się, że nie działa, ponieważ została zhackowana.

Podejdź do zarządzania w taki sposób, aby pokazać, że rozumiesz wpływ na budżet wprowadzania dużych zmian w kodzie i wpływ na budżet NIE dokonywania zmian. Podobały mi się słowa Emilio.

Należy pamiętać, że „stary” kod zawsze będzie okropny. Rozumiem przez to, że wszyscy stale rozwijamy się jako programiści. Piszemy dobry kod, a następnie uczymy się pisać lepszy kod później, a poprzedni „dobry” kod wydaje się okropny. Zbyt wielu programistów przyłapuje się na ciągłym ulepszaniu i marnowaniu większej ilości pieniędzy na dłuższą metę. To równowaga. To powiedziawszy, zawsze świetnie jest, jeśli możesz ulepszyć go w drodze. Kiedy idziesz zmodyfikować tę gigantyczną funkcję, podziel ją! W końcu gdzieś się dostaniesz.

Nie rób tego

W każdym razie przepisywanie dużego projektu od podstaw jest dużym błędem.

Nigdy nie sądziłem, że łatwo jest powiedzieć menedżerom, zwłaszcza kierownikom projektów, o złym kodzie i refaktoryzacji. Po pierwsze, muszą ci ufać, nawet jeśli jesteś starszym facetem, wciąż potrzebujesz czasu, aby zaufać. Po drugie, po prostu nie rozumieją, jak poważny jest problem. Jeśli dzisiaj jest ostatni dzień na wydanie nowej kompilacji, a kompilacja się nie powiedzie. Wiedzą, jak poważny jest, ale nigdy nie wiedzą, że kompilacja po prostu się nie powiodła, ponieważ wiele problemów, takich jak zły kod, nieodpowiednie testowanie itp.

Wykonałem zadania związane z konfiguracją i wdrażaniem w projekcie internetowym. Naprawianie nieoczekiwanych problemów za każdym razem, gdy wdrażam nową kompilację, zajmuje dużo czasu. Większość problemów dotyczyła bezpieczeństwa i integracji (między kilkoma aplikacjami WWW / Windows). Nasz kod jest do kitu, kod innych jest do kitu, to kompletny kod spaghetti.

Planowaliśmy nową wersję i zdecydowanie poprosiłem o pewne refaktoryzowanie, po prostu dodaj szczegółowy dziennik do kodu logowania / uwierzytelnienia, w którym często występowały błędy. Menedżerowie zgodzili się, ale potem została umieszczona na ładnej liście i nie wiem, czy to się stanie, ponieważ mieliśmy już dużą listę funkcji i napięte ramy czasowe.

Istnieją dwa rodzaje menedżerów: ci, którzy udają, że rozumieją, co robisz, i ci, którzy tego nie robią. Ci, którzy udają, że rozumieją oprogramowanie, będą ci wrogo nastawieni. Te, które nie są po prostu zirytowane przez ciebie.

W każdym razie menedżerowie są kłamcami, więc mają silną skłonność do zakładania, że ​​wszyscy inni są.

Chodzi mi o to, że jeśli powiesz, że oprogramowanie jest nieaktualne, uznają to za wymówkę. Nie obchodzi ich to.