Jak udowodnić, że aplikacja jest zbudowana na złej bazie kodu?

23

Obecnie sprawdzam system zbudowany przez niektórych programistów, którzy wcześniej pracowali w mojej pracy. System działa całkiem dobrze z punktu widzenia użytkownika, ale podczas zagłębiania się w przegląd kodu jest kompletnym bałaganem. Jestem bardziej niż przekonany, że sposób, w jaki aplikacja jest zbudowana, nie wytrzyma przyszłych aktualizacji, nie mówiąc już o dużym wzroście wykorzystania.

Problem polega na tym, że wiem, jak źle jest, ale moi przełożeni nie. Jak mogę to udowodnić mojemu menedżerowi, aby dostrzegł problem i mógł zostać przekonany do minimalnej segregacji na bieżącej bazie kodu, aw najbliższej przyszłości rozpocząć nową linię rozwoju kolejnej wersji aplikacji?

ChrisR
źródło
6
programmers.stackexchange.com/questions/59050/... Może zważasz na to, jak źle robi się „duże przepisywanie” zwykle z perspektywy biznesowej. To właśnie zrobiłby programista „wyższego poziomu”.
quentin-starin
22
@qes, jedyną gorszą rzeczą niż wykonanie „dużego przepisywania” jest paraliżujący strach przed „dużym przepisaniem”. Kiedy zacząłem swoją obecną pozycję, odziedziczyłem bałagan Perl CGI od dwóch lub trzech różnych programistów bez kontroli źródła, śledzenia błędów ani testów. Trochę to przekonało, ale otrzymałem zgodę na przepisanie w Ruby on Rails przy zachowaniu starszego kodu. 5 miesięcy później narzędzia były bardziej przyjazne dla użytkownika i mogliśmy dodawać nowe funkcje w ciągu dni lub tygodni zamiast miesięcy. Użytkownicy są zachwyceni i nie tracę zmysłów. „Duże przepisanie” wymaga solidnego uzasadnienia, a nie całkowitego unikania.
Jason Lewis
1
@JasonLewis: (Zgaduję, że nie podążyłeś za linkiem w moim poprzednim komentarzu?) Wydaje się to niewłaściwe dla kogoś, kto mniej niż rok temu sam określił się jako brak ważnych umiejętności, które posiadałby wyższy poziom, a nie wiesz, od czego zacząć, rozpoczynając nowy projekt.
quentin-starin
5
@JasonLewis Całkowicie się z tobą zgadzam. Za każdym razem, gdy ktoś pyta o przepisywanie aplikacji w SE, wiele osób przychodzi z tą ideologią „nie rób wielkiego przepisywania”. Myślę, że jest wiele powodów, aby tego nie robić, ale nie powinieneś tego unikać za wszelką cenę. Brałem udział w przepisywaniu 100 000 wierszy aplikacji kodu i odnieśliśmy duży sukces, bardzo podobny do tego, co opisałeś. Byliśmy nawet w stanie przepisać go moduł po module (pierwsza część interfejsu użytkownika, potem serwer, a potem reszta). 12 miesięcy później mamy bardzo zadowoloną bazę klientów i wszyscy są dumni z podjętej przez nas decyzji.
Alex
2
Jest to część bardziej ogólnego problemu: tego, że twój poprzednik dąży do natychmiastowych rezultatów kosztem długoterminowym. Podczas przejmowania musisz wyjaśnić, dlaczego nie możesz utrzymać tego samego wyniku.
David Thornley,

Odpowiedzi:

23

„Ale to działa teraz” to standardowa odpowiedź kierownictwa na uzasadnione frustracje inżynierów oprogramowania. Pierwszą rzeczą, którą bym zrobił, byłoby skompilowanie dokumentacji (jeśli istnieje) i wykorzystanie jej do wykazania sprzeczności między kodem a dokumentacją.

Jeśli możesz, przygotuj kompleksowy zestaw testów jednostkowych. Uruchom je przy każdej zmianie, aby móc udokumentować regresje, które można obwiniać o istniejącą bazę kodów.

Wreszcie, jeśli możesz przyciągnąć programistę z innego działu, któremu ufasz, poznaj kod drugiej pary. Jeden programista, który mówi „to bzdury”, jest łatwiejszy do odrzucenia niż wtedy, gdy starszy programista, który już od jakiegoś czasu go popiera i mówi: „Nie, Jim, ma rację. To bzdura na gównianym gównie.

Oczywiście wszystko zależy od środowiska, wielkości firmy itp.

