Jak podejść do refaktoryzacji istniejącej aplikacji internetowej?

11

Ostatnio dużo czytam i myślę i doszedłem do wniosku, że może powinienem przemyśleć swoją strategię rozwoju sieci. Robię dużo programowania w locie, a przez 2 lata pracowałem nad aplikacją PHP, co mogło się zacząć, gdy małe narzędzie stało się całkiem dużym projektem. Ale jest mnóstwo starszego kodu ode mnie i mojego poprzednika, fragment kodu, który mógł mieć sens w tym czasie, ale teraz wątpię w użyteczność tego kodu w jego obecnej formie. Co więcej, takie rzeczy jak testy jednostkowe i Test-Driven Development nie były w moim zakresie do niedawna.

Jak więc podejmiesz decyzję o refaktoryzacji aplikacji internetowej? Jakich rzeczy powinienem szukać i w jakiej kolejności? Co z grą przeglądarkową a funkcjonalną aplikacją internetową? Czy byłaby wtedy różnica w podejściu?

Eldros
źródło
4
Jeśli nie jest zepsuty, nie naprawiaj go. Poświęć więcej czasu na pisanie testów, a mniej na wprowadzanie niepotrzebnych zmian.
Macneil,
Po prostu z zainteresowania. W jakim języku / technologiach napisałeś swoją aplikację? Co to za strona? Zobacz welie.com/patterns -> Kontekst projektu -> Typy witryn
JW01
@ JW01 Używam PHP do logiki wewnętrznej i AJAX do zarządzania widokami i sprawdzania poprawności formularzy. Byłby to wariant wzorca aplikacji internetowej, ale dostępny tylko w danym środowisku, ponieważ jest to narzędzie wewnętrzne.
Eldros,
Kiedy odpowiedziałem na pytanie, miałem zupełnie inny obraz Twojej aplikacji. Masz o wiele więcej swobody w zakresie zmiany interfejsu API niż w domenie publicznej.
JW01,
@ JW01 Nie chciałem być zbyt konkretny, ponieważ chciałem, aby to pytanie było przydatne także dla innych.
Eldros,

Odpowiedzi:

6

Prawie w ten sam sposób podchodzisz do dowolnego starszego kodu. Znajdujesz kawałek, który można przetestować, piszesz dla niego testy i refaktoryzujesz.

Jeśli nie możesz znaleźć elementu, który można łatwo przetestować, musisz go przetestować bez uprzęży bezpieczeństwa zestawu testowego, w którym to przypadku bardzo ostrożnie zmieniasz fragment kodu, który można prawie przetestować, aby można go było przetestować.

Kod, który nie wyświetla rzeczy w przeglądarce - kod „infrastruktury”, modele, dane dotykające bazy danych - może być dobrym miejscem do rozpoczęcia.

Edycja: Testowanie interfejsu użytkownika: Z ostrzeżeniem, że mam tu niewielkie doświadczenie, robi to mój przyjaciel: uruchamia kawałek kodu generującego HTML. Następnie włamuje się do swojego kodu i porównuje nowo wygenerowany kod ze starą wersją (używając diff; nie zautomatyzował do końca). Zmiany w HTML oznaczają, że Twoje refaktoryzacja się zepsuła.

Frank Shearar
źródło
Jak poleciłbyś przetestować część „widok” starszej aplikacji - IE, część HTML / JavaScript / CSS / etc? Zgadzam się, że testowanie jednostkowe jest dobrym rozwiązaniem, ale testowanie kodu aplikacji wydaje się trudne do zautomatyzowania.
Justin Ethier,
podczas tworzenia testów dla internetowego interfejsu użytkownika - porównywanie starego HTML-a z nowym HTML-em jest dość delikatnym sposobem robienia rzeczy. Zazwyczaj identyfikuję semantykę strony internetowej i ją testuję. Tj. „Czy zmienił się nadruk internetowy (tytuł strony, nagłówek, słowa kluczowe, linki wychodzące, formularze)?” nie „Czy HTML się zmienił?”.
JW01,
Możesz testować aplikacje internetowe za pomocą „bezgłowej przeglądarki” - w zasadzie biblioteki, która służy do testowania jednostkowego tego, czym jest przeglądarka dla pracownika działu kontroli jakości. W świecie Java są HTMLUnit (czysta Java, samodzielny) i WebDriver (zdalnie steruje prawdziwą przeglądarką, taką jak FireFox). Mój projekt ma zestaw setek takich testów.
Tom Anderson,
@ JW01 Masz absolutną rację - jest bardzo delikatna. Doskonale nadaje się do testowania refaktoryzacji w sposób jednorazowy: możesz sprawdzić, czy refaktoryzacja nie zmieniła danych wyjściowych, ale za każdym razem, gdy zmieniasz wygenerowany HTML, musisz zapisać „nowy oczekiwany” HTML.
Frank Shearar,
10

