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

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?

„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.

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.

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.

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.

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?).

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.

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.

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ł.

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.

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.