Zawsze polecam zajrzeć do The Pragmatic Programmer, jeśli jeszcze go nie przeczytałeś. Wymagana jest nie tylko lektura dla każdego specjalisty ds. Oprogramowania, ale także kilka dobrych sugestii dotyczących zarządzania, współpracowników, użytkowników itp., Którzy nie postrzegają inżynierii oprogramowania jako rzemiosła.

Jason Lewis
źródło
7
Nie ma żadnych dokumentów, a kod jest prawie nie do przetestowania, chyba że zamierzamy go zreformować. Jestem dość pewny, że wsparło mnie wielu współpracowników, więc może pomóc inny programista w dyskusji.
ChrisR
@ChrisRamakers To doskonała wiadomość (wsparcie, a nie brak dokumentów!). Menedżerom trudniej (choć nie jest to niemożliwe) odmówić / odrzucić profesjonalną opinię wielu programistów. A jeśli twoi zwolennicy są dłużej w firmie, mogą mieć cenne doświadczenie w kierowaniu wewnętrzną polityką organizacji. Powodzenia!
Jason Lewis,
Dodatkowo, jeśli uda ci się uzyskać dostęp do oprogramowania do testowania obciążenia, możesz pokazać, w jaki sposób może ulec awarii pod dużym obciążeniem.
HLGEM
13

Z punktu widzenia zarządzania, nie ma nic złego w systemie i narzekasz, ponieważ [po prostu chcesz go przepisać / nie rozumiesz, co zrobili poprzedni inżynierowie / chcesz, aby praca była łatwa]. Trochę słomkowy mężczyzna, ale kiedy ktoś na szczycie widzi, że teraz wszystko działa dobrze, niechętnie widzi kryzys, w którym się znajdujesz (jestem pewien, że gdzieś tam jest alegoria zmian klimatu ...) .

Do pewnego stopnia mają rację. Kierownictwo widzi problemy, gdy wydania znacznie wykraczają poza pierwotne szacunki, szacunki wydają się zbyt wysokie dla wykonywanej pracy, „jest to niemożliwe przy naszej istniejącej bazie kodu”, a częste błędy przekraczają QA. Jeśli wszystko ładnie mruczi, łatwo poklepać cię po głowie i powiedzieć, abyś postąpił jak najlepiej, ponieważ nie wpływa to na wynik finansowy.

To, co należy zrobić, zależy od organizacji i samego oprogramowania. Zasadniczo jednak sugeruję udokumentowanie każdej komplikacji, która pojawia się w wyniku złego, starszego kodu. Przy szacowaniu zadań wyjaśnij kierownictwu, dlaczego Twoim zdaniem to zajmie tak długo, wraz ze szczegółowymi wyjaśnieniami na temat tego, jakie aspekty starej bazy kodu powodują dodatkowe koszty. Kiedy błędy są wprowadzane do kodu, podaj przyczyny, dla których ten błąd mógł się wślizgnąć, oraz sposób, w jaki odpowiedzialne są problemy w starej bazie kodu.

Sugeruję przekazanie twoich obaw zainteresowanym stronom w sposób, który sugeruje, że oprogramowanie przerosło swój pierwotny projekt i jest obecnie problematyczne z dalszym ulepszaniem.

Stefan Mohr
źródło
5

Dostępne są różne narzędzia, które mogą obejmować pokrycie kodu i przegląd kodu. Narzędzia Google odpowiednie dla Twojej technologii, zwykle są to standardowe narzędzia branżowe. Sugeruję, abyś użył tych narzędzi i opracował raport dotyczący jakości kodu i przedstawił go menedżerowi. Upewnij się, że twoja krytyka jest sprzeczna i niepolityczna.

ViSu
źródło
tak, zastanawiałem się nad obliczeniem średniej złożoności cyklicznej i wykorzystaniem jej jako argumentu, ale jestem pewien, że nie przyniesie to żadnego zarządzenia. Ale warto spróbować, dzięki
ChrisR
5
@ChrisRamakers: Nic nie można „udowodnić” kierownikowi. Zapomnij o „dowodzie”. Zbierać dane. Fakty są wszystkim, co masz. Więcej faktów jest bardziej przekonujące. Ale nie ma „dowodu”.
S.Lott,
4

Wybierz przykład, który jest łatwy do zrozumienia, gdzie zarządzanie uznałoby to za zwykłe żądanie zmiany, ale ze względu na istniejący projekt jest znacznie trudniejsze.

Nie chcesz, aby zastanawiali się nad konkretnym żądaniem, ale upewnij się, że dasz im znać, że tak będzie JAKIEKOLWIEK żądanie zmiany. Nikt nie chce być malowany w rogu za pomocą aplikacji. Programiści wierzą w YAGNI, ale zarząd wierzy w CYA.

