Projekt aplikacji Opcje

[markuz]

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ć (IMG:style_emoticons/default/smile.gif)
Pozdrawiam i proszę o wasze opinie.

[Dejmien_85]

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

Ten post edytował Dejmien_85 17.09.2013, 11:52:09