Witam!
Mam problem. Otóż moim zadaniem w najbliższym czasie jest stworzenie dosyć zaawansowanego skryptu (kilkadziesiąt tabeli SQL, dużo modeli i widoków). Próbowałem pisać ten skrypt "od ręki" tzn. bez przygotowania żadnych planów jednak po kilku tysiącach linijek kodu ciężko jest dojść co i jak. Tym tym razem postanowiłem zabrać się za to jak trzeba tzn. przygotować jakiś projekt. Ale w jaki sposób? Chciałem Was zapytać jak wy przygotowujecie projekt większych skryptów. Czy rozpisanie wszystkiego na kartce ułatwi sprawę? Może macie jakieś narzędzia które by pomogły w planowaniu takiego skryptu (zarówno tabel SQL jak i funkcjonalności skryptu). Najlepiej gdyby ktoś udostępnił mi taki projekt w celach czysto naukowych abym mógł sprawdzić jak to zrobić
Pozdrawiam i proszę o wasze opinie.

W kwestii projektowania bazy danych - radzę wykorzystać jakieś narzędzie pokroju mysql workbrench

Pozwala ono tworzyć wizualnie tabele - powiązania między nimi - organizować je wizualnie kolorami itp. co ułatwia zarządzanie bazą

Następnie taki schemat możesz wyeksportować do gotowego zapytania SQL, które utworzy bazę

Jeśli korzystasz z jakiejkolwiek innej bazy Oracle SQL czy innej - to znajdziesz podobne narzędzia dla każdego innego typu

Zaś co do samego kodu PHP - wystarczy, że pracujesz w programie typu Netbeans czy Eclipse albo jakimkolwiek innym środowisku, które ułatwia programowanie - wtedy łatwo możesz nawigować po klasach, które tworzysz, dokonywać refaktoryzację itp. - najlepiej w ogóle projekt oprzeć o jakiś gotowy Framework w stylu Zend wtedy też Twój kod będzie od razu miał jakiś lepszy podział, będzie czytelniejszy i łatwiej będzie go zmieniać w przyszłości

Dzięki za mysql workbrench. A co jeśli chodzi o dokumentacje? Opis funkcji, klas itp.

Niestety nie wystarczy

Nie wiem jak pozostali, ale jeśli o mnie chodzi to korzystam z zasady od ogółu do szczegółu. Na początek wypisz sobie co aplikacja ma w zasadzie robić, jakie przewidujesz funkcjonalności itp. Następnie rozpisuj sobie coraz bardziej szczegółowo jak ma ona wyglądać. Im więcej Ci się uda, to na podstawie projektowania będziesz w stanie wychwycić więcej problemów i poprawić projekt.
Do tworzenia schematów lub makiet możesz użyć pencil tool.

Podziel cały projekt na zadania, a zadania na mniejsze zadania,
Jak np masz zrobić system rejestracji/logowania to:
rejestracja/logowanie

rejestracja

utworzenie formularza rejestracji z polami ...
walidacja wprowadzonych danych
wprowadzenie danych do bazy, wysyłka wiadomości E-Mail
aktywacja konta (link w mailu, przypomnienie, wyślij ponownie)
zapomniałem hasła/email

logowanie

utworzenie formularza ...
walidacja i autoryzacja
uprawnienia (ACL)
zarządzanie uprawnieniami

praca z SVN czy GIT umożliwia śledzenie zmian, dobrze opisane commity pozwalają domyślić się po co były zmiany
komentarze są bardzo dobrym źródłem informacji

Mi bardzo pomógł phpdoc w połaczeniu z IDE.

Lepiej napisac sobie to na kartce czy uzyc jakiegos programu do zaprojektowania tego?

Kwestia, jak ci wygodniej . Ja lubię pod taska w redmine mieć podpięte zmiany w kodzie, jak coś się sypie to wiem dlaczego.

Do mysql:
workbench zdecydowanie
PHP:
napisz sobie coś, co ci rozwarstwi aplikację, koniecznie
u mnie zwykle wyglada to tak:
core/
core/controller/
router.php
router aplikacji
core/models/
jakaś ogolna logika
view.php
core/data
coś, czego bede uzywał czesto do pobierania danych, np przywileji użytkownika
core/libraries
prototypy metod dla klas, które prezentuja coś, co chcę zrobic
core/drivers
coś, co coś robi, np operacje na mysql:
connect, prepare, query, fetch, dataOperations, close

dla loginu:
login/
login/controllers/
login.php
login/models
login/models/login.php
login/data
login/data/loginform.php
login/data/userverification.php

ułatwio to zapanowanie nad aplikacją

