Jakie jest najlepsze podejście do audytu dużej aplikacji WWW java/j2ee?

Question

Muszę przeprowadzić audyt dużej aplikacji WWW Java/J2ee, która rozwinęła się przez kilka kolejnych lat. Została napisana przez inną firmę, nie tę, dla której pracuję. W jest to stan, w którym trudno jest się rozwijać i utrzymywać, nowe funkcje są trudne do dodania i często prowadzą do błędów, które kiedyś pojawią się w produkcji . Wydaje się, że jest jakiś skopiowany/wklejony kod, który spowodował duplikację kodu. Obecna aplikacja to coś w rodzaju zakupów online z treściami podobnymi do cms tu i tam. To głównie Struts i trochę wiosny w nowszych częściach kodu, może niektóre ejbs wrzucone na dobre pomiary w postaci . Dostępnych jest kilka testów jednostkowych, ale nie wiele z nich. To są rzeczy, o których mi mówiono, nie widziałem jeszcze prawdziwego kodu.

Moja firma przedstawi propozycję przepisania części tej aplikacji, aby zmniejszyć złożoność, poprawić jakość i modułowość oraz umożliwić łatwiejsze dodawanie nowych funkcji bez zniekształceń. Przed dokonaniem jakiegokolwiek zatwierdzenia, chcieliby Państwo uzyskać pewien szacunek jakości istniejącego kodu i ocenić, ile jego części można ponownie wykorzystać, aby uzyskać więcej niż domysły na temat tego, co będzie konieczne. done - przepisanie pełne lub częściowe przepisanie na .

Połów jest taki, że będę musiał to zrobić w bardzo krótkim czasie (kilka dni), więc jestem próbuje opracować plan, co można zrobić w tak krótkim czasie. Co jestem thiking jest:

• check out "podstawowe" rzeczy - obróbka wyjątki zalogowaniu
• Sprawdź poziom licowania (widoki, kontrolery, warstwy DAO)
• zmierzenia rzeczywistego pokrycia urządzenie testuje
• może uruchomić jakąś Checkstyle, Findbugs i PMD nad projektami
• ...

więc rzeczywisty pytanie, co inne rzeczy sh Czy powinienem wziąć pod uwagę/sprawdzić/zmierzyć/etc?

Nie jestem pewien, jakie numery mogę uzyskać z tego i jeśli to naprawdę znaczy coś, mam wrażenie, że to, co pyta kierownictwo jest rodzaju niewłaściwego podejścia , więc drugie pytanie byłoby: czy ktoś ma lepszy pomysł?

Doceniam każdy pomysł, sugestię, komentarz na ten temat.

Edit: będę dodanie dwóch martwych detektory kodu do mieszanki: UCD i DCD

Answer 1

Miałem dwie aplikacje internetowe z podobnymi ustawieniami jak ty. Przestałem używać FindBugs i Checkstyle, ponieważ pokazały ponad 10.000 problematycznych punktów. Aplikacje wykorzystywały dostęp do danych na poziomie JDBC, JSP do prezentacji i niestandardowe ramy dla wysyłania żądań. Na szczęście dla mnie te ustawienia niskiego poziomu pozwoliły mi zrobić rozszerzenia i poprawki na średnim poziomie trudności. W trakcie 3-letniego projektu pozostało tylko około 20% pierwotnego kodu. Wcześniej czy później wszystko inne musiało zostać zmienione, zastąpione lub usunięte (i wreszcie mogłem użyć FindBugs i Checkstyle).

Mamy też do czynienia z dylematem pełnego przepisać. Jednak było na to kilka czynników:

• Nie jestem pewien, czy klient zapłaci za całkowite przepisanie.
• Brak dokumentacji funkcjonalnej i technicznej powoduje, że wykonanie pełnej przeróbki jest ryzykowne.
• Manhours, aby w pełni zrozumieć kompletną aplikację, było zbyt wysokie. Klient prędzej zażądał wymaganych zmian.
• Użytkownicy, którzy dostosowali się do prezentacji i zachowania strony. Trudno było przekonać użytkowników do korzystania z nowego interfejsu dla starych funkcji.
• Jeśli dokonamy całkowitego przepisania, musimy dostarczyć pełną dokumentację. W celu aktualizacji potrzebowaliśmy udokumentować tylko naszą część.
• Trudno przekonać kierownictwo (własne i klienta) do przepisania, jeśli program działa (mniej więcej)
• Firma miała własne zasady PMD, a kod nie przeszedł. Łatwiej było argumentować, że wystarczy, że nowe części zdadzą test.

