Wskazówki dotyczące planowania przepisywania dużego projektu PHP?


13

Zdecydowałem się całkowicie przepisać framework PHP (używając MVC), nad którym pracuję, włączam i wyłączam od lat. Do tej pory mój problem polegał na tym, że po prostu wpadałem na pomysły, wrzucałem je do Traca jako bilety i dodawałem później - nie martwiąc się o sam projekt frameworka. Z czasem spowodowało to pewne problemy i myślę, że przepisanie byłoby pomocne, ale nie jestem pewien, od czego zacząć od planowania - wiem, że nie chcę używać Traca i wiem, że potrzebuję więcej niż tylko bilety i kamienie milowe - ale czego jeszcze potrzebowałbym?

Naprawdę chcę dokładnie zaplanować to przepisywanie, chcę szczegółowo opisać każdą funkcję, którą chcę, gdzie będzie i jak będzie się łączyć z każdą inną częścią - ale nie mam doświadczenia z tym poziomem planowania. Jakakolwiek rada? Jakieś programy, które pomogą? Mam już dość Traca, nigdy tak naprawdę go nie lubiłem.

Wiem, że będę potrzebować dokumentu projektowego, ale czy jest jakiś układ, który powinienem zastosować? Potrzebuję też śledzenia błędów, biletów, kamieni milowych itp., Ale poza Tracem nie wiem też, co jest dobre. Jestem pewien, że potrzebuję więcej, ale nie mam pojęcia, co, więc każda pomoc byłaby mile widziana.


dlaczego chcesz to przepisać? Dlaczego nie przebudować go w miejscach wymagających poprawy? Kiedy przepisujesz coś od zera, prawdopodobnie eliminujesz stare problemy z nowymi.

@Gordon może jest napisane tak strasznie strasznie, że przepisanie go jest lepsze niż refaktoryzacja.
prawy

Przepisywanie jest zawsze trudniejsze, niż się wydaje, i nauczyłem się tego na własnej skórze. Och, cóż, tym razem wiem, co robię, więc zajmie to o połowę mniej czasu (potem skończy się to dłużej niż oryginał, ponieważ nadmiernie inżynier próbuje poprawić lub uprzedzić wcześniej popełnione błędy)
Davy8

Odpowiedzi:


7

Zobacz poniżej niektóre rzeczy, które robię podczas opracowywania dużego projektu:

1 - Używam narzędzia do planowania, takiego jak OpenProj, i dodaję wszystkie funkcje, które chcę uwzględnić jako zadanie. Na przykład teraz pracuję nad funkcją umożliwiającą moim użytkownikom automatyczne logowanie po zarejestrowaniu się w mojej witrynie. W moim planie mam zadanie takie jak „funkcja autologowania”.

2 - Jestem jednoosobowym sklepem programistycznym, więc zazwyczaj przechodzę od jednej funkcji do drugiej. Mój plan jest tworzony w taki sposób, że wszystkie funkcje są sekwencyjne. Nie inwestuję zbyt wiele czasu w oszacowanie, ile czasu potrzebuję na każdą funkcję. Zwykle uważam, że każdy z nich zajmie mi dzień. Jeśli ktoś bierze więcej, po prostu aktualizuję plan i wszystkie przyszłe zadania odpowiednio się zmieniają.

3 - Używam git intensywnie. Każda funkcja jest gałęzią. Po zakończeniu każdej funkcji łączę ją z powrotem w gałąź programistyczną i tworzę nową gałąź dla następnej funkcji.

4 - Jeśli znajdę błąd w oprogramowaniu, tworzę małą gałąź git, aby go naprawić i scalić z powrotem, gdy zostanie rozwiązany. Upewniam się, że aktualizuję zarówno gałąź rozwoju, jak i moją obecną gałąź funkcji, nad którą pracuję. Nawiasem mówiąc, błąd staje się kolejnym zadaniem w moim planie OpenProj. Coś w rodzaju „błędny adres”. A kiedy go wstawię, wszystkie inne funkcje zostaną cofnięte na osi czasu.

5 - Podczas opracowywania, jeśli myślę o nowej funkcji, po prostu uwzględniam ją w planie, w którym moim zdaniem najlepiej będzie pasować i ponownie dostosować oś czasu.