Jest świetna książka na ten temat zatytułowana „Efektywna praca ze starszym kodem” autorstwa Michael Feathers. Spójrzmy prawdzie w oczy, wszyscy mamy starszy kod.

Najważniejsze jest przetestowanie nowego kodu, który tworzysz. Ponieważ musisz dotknąć innych fragmentów kodu, znajdziesz również możliwości przetestowania tych fragmentów. Jest to długi, powolny proces, ale jeśli wykonujesz go systematycznie, z czasem możesz naprawdę poprawić ogólny produkt.

Marcie
źródło
3
„Spójrzmy prawdzie w oczy, wszystko, co teraz robimy, to pisanie dziś oprogramowania przyszłości”. - Martin Fowler
Frank Shearar,
3
  • Tak - aplikacje internetowe różnią się od witryn internetowych

Traktowałbym je osobno. Jeśli masz jedną część witryny, która jest po prostu zbiorem dokumentów (które wyglądają tak samo dla anonimowych użytkowników i zalogowanych użytkowników) - wtedy najlepsza metoda ich struktury różni się bardzo od aplikacji internetowej obsługującej dynamicznie różne strony do każdego użytkownika. Podziel te dwie części witryny na dwie aplikacje / komponenty i postępuj inaczej z każdą częścią.

  • Zacznij korzystać z kontroli wersji

Gdy twój kod jest pod kontrolą wersji, możesz przejść i, pewnie, usunąć niepotrzebny kod, który wcześniej trzymałeś „na wszelki wypadek” itp. Nie wiem, jak przetrwałem bez kontroli wersji.

  • Zmniejsz nieskończoności

Jeśli wszystkie cztery adresy URL wskazują ten sam zasób, problem jest znacznie większy. W końcu masz do czynienia z nieskończoną liczbą adresów URL. Jak najszybciej możesz się upewnić, że masz zasady normalizacji adresów URL. Gdy to zrobisz, możesz zacząć przypisywać znaczenia semantyczne do adresów URL i mieć możliwość wyszukiwania wstecznego od zasobu do adresu URL. Umożliwia to oddzielenie „odcisku internetowego” od „zasobów” witryny.

Musisz zadać sobie pytanie „podany adres URL, jaka jest jego znormalizowana forma?”. Po przypisaniu tego. Następnie 50 000 lub więcej adresów URL w Twojej witrynie można zmniejszyć do 2000. co jest o wiele łatwiejsze do zrozumienia i zarządzania w twoim umyśle.

patrz: http://www.sugarrae.com/be-a-normalizer-a-c14n-exterminator/

  • Zacznij od modelowania „czym jest”, a nie „tego, czym chcesz”

Jeśli porządkujesz starszą witrynę, która od samego początku nie została zaprojektowana z myślą o najlepszych praktykach, kuszące jest przejście od „bałaganu” do „idealnego projektu”. Uważam, że musisz to zrobić w co najmniej dwóch krokach: „bałagan” -> „dobrze wymodelowany starszy kod” -> „idealny nowy kod z dodatkowymi funkcjami”. Przestań dodawać funkcje. Skoncentruj się na naprawie bałaganu lub zamknięciu go za warstwą antykorupcyjną. Tylko wtedy możesz zacząć zmieniać projekt na coś lepszego.

Zobacz: http://www.joelonsoftware.com/articles/fog0000000069.html

Zobacz: http://www.laputan.org/mud/

  • Testowanie to dobry pomysł.

Utwórz zestaw testów / strukturę i zacznij dodawać testy. Ale dość trudne jest przetestowanie starszego kodu. Więc nie rozłączaj się zbytnio. Tak długo, jak masz tam strukturę, możesz stopniowo dodawać testy.

Zobacz: http://www.simpletest.org/en/web_tester_documentation.html

  • Miejcie odwagę w swoich przekonaniach

Większość literatury na temat najlepszych praktyk tworzenia oprogramowania dotyczy komputerów stacjonarnych / aplikacji Enterprise App Centric. Gdy Twoja witryna jest w chaosie, czytasz te książki i możesz być pod wrażeniem mądrości, która z nich płynie. Ale nie zapominaj, że większość tych najlepszych praktyk została naliczona w czasach, zanim internet / SEO stały się ważne. Wiesz dużo o nowoczesnej sieci, więcej niż wspomniano w klasycznych książkach, takich jak POEA, Gof itp. Jest z nich wiele do zrobienia, ale nie odrzucaj całkowicie własnego doświadczenia i wiedzy.


Mógłbym kontynuować. Ale to są niektóre rzeczy, które wybrałem, przekształcając starą starszą witrynę w lśniącą nową.

JW01
źródło
Dobre linki referencyjne!
Nilesh
2

Przed zrobieniem czegokolwiek najlepiej mieć kontrolę nad projektem. W ten sposób możesz wycofać zmiany lub pracować nad głównymi zmianami w oddzielnej gałęzi, a także oznaczyć kamienie milowe.

Następnie napisz testy dla każdego kodu, który chcesz zmienić. Nie musisz robić wszystkiego od razu, pisząc testy na wszystko. Właśnie nad tym planujesz natychmiast pracować. Teoria głosi, że przy wystarczającej ilości czasu większość bazy kodu zostanie objęta testami. Zauważ, że niektóre refaktoryzacje są „bezpieczne” bez testów - są one udokumentowane w książce Legacy Code wspomnianej wcześniej i bez wątpienia gdzie indziej.

Po wprowadzeniu testów dla sekcji kodu zmień kod. Rób wszystko, co musisz, o ile testy będą nadal zaliczane.

Nawet ze starszym kodem możesz wykonywać TDD, jeśli wprowadzasz zmiany lub uzupełnienia. Po prostu napisz testy dla przewidywanych zmian, zobacz, jak się nie udają, a następnie wprowadź zmiany.

Niektóre narzędzia mogą być przydatne tutaj. NDepend może wskazać wysoce sprzężony kod i inne zapachy. NCover śledzi Twoje poziomy pokrycia kodu. FxCop jest zasadniczo narzędziem do sprawdzania poprawności kodu, wykraczającym poza to, co robi kompilator. Są to wszystkie przydatne narzędzia, które mogą się przydać przy projektach o dowolnym rozmiarze, szczególnie w przypadku starszych odmian.

Ostatecznie jest to proces wieloetapowy. Nie próbuj robić tego wszystkiego naraz, po prostu weź to po trochu.

Grant Palin
źródło
-2

Jeśli to wystarczająco brzydkie, żeby mnie wkurzyć, to wystarczająco brzydkie, żebym mógł usunąć całą rzecz i napisać kroplę w zamian.

Przekonasz się, że najczęściej zajmuje to tyle samo czasu, co siedzenie tam i chodzenie na palcach wokół niezorganizowanego i nieudokumentowanego bałaganu i delikatnie go pieścić.

Sneakyness
źródło
2
Nie zgadzam się (chociaż nie dałem ci -1). joelonsoftware.com/articles/fog0000000069.html
JW01
1
Naprawdę zbyt wielka jest decyzja sytuacyjna, by się obronić. Mogę tego nie robić, gdy pracuję nad ogromną biblioteką Objective-C, jednak nie mam żadnych wątpliwości co do pisania zupełnie nowej biblioteki javascript.
Sneakyness
Bardzo zły pomysł! Żałuję, że nie przeczytałem artykułu Joela Spolsky'ego, który @ JW01 był powiązany 2 lata temu, zanim zdecydowałem się przepisać istniejącą aplikację PHP za pomocą Angular & Bootstrap. Angular i Bootstrap to świetne technologie, ale wciąż próbuję przekonwertować tę starą aplikację 2 lata później. Powinienem był właśnie zmodyfikować istniejącą aplikację, a nie zgrać / wymienić.
Zack Macomber,
Zgadzam się, zwłaszcza przy uwzględnianiu twojego komentarza. „scenariusz” jest kluczową rzeczą, która determinuje decyzję. Czy powinieneś pozbyć się tego ogromnego interfejsu API, który obsługuje całą firmę? Kto wie, jest wiele do rozważenia. Chciałbyś wcześniej przetestować testy. Artykuł, do którego prowadzi link, jest zbyt liniowy, jakby istniał jeden rozmiar dla wszystkich, ale co z sytuacją, gdy coś jest wadliwe lub naprawdę stary kod? Czy ten artykuł naprawdę sugeruje, że nie przechodzimy od starszych wersji kodu, który jest łatwiejszy do odczytania i utrzymania? W świecie deweloperów nie ma czerni i bieli, tylko scenariusze i decyzje
James