Sugestie dotyczące testowania obciążenia mogą być dobrym podejściem, ale nie można ich przekonać, że obawy związane ze zwiększonym wykorzystaniem spełniają rzeczywisty potencjał wzrostu w świecie (firma nie podwoi się w ciągu jednego roku).

Wszystko jest względne. Mogą nie chcieć wkładać zasobów w ten projekt, jeśli mają plany na ważniejsze projekty, na które można spędzić czas. Nie daj się oznakować jako nie widzący dużego obrazu.

JeffO
źródło
1
Po wprowadzeniu zmiany pokaż plik różnic, który w złej bazie kodu dotknie wielu różnych plików źródłowych, ma „co to ma z tym wspólnego?” element itp. Wyjaśnij zarządowi, jak duża część tej pracy, tj. czas == $$, była związana ze słabą bazą kodu i że wszystkie zmiany będą miały tę cechę.
Larry OBrien
3

Kiedy mówisz o udowodnieniu czegoś, w grę wchodzą wszystkie metody naukowe, a to oznacza, że ​​jeśli zamierzasz zaakceptować obiektywne standardy decydowania o tym, co jest prawdą, musisz zaakceptować możliwość, że po zbadaniu, te irytujące fakty okazuje się, że nie jesteś po twojej stronie.

W twoim przypadku uważam, że są 2 rzeczy do udowodnienia.

Po pierwsze, że obecna baza kodów jest „zła”. Prawdopodobnie możesz udowodnić, że „profesjonalna opinia prawie wszystkich programistów badających ten kod jest taka, że ​​jest on zły”.

Po drugie, że lepiej byłoby przepisać bazę kodów. Jest to problem, ponieważ nawet jeśli pierwszy punkt jest prawdziwy, drugi może nie być. Ponadto nie masz wystarczającej wiedzy, aby dokonać tej determinacji. Jest to zadanie kierownictwa, a jeśli chcesz, aby szanowali twój profesjonalny osąd odnośnie pierwszego punktu, powinieneś uszanować ich w odniesieniu do drugiego punktu.

Ale nie mogą ustalić drugiego punktu bez dostarczonych informacji. Musisz przekazać, co wiesz o tym, w jaki sposób problemy w kodzie wpłyną na biznes, a także o tym, w jaki sposób przepisywanie wpłynęłoby na biznes. Jest to trudne, ponieważ oba obejmują przewidywanie przyszłości, która jest bardzo niepewna.

Ale możesz spróbować określić problem w kategoriach biznesowych. Ile dodatkowego czasu poświęca się na zmiany i regresje? Ile kosztuje przepisanie? Jak szybko koszty obecnego systemu wzrosną z czasem, jeśli nie zostaną przepisane? Co się stanie, jeśli zwiększy się użycie, jaka jest szansa katastrofy, jeśli obecny kod zostanie zachowany? Tak naprawdę nic nie wiesz, ale możesz zgadywać lepiej niż ktokolwiek inny. Podaj zakres lub coś, co pokaże, jak dokładnie możesz przewidzieć te rzeczy.

Większość programistów nie lubi utrzymywać kiepskiego kodu. Dlatego może być niefortunne, że przepisywanie kodu z perspektywy dewelopera nie jest łatwe, ale nie jest warte przepisywania z perspektywy biznesowej.

Na przykład, nawet jeśli przepisanie okaże się opłacalne, może być warte mniej niż koszt alternatywny wydania pieniędzy w innym miejscu w firmie. Albo zła baza kodu może zająć więcej czasu, aby zmienić i mieć więcej regresji, ale nie wystarczy, aby przepisanie było opłacalne. Być może będą chcieli zostać wykupieni w ciągu najbliższych kilku miesięcy, a wydawanie pieniędzy na przepisywanie pojawi się na książkach, ale błędne oprogramowanie nie.

Spróbuj myśleć o tym z perspektywy biznesowej i nie gotuj liczb, aby uzyskać to, czego chcesz. Duże przepisywanie prawie nigdy nie jest łatwe z biznesowego punktu widzenia. Jeśli chcesz udowodnić coś, czego nie da się bezpośrednio udowodnić, postaraj się to obalić. Jeśli nadal próbujesz wymyślić sposób, aby nie przepisywać od nowa, ale nic, co wymyślisz, nie ma sensu, może wtedy naprawdę nadszedł czas, aby przepisać od zera. A wysiłek ten pokaże twojemu kierownictwu, że poważnie podchodzisz do reprezentowania interesów firmy, a nie własnych (reprezentujesz interesy firmy, a nie własne, prawda?).

psr
źródło
2