Mam nadzieję, że to pomoże. Wygląda na to, że masz przed sobą ekscytujący projekt. Powodzenia!


10

Jeśli masz zamiar całkowicie przepisać, dlaczego nie pomyśleć o tym, czy w ogóle powinieneś używać php? Zmiana / aktualizacja technologii może być katalizatorem, który chcesz ulepszyć swój projekt / skalowalność / łatwość konserwacji itp.


3
Należy również wziąć pod uwagę, że istniejące frameworki mogą być bardziej odpowiednie niż tworzenie jeszcze innej struktury jednorazowego użytku.
S.Lott,

1
@ S.Lott - co jest złego w tworzeniu frameworka jednorazowego użytku, jeśli jest on dostosowany do zaspokojenia tego jednorazowego użytku lepiej niż jakikolwiek inny?
Anonimowy

1
@Chris Bridgett: Świat może nie potrzebować kolejnej wysoce wyspecjalizowanej platformy. Może to być „uciążliwe”. Zabawa stratą czasu. Często istniejące ramy działają równie dobrze. „Dostosowywanie” w ramach specjalnego przeznaczenia często wynika z niezrozumienia ustalonych, istniejących ram. Często istniejące ramy są bardziej bezpieczne, niezawodne i szybsze. Często istniejące frameworki są już debugowane. Często istniejące ramy są lepiej rozumiane przez innych członków zespołu.
S.Lott,

@ S.Lott: Piszę to dla kilku witryn, których jestem właścicielem, a jego konstrukcja jest skonfigurowana w sposób, który nie jest żadnym innym frameworkiem. Nie planuję też wydać go na jakiś czas, jeśli w ogóle. re: TheLQ: To była jedna z moich pierwszych myśli, jednak żaden inny język WWW nie ma takiego zasięgu, jak PHP .NET. Preferowany byłby Python, jednak konfiguracja na serwerach cPanel (które niestety tworzą wiele światów hostingu), jest uciążliwa.
Jon

1
@ S.Lott Czytam o Symfony, CakePHP i CodeIgniter od czasu opublikowania, a najważniejszą rzeczą, która powstrzymuje mnie od korzystania z nich - jest to, że wszyscy wydają się ślepo trzymać się MVC i ignorować możliwość ponownego użycia. Mój obecny projekt (i przyszłość, jeśli przepiszę) to MVC w jednym folderze (folder „modułu”), z widokami tam, gdzie użytkownik tego chce (o nazwie example.module.view.php), a także motywami folder, w którym projektanci mogą tworzyć własne kompozycje, które zastępują istniejące widoki. Ma to dla mnie kluczowe znaczenie i wydaje się, że żadna z głównych platform nie robi tego bez hakowania - to mi przeszkadza.
Jon

10

Sugerowałbym zamiast tego mocno refaktoryzować

Problem, który przewidujesz tutaj:

Naprawdę chcę dokładnie zaplanować to przepisywanie, chcę szczegółowo opisać każdą funkcję, którą chcę, gdzie będzie i jak będzie się łączyć z każdą inną częścią - ale nie mam doświadczenia z tym poziomem planowania. Jakakolwiek rada? Jakieś programy, które pomogą? Mam już dość Traca, nigdy tak naprawdę go nie lubiłem.

jest naprawdę trudny. Jest to w zasadzie model Waterfall z całą swoją brzydotą. Oto kilka anegdotycznych dowodów na problemy związane z podejściem „wielkiego przepisywania”, który doszedł do wniosku: prawdopodobnie nie przewidzisz problemów poprawnie i skończysz na kolejnym bałaganie, który chcesz przepisać od zera. Nie dlatego, że jesteś zły, ale dlatego, że nie można uzyskać czegoś dużego za jednym razem.

Kiedy zamiast zacząć byłaby, to można napisać pojedyncze bilety i można kontynuować korzystanie z projektu. Sztuczka polega na tym, aby zidentyfikować mniejsze zmiany, które prowadzą do ogólnie lepszego projektu.

