W jaki sposób uzupełnisz swój stary kod PHP?

Question

Niedawno zaangażowałem się w projekt, w którym gra internetowa wykorzystuje silnik napisany w PHP. Gra działa dobrze, ale może być bardziej solidna i ma więcej funkcji - a kod jest zarówno stary, jak i dość brzydki.

Problem z tym kodem (i ogólnie podejrzanym kodem PHP) jest taki, że ewoluował on tam, gdzie jest i jest niezbyt dobrze zbudowany, ma wiele prawie identycznych wycinanych/wklejonych fragmentów kodu, i intensywnie korzysta z globali, nawet jeśli chodzi o funkcje. Oczywiście żadna jednostka nie testuje, a kod jest zakodowany na sztywno, aby użyć konkretnej bazy danych i opiera się na łańcuchach $ _REQUEST ze strony internetowej, która wywołuje kod.

Właściwe byłoby wyciągnięcie fragmentów kodu jako podfunkcji, posprzątanie ich i dodanie testów jednostkowych, aby upewnić się, że nadal działają, dodając kilka pozorowanych obiektów po drodze. Jednak robienie tego całkowicie ręcznie jest nudne i podatne na błędy i zastanawiam się, jak to zrobić - czy istnieje IDE lub narzędzie, które może pomóc, na przykład? Chciałbym mieć narzędzie, które może pomóc w stworzeniu funkcji z określonego fragmentu kodu, zasugerować, które zmienne powinny być parametrami, według wartości lub odniesienia, automatycznie dodać $ to-> referencje itp.

Czy to za dużo zapytać, czy jest dobre rozwiązanie?

Dzięki!

Answer 1

Allan, nigdy nie widziałem tak skutecznego narzędzia do refaktoryzacji. Nawet refaktoryzacja Eclipse dla Javy nie jest kompletna. Jednak istnieją pewne typowe wskazówki dotyczące refaktoryzacji. Zwykle refaktoryzuję aplikacje w dwóch krokach.

1. Rozdziel rzeczy. Wyodrębniam pliki db i model i wyodrębniam je z kodu głównego. Pomoże w tym jakaś reprezentacja obiektu. Sprawdź wzór Active Record lub DAO dla dowolnej pracy ORM. Kod HTML może zostać usunięty z głównego kodu i przeniesiony do plików szablonów. Sprawdź ładny silnik szablonów z silnym wsparciem dla przetwarzania logiki widoku - Smarty.

2. Umieść rzeczy w strukturze MVC.MVC to solidna architektura, która wyjątkowo dobrze pasuje do aplikacji internetowych. Użyj jednego ze szkieletów PHP, aby związać luźne pliki PHP z metodami kontrolera. Ramy ułatwiają zarządzanie adresami URL, żądaniami HTTP, przekazywanie parametrów, zarządzanie danymi logowania i zwykle zapewniają pewne mechanizmy kontroli dostępu.

Ale najważniejsze jest: nie rób niczego poza naprawą. To refaktoryzacji, a nie przebudowy ;-)

Answer 2

Czuję twój ból. Jednak nigdy nie słyszałem o takim narzędziu, przynajmniej nie dla PHP.

Answer 3

Nie sądzę, że język jest wystarczająco skonstruowany, aby umożliwić półautomatyczny refaktoryzacji. W każdym razie nie znam żadnej aplikacji, która mogłaby to zrobić, ale z drugiej strony - zrobienie tego wszystkiego ręcznie sprawi, że będziesz dobrze zaznajomiony ze źródłem, może ci to później pomóc, że znasz swoją drogę znacznie lepiej niż ty dzięki zautomatyzowanym narzędziom.

Answer 4

Ten artykuł naprawdę podkreśla niebezpieczeństwa refactoring/redevelopment starego kodu brzydkiego:

http://www.1729.com/blog/EconomicsOfTestingUglyCode.html

Moje podejście do rozwiązania jest na ogół jeden mały problem w czasie, który rozpoczyna z ukrywaniem znacznej części starego kodu za interfejsem, gdzie można go traktować "później" bez wpływu na nowy kod.W ten sposób wszystko, co piszę, może być dobrze zaprojektowane i mieć solidną strukturę, ale nie muszę tracić zbyt wiele czasu na próbę refaktoryzacji, a następnie przetestowanie złego kodu tygodniami/miesiącami/latami.

Answer 5

Żadne narzędzie nie przyjmie fugly kodu i jakoś sprawi, że będzie znowu ładny. Wyrażenie "back-to-formuła" jest dość przerażającą perspektywą dla dojrzałego projektu, ale bez problemu ...

Sugerowałbym przeniesienie go do porządnego środowiska MVC. W takim przypadku może nie być to zły czas na przepisanie strukturalne, więc wszystkie klasy są zoptymalizowane (coś, co rzadko dzieje się naturalnie z ewoluującym kodem). To zajmie dużo czasu i nie będzie bólu, gdy rzeczy nie działają zgodnie z oczekiwaniami.

To duży krok, ale tak właśnie dzieje się, gdy pozostawia się kod gnijący.

Twoje inne opcje:

1. Czy częściowej restrukturyzacji, gdzie wszystko nowy kod następuje reżim zadanej i stary kod powoli nowa.
2. Napraw swoje błędy i nie przeprowadzaj żadnych restrukturyzacji.

Answer 6

Przeszukałem tę sprawę i znalazłem interesujący blog klienta Accurev.

http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/

Po odpowiednim narzędziem kontroli wersji w przyborniku nie zaszkodzi.

Answer 7

Z mojego doświadczenia wynika, że ​​całkowite przepisanie jest o wiele bardziej ekonomiczne w tej sytuacji.