Myślę, że to zależy od tego, co jest złe w bazie kodu. Bycie „nie tak, jak bym to robił” nie oznacza, że ​​jest to zła baza kodu.

Rzeczy, które faktycznie tworzą złą bazę kodu:

  • Luki w zabezpieczeniach

    Problemy, które narażają serwer, aplikację i / lub dane na podatność. Szczególnie wszystko, co naraża wrażliwe dane firmy, klientów lub klientów. Powinny być łatwe do udokumentowania.

  • Praca zepsuta

    Działa tylko dlatego, że masujesz dane i wykonujesz konserwację aplikacji prawie nieprzerwanie, aby działała. Jeśli odejdziesz i nikt nie weźmie luzu, przestanie działać. - Dokumentuj ile czasu spędzasz na tym. I zwróć uwagę, ile możesz zaoszczędzić. Dość często te procesy są również nieefektywne dla użytkowników i możesz to również udokumentować.

  • W rzeczywistości nie działa

    Wygląda na to, że działa, ale wyniki są niepoprawne. Powoduje to generalnie problemy w dolnej linii, takie jak niepasujące liczby, wysoki wskaźnik defektów itp.

Co nie jest zła baza kodu (po prostu nie jest dobra):

  • Napisane na przestarzałej nieobsługiwanej technologii. (VB6, COBOL, .net1.1 Itd.)

Zwróć uwagę na zalety migracji do nowej technologii. Spróbuj znaleźć ścieżkę migracji, która przenosi elementy na raz, aby zminimalizować ryzyko i zwiększyć zaufanie użytkowników i zarządzania. Upewnij się, że logika działa w zasadzie tak samo jak oryginał.

  • Nieudokumentowany / źle sformatowany kod

Jest to najłatwiejszy do naprawienia, ponieważ ogólnie można dodawać komentarze i poprawiać formatowanie bez faktycznego wpływu na kod. Ale nie wymaga przepisania. Jeśli uważasz, że jest to połączone z innymi problemami, pierwszą rzeczą do zrobienia jest naprawienie tego, abyś mógł lepiej ocenić wykonalność kodu.

SoylentGray
źródło
1

W pewien sposób odpowiedziałeś na swoje pytanie.

Aby przekonać ich do wydania pieniędzy na system, należy poczekać, aż użytkownik nie będzie działał dobrze. Jeśli uważasz, że się nie skaluje, poczekaj, aż to się zdarzy, lub wykonaj test obciążenia, aby to udowodnić.

Jest to prosta propozycja wyczyszczenia tej skali za X godzin.

Jonno
źródło
8
Jedyny problem polega na tym, że jeśli ponosi główną odpowiedzialność za system, zostanie obwiniony, gdy przestanie on działać. „Ale to działało zanim ty rozpoczęty!”, Oni mówią. Dlatego doradziłem proaktywne podejście. Ostrzeż ich z wyprzedzeniem, udokumentuj problemy, a następnie jego tyłek jest zakryty, gdy pęka, i nie tylko może powiedzieć „Powiedziałem ci to swojemu szefowi”, ale może powiedzieć „Powiedziałem mu to” szefowi swojego szefa.
Jason Lewis
3
@Jason - Rozumiem, o co ci chodzi, ale z mojego doświadczenia wynika, że ​​zaprzeczanie działa w dół i „powiedział mu, że” awansowanie łańcucha bardzo szybko się spotka z „graczem nieposiadającym zespołu” w drodze na dół.
Jonno
2
Jest bardzo wiele zależy od indywidualnej pracy, ale zgadzam się z tobą ... mógłbym sformułować go lepiej ... Moim głównym punktem było dokumentowanie przyczyny to wykraczających niepowodzenie z góry, argumentując punkt i prowadzenie dokumentacji dostępne dla kiedy to robi ... najlepszy scenariusz, możesz to naprawić. Średnia, nie jesteś wkręcony, gdy zawiedzie. Co najgorsze, głęboko zaznajomisz się z systemem i jego słabościami oraz z tym, jak je naprawić, aby imponująco wyjaśnić (w żywych szczegółach), w jaki sposób i dlaczego pozostawiłeś swoje ostatnie stanowisko potencjalnemu pracodawcy, kiedy skończysz poszukiwania pracy po jego awarii ;-)
Jason Lewis,
1
@JasonLewis Jeśli gracze w firmie używają takich zwrotów, I told you soto jest to toksyczna kultura winy, a nie miejsce, w którym OP chciałby pracować długo. Dobry menedżer nie obwinia, dobry menedżer uznaje problemy i opracowuje plan.
wałek klonowy
@maple_shaft Zgadzam się. Nie miałem na myśli tych słów dosłownie, bardziej odnosiłem się do objęcia wszystkich podstaw. Idealnie byłoby, gdybyśmy mieli dobrych, wspierających kierowników, aż do łańcucha dowodzenia. Często jednak godzimy się na podejście od przeciętnego do średniego, abyśmy mogli wykorzystać pracę, którą mamy, jako odskocznię do pracy, którą chcemy.
Jason Lewis,
1