Koniecznie poczytaj o SOLID, DRY i KISS

Witaj,

Oprócz trafnych porad kolegów powyżej mogę Ci polecić jedną dość pomocną rzecz: UML.

To może Ci pomóc w rozplanowaniu całej aplikacji. Ważne jest, aby nie zaczynać od kodowania. Najpierw sobie usiądź i zapisz na papierze jakie funkcje będzie posiadał ten serwis. Wypisz wszystko co Ci przyjdzie do głowy, od prostych rzeczy typu "logowanie", czy "sytem autoryzacji", po bardziej skomplikowane.

Następnie dla każdej funkcjonalności zaplanuj klasy/metody.

Nad tym możesz spędzić dzień, albo i nawet kilka dni (w zalężności od wielkości projektu), ale korzyści płynące z takiego planowanie przerosną Twoje najśmielsze oczekiwania. Ważne jest, abyś miał plan jak zabrać się do pracy. Ogromnie ważne jest to, abyś wszystko dobrze przemyślał, zanim zabierzesz się do pracy, bo później może się okazać, że pewne rzeczy będziesz musiał przepisać/napisać od nowa/wywalić w cholerę - (tą droge już poznałeś i nie chcesz do tego wracać!).

Zdaję sobie sprawę, że chciałbyś się pewnie od razu rzucić do kodowaia, jednak ta droga jest zgubna- zresztą w tej chwili wiedzisz do czego doprowadziła (napisałeś sporo kodu, który idzie do śmieci). Naprawdę warto jest najpierw zaplanować całą aplikację (choćby ogólnikowo), a później zacząć przechodzić do szczegółów i na końcu do pisania.

Poza tym - do dużych projektów polecam frameworki PHP (Symfony, Laravel, FuelPHP itd). Ułatwią Ci znacznie pracę i sprawią, że Twój kod będzie utrzymany w ładzie i porządku.

Polecam edukację z tematu OOD (Object Oriented Design) - pomoże Ci to znacznie w ogarnięciu kodu. Nie chcesz raczej powracać tutaj po kilku tysiącach linijek kodu i napisać: "Kurcze, napisałem XYZ linijek kodu i... dupa". ; )

Ogólnie życzę powodzenia! Po stworzeniu tego serwisu Twoje doświadczenie wzrośnie drastycznie.

Pamiętam swój piewrszy serwis (pisany samodzielnie). Kodziłem go ok. 2 miesięcy. Kod z pierwszych tygodni był napisany amatorsko, korzystałem z FW PHP i wzorca MVC. Na początku pisałem niezbyt przemyślanie, tworzyłem "grube kontrolery" i przerośnięte funkcje/metody (mimo tego, że wiedziałem naprawdę duzo o OOP/OOD), ale w drugim miesiącu wszytko wyglądało już całkowicie inaczej. Najwięcej zmieniło się wtedy, gdy mojemu klientowi co jakiś czas wpadały do głowy zmiany, których nie uwzględnił w specyfikacji. Wtedy dopiero odczułem na własnej skórze co na myśli mieli Ci, którzy mawiali, że liczy się utrzymywanie aplikacji ("maintenance").

OOD doceniłem wtedy, gdy klient przychodził do mnie z nowymi pomysłami, które wywracały kompletnie wcześniej tworzone algorytmy, lub wymagały przeprowadzenia dość sporych zmian - i tak jest do tej pory. W takich chwilach dowiadujesz się ile tak naprawdę warte jest to co "płodzisz".

Napisałeś, że gubisz się we własnym kodzie - niedobrze, jednak wiedz, że każdy tak zaczynał, także głowa do góry i zabieraj się za to, co może pomóc Ci w rozwijaniu swoich umiejętności. OOD (Object Oriented Design) to droga, którą powinieneś zacząć podążać - i ta dorga doprowadzi Cię do reszty przydatnych narzędzi/idei.

Na koniec kilka krótkich porad:
- każda klasa w osobnym pliku + określona funkcjonalność (bedziesz miał ład),
- każda metoda danej klasy powinna robić jedną okreśłoną rzecz (unikniesz tworzenia "grubych" metod ciężkich do powtórnego wykrozystania czy modyfikacji - a uwierz mi, że modyfikacje będą i przygotuj na to tą aplikację),
- metody powinny być krótkie (głównie chodzi o to, aby uniknąć tworzenia "grubych" metod, które wykonują X różnych rzeczy na raz i które... są trudne do powtórnego wykorzystania/modyfikacji),

z kontrolkami bardzo łatwo wykonasz taką akcje. zresztą jest wiele programów które to ułatwia.