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

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.

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!

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.

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.

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

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.

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