Jest to trudna sytuacja, ponieważ z perspektywy użytkownika wszystko jest teraz w akceptowalnym i stabilnym punkcie. Przede wszystkim w przypadku menedżerów nietechnicznych obecnie nie ma się czym martwić, ale prośba o przepisanie bazy kodów jest ogromną decyzją i nie należy jej lekceważyć, zwłaszcza na podstawie opinii i wysiłków jednego człowieka (ciebie) .

Więc jesteś w trudnej sytuacji, próbując uzasadnić przepisanie ze względu na przytłaczający dług techniczny (Twoim zdaniem, nie mamy żadnych przykładów i musisz wierzyć na słowo), a także będąc w trudnym miejscu trudności z utrzymaniem i dodawaniem funkcji do tego systemu.

Twoje szacunki dotyczące nowych funkcji będą wysokie, uzasadnij te wysokie liczby faktami, udowadniając, że te rzeczy rzeczywiście zajmą dużo czasu. Jeśli nie przekażesz tego poprawnie, kierownik może po prostu założyć, że jesteś niekompetentny i na pewno tego nie chcesz. Kiedy kwestionuje wysokie szacunki, wyjaśnij, dlaczego uważasz, że skumulowany dług techniczny utrudnia możliwość szybkiego i taniego dodania funkcji do obecnego oprogramowania. Jeśli twój menedżer ma dwie komórki mózgowe do zacierania się, zacznie bardzo szybko rozumieć.

Chodzi o to, że nie powinieneś próbować przekonywać swojego kierownika, ale kieruj swoim menedżerem odpowiednimi (i starannie dobranymi) informacjami, aby przekonał się, że przepisanie jest akceptowalnym kursem. Musisz sprawić, żeby kierownik cały czas myślał, że to jego pomysł.

wałek klonowy
źródło
1

Najpierw określ skumulowane zadłużenie techniczne w bazie kodu. Następnie spójrz na to pytanie i odpowiedzi , w których wyjaśniono, jak przekonać kierownictwo do spłaty zadłużenia technicznego przed dalszym postępowaniem.

BЈовић
źródło
0

Istnieje powód, dla którego całe dojrzałe oprogramowanie wygląda na bałagan:

  1. Cały bałagan koduje krytyczną logikę, na której opiera się firma. Bez tego nic nie działa. Wszystko było konieczne, aby rozwiązać problem użytkownika.
  2. Wykorzystuje nieco przestarzałą technologię. Obecni programiści myślą, że jeśli nie używa magii szablonów, to tylko bałagan. To jest zepsuty widok. Każdy, kto spóźni się na większy projekt, przejdzie ten etap, poznając wszystkie szczegóły.
  3. Wymagania, które kiedyś były krytyczne, nie są już tak ważne. Wynika to z faktu, że oprogramowanie już rozwiązało te problemy. Spóźniając się z projektem, może wydawać się, że oprogramowanie jest złożone bez uzasadnionego powodu - problem już nie istnieje, ale złożoność kodu wciąż istnieje.
tp1
źródło
Tego rodzaju podejście prowadzi programistów do usprawiedliwienia ogromnego technicznego długu wynikającego z ignorancji lub lenistwa. Zadaniem programisty jest kodowanie logiki biznesowej za pomocą abstrakcji. Zmienna specyfika powinna żyć w metadanych, a nie w zakodowanych liczbach magicznych. Po drugie, „nieco przestarzały” może być subiektywny. IMHO, „nieco przestarzały” oznacza, że ​​platforma / platforma jest nadal aktywnie rozwijana i mam ścieżkę aktualizacji. Alternatywą jest „przestarzała”. Numer 3 jest niewybaczalny. Właśnie opisałeś cruft. Nikt nie dokonał refaktoryzacji ani nie wyczyścił bazy kodu, a czy jest to do przyjęcia?
Jason Lewis
jasne, ale jaki jest wynik po zakodowaniu logiki biznesowej za pomocą abstrakcji ... Kod będzie wyglądał na skomplikowany. To jest definicja „bałaganu”. (3) nie jest cruft, ponieważ złożoność jest nadal wymagana; potrzeba jej nie zniknęła nawet po rozwiązaniu problemu.
tp1