Na przykład: wspominasz, nie masz MVC, ale chcesz. Pierwszym krokiem może być pojedynczy plik PHP i, przy założeniu zwykłego miksu, posortuj go, tak aby na górze miałeś dostęp do db, obliczeń itp., Na dole masz „szablon” ( pierwsze bilety, dla każdego pliku). Drugim krokiem jest zamknięcie wszystkich tych szablonów w funkcje, które przejdą przez parametry. (dużo więcej biletów). Gotowy? Gratulacje, ukończyłeś swoje V w MVC.


Uwzględnię to, dzięki. Również po to, żeby wszystko wyjaśnić - używam teraz MVC.
Jon

@Jon: Tak, również mój przykład zakładał typową stronę, bez ram. Myślę jednak, mutatis mutandis, że moja odpowiedź nie jest przez to unieważniona. Punkt, o którym nie wspomniałem: refaktoryzacja jest fajna. To bardzo satysfakcjonujące, gdy totalne bzdury stają się czymś pięknym :)
keppla,

3

Rozważ użycie istniejącego frameworka. CakePHP, Zend Framework, CodeIgniter i Symfony są znane z PHP. Jeśli zaspokoją potrzeby setek lub tysięcy użytkowników, jestem pewien, że mogą zaspokoić twoje.

Jeśli chcesz się uczyć / używać czegoś innego niż PHP - Django (Python) i Rails (Ruby) są właściwie wiodącymi platformami dla konwencjonalnych aplikacji internetowych.

To oczywiście, chyba że chcesz doświadczyć tworzenia frameworków - które, dodam, ma znacznie mniejszą wartość na rynku (zamiast umieć dobrze korzystać z istniejących, wspieranych frameworków).


1

Lubię korzystać z Redmine jako narzędzia do śledzenia harmonogramów. IT bardzo dobrze radzi sobie z każdym z tych elementów, a jednocześnie jest o wiele bardziej przyjazny dla użytkownika (moim zdaniem) niż trac.

Jeśli chodzi o ponowne pisanie, ważne jest, aby najpierw zrozumieć, że nigdy nie będziesz oczekiwać każdej funkcji / nowego rozszerzenia, które mogą się pojawić, więc spróbuj napisać aplikację tak elastycznie, jak to możliwe. Korzystanie z wielu frameworków MVC, które PHP ma, może pomóc to wykorzystać; jednak niektóre z tych frameworków również dziurawią cię, jeśli twoja architektura DB od samego początku nie jest elastyczna (Cake). Naprawdę skupiłbym się na tworzeniu rzeczy tak abstrakcyjnych, jak to tylko możliwe, a kiedy tylko zobaczysz coś na stałe zakodowanego, zadaj sobie pytanie, po co to jest i dlaczego nie może być przechowywane w DB.

Naprawdę projekt DB pomaga odpowiedzieć na tak wiele pytań i problemów, i właśnie tam widzę główne znaczenie interakcji aplikacji; dlatego zaleciłbym spędzić większość czasu na analizie sposobu przechowywania danych i struktury bazy danych.


1

Jako oprogramowanie do śledzenia problemów JIRA jest świetna, ale jest bardzo droga. Innym dobrym narzędziem, którego używam, jest Eventum. Jest wolne.

Ale najważniejszą częścią jest dobre wyobrażenie o tym, czego potrzebujesz. Najpierw musisz zebrać wymagania dotyczące aplikacji, aby mieć ogólne wyobrażenie o tym, czego chcesz i jak najbardziej kompletne.

Na tej podstawie stworzysz wymagania dotyczące oprogramowania, czyli bardziej techniczne podejście, w którym opiszesz moduły, które będą częścią twojej aplikacji, ich funkcje i podfunkcje, obiekty, klasy, ich interfejsy, prawie wszystko.

Wiedząc, dobrze zrozumiesz złożoność aplikacji i wymaganych wierszy kodu, dzięki czemu możesz dokonać oszacowania i stworzyć harmonogram. Ważne jest, aby mieć harmonogram i termin, w przeciwnym razie możesz nie skończyć go.

Mam nadzieję, że to pomoże


Jira jest bardzo tania dla mniej niż 10 użytkowników. Koszt to 10 USD, a 10 USD idzie na cele charytatywne.
sixtyfootersdude
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.