Jak ulatwiacie sobie pracę ? pytanie do programistów "obiektowych" Opcje

[htmlxp]

Witajcie,

Mam do was dość nietypowe pytanie które nie odnosi się do "nie wiem jak to napisac, pomocy!", lecz chciałbym spytać jak organizujecie sobie pracę.

Ja w programowanie obiektowe powoli wchodzę, lecz po napisaniu okolo 200 funkcji dla jednego projektu, powoli zaczynam się w tym wszystkim gubić. Tym bardziej że nie robie jednego projektu cały czas, zostawiam go i wracam po jakimś czasie.

Jakie macie spososby na większe projekty ? przed rozpoczęciem planujecie wszystkie funkcje, rozpisujecie je a potem przystępujecie do kodowania ? Posiadacie jakiś dobry system rozpisywania komentarzy dla danego pliku ?

Ja do tej pory pracowałem "na żywioł", czyli siadam i koduje, lecz może posiadacie lepsze pomysły.

[Sephirus]

Ogólnie temat rzeka ale podstawą są:

- Komentowanie kodu - używaj na przykład styl PHPDoc'a,
- Autokomentowanie kodu - nazywaj odpowiednio obiekty oraz ich metody tak - by wiadomo było za co są odpowiedzialne i co mają robić ale nie popadaj w skrajność. Staraj się nie używać za dużo skrótów, które mogą kojarzyć się z wieloma rzeczami naraz,
- Użyj odpowiedniego środowiska, które będzie Ci podpowiadać - np.: NetBeans

Zalecam korzystanie z dwóch idei - KISS i DRY

Jeśli nie chcesz projektowa wszystkiego na samym początku - co nie jest łatwe i wymaga nieco doświadczenia i wiedzy z różnych zakresów to zaprojektuj sobie ogólnie szkielet aplikacji, wydziel główne moduły, klasy odpowiadające za dane funkcjonalności itp. Metody w danych klasach dopisuj na bieżąco - nie rób nic na zaś. Dopiero gdy zauważysz podczas pracy, że można coś zoptymalizować zrób to. Tak samo jeśli używasz tego samego kodu w wielu miejscach - wydziel go na zewnątrz.

Polecam przygotowanie sobie samego szkieletu aplikacji, i na podstawie przypadków użycia wyodrębnienie większości funkcjonalności - innymi słowy spisz co ma być możliwe w aplikacji i podziel to na moduły i klasy zapisując także jak na siebie wpływają.

To podejście jest raczej do małych i średnich projektów - normalnie jeśli miałbyś tworzyć coś dużego dla kogoś to polecam jednak poczytać o projektowaniu, wzorcach, logice biznesowej, diagramach itp.

[CuteOne]

1. Najważniejsze - dobre i skonfigurowane IDE np. netbeans/eclipse. Oszczędza masę czasu na pisaniu funkcji, których nazw dokładnie nie pamiętamy, wskazuje błędy składni, kolorowanka skłądni, git/ftp, source refactor(przydatne gdy poprawiasz kod po kimś)
2. Framework - nie piszesz 1k razy nowy router/acl/obsługę sessji/autoryzację itp. itd. Oczywiście na początku trzeba poświęcić swój czas na naukę ale potem to się zwraca z nawiązką
3. Komentowanie wszystkiego co możliwe - pracochłonne i czasobożerne ale po powrocie do kodu patrzysz na komentarze i wiesz do czego pobranie z bazy id_user było wykorzystane
4. Komentarz wstawiam przed klasą, metodą i jakąś ważniejszą funkcjonalnością.
5. Omijam szerokim łukiem komentarze techniczne typu:

[PHP] pobierz, plaintext 
/**
 * View action
 *
 *@param int $c
 *@return mix $cc
 */
[PHP] pobierz, plaintext 

zamiast takiego komentarza wolę coś w ten deseń

[PHP] pobierz, plaintext 
/**
 * viewAction - podczas pobierania danych, ustawiamy autoryzację na false. Następnie
 * w widoku zmieniamy $xx na $yyy aby nie zapętlić sktyptu
 *
 *@param int $c - id użytkownika (przechodzi wstępną walidację)
 *@return mix $cc - zwracamy tablicę, obiekt lub int użytkownika w zależności od zmiennej $xx
 */
[PHP] pobierz, plaintext 

6.Kiedyś korzystałem z autorskiego narzędzia, które tworzyło "spis treści" danej klasy (wszystkie metody, parametry, odwołania do innych zasobów itp.) ale po przejściu na Zenda już go nie potrzebowałem

Ten post edytował CuteOne 30.10.2012, 11:45:59

[skowron-line]

1. Podziel całość na moduły
2. Pisz jeden moduł od początku do końca
3. Komentarze
3.1 Nazwy zmiennych, metod, klas takie które mówią dużo o tym co metoda robi to sprawi że w sytuacji kiedy nie będziesz miał komentarza to będziesz w stanie z nazwy (klasy|metody|zmiennej) wywnioskować co robi.
4. MVC
5. IDE