Sprowadza to, co chcesz zrobić.

Chcesz przerobić, pomimo złożoności?

• Połóż nacisk na błędy kodu. Duże wykresy kołowe z dużą ilością czerwieni są przekonujące.
• Wyjaśnij właściwości programu i sposób, w jaki nie pasują one do wizji firmy.
• Pokaż opcje ulepszeń wykraczające poza aktualne wymagania i opisz, w jaki sposób bieżąca wersja nie spełnia wymagań.
• Wywiady z prawdziwymi użytkownikami. Mogą wskazać ważne problemy z aktualną wersją.
• Być tanie, ale dobrym estymatorem. Możesz opóźnić niektóre koszty do fazy konserwacji.

Nie chcesz przepisywać?

• Połóż nacisk na koszty, szczególnie na czas wymagany od klienta, aby ponownie przetestować wszystko.
• Wyróżnij potencjalne problemy z zerwaniem funkcjonalności.
• Poproś o pełnoetatowego autora dokumentów.

Jeśli chcesz spróbować kodu, spróbuj dodać Hello World! funkcja/ekran do aplikacji. To mówi, jak ciężko i jak szybko można wdrożyć nowe rzeczy.

Answer 2

Lubię lista całkiem sporo. Myślę, że masz doskonały plan ataku, aby zacząć.

Spoglądałbym z naciskiem na standaryzację na Spring lub EJB 3.0, ale nie na oba.

Nie czytałem sam, ale zastanawiam się, czy książka Michaela Feathersa "Working Effectively With Legacy Code" ma jakieś dobre pomysły?

UPDATE:

Może pomóc rzeczy poprzez umieszczenie ich na zautomatyzowanej produkcji i ciągłej integracji - tempomat, Hudson, lub zespół City. Jeśli będziesz musiał dokonać jakiegokolwiek refaktoryzacji, to pomoże.

Answer 3

Koncentrujesz się na łatwości konserwacji i rozszerzalności, która jest ważna.

dodałbym patrząc na jak długo ma zamiar podjąć, aby ponownie uruchomić projekt. Czy używają kontroli źródła? Czy mają oddzielne środowiska do integracji i testowania akceptacji przez użytkowników? Czy istnieje serwer kompilacji?

Kiedy trzeba wydać dwa miesiące zanim pojawi się pierwszy poprawa ktoś musi zarządzać oczekiwania klienta z góry.

Answer 4

W rzeczywistości oni nie będą płacić za pełną przepisać, ponieważ:

• Jest recesja, koszt ciebie przepisywania go od nowa będzie wysoka

• Mogli próbować sprzedać firma ASAP

• kierownictwo nie nic na temat rozwoju oprogramowania zrozumieć

Chciałbym najpierw pójść z kilku prostych faktów:

• Za pomocą narzędzia do wyświetlania Sloc projektu
• Run jak planowano FindBugs i ostatecznie PMD, żeby oszacować wad
• Czy szybkie profilowanie sesja
• Sprawdź różne warstwy
• Zobacz (połączenia strumieni, hibernacji lub JDBC, itd.), jeżeli środki są na ogół zamknięte
• Zobacz, czy technologie są stosowane tam, gdzie nie mają zastosowania (EJB, Web Services, etc.)
• Zobacz, w jaki sposób obsługi wyjątków i zalogowaniu
• Zobacz, czy nie ma zbyt wiele lub zbyt mało abstrakcji
• Zobacz, czy można dodać kilka klas bazowych w celu zmniejszenia powielania kodu

staramy się wyciągnąć szybki schemat architektura aplikacji, jeśli nie dadzą Ci o tym dokumentu.

Zbierz kilka statystyk i niektóre fakty, napisz raport i wyślij je do firmy. Będą chcieli zminimalizować koszty, a poprosią cię, abyś nie naprawiał kodu, który nie jest zepsuty. Zaczynasz od statystyk, następnie do faktów i propozycji z czasem/przybliżonym procen- tem wpływu/ceny.

Zwykle starsze aplikacje Struts to pita do utrzymania, już to zrobiono. Gdyby to nie było częścią twojej pracy, powiedziałbym, że odpuszczę. Jeśli natkniesz się na "samodzielne" strony, które nie zawierają wielu szablonów i podlegają wielu zmianom, zaproponuj przepisanie ich za pomocą innej technologii.