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

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?

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.

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.

• 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ą.

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.

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