//DEVGURU

Pisząc małe aplikacje nie musimy się przejmować zbytnio jakością kodu, ale już nawet średnie projekty wymagają tego, by je w jakiś sposób zaplanować, żeby je w ogóle skończyć. Po napisaniu kilku rzeczy w Cake’u mam parę spostrzeżeń na to, jak pisać, by było dobrze (a przynajmniej by nie było źle). Część z poniższych punktów odnosi się do programowania w ogóle, część jest stricte Cake’owa.

1. Dobre zaplanowanie struktury aplikacji.

Rzecz najważniejsza. Przeanalizować założenia, zidentyfikować wszystkie obiekty, które będą występować w systemie. Dobrze rozbić aplikację na wiele rozłącznych modułów, które będą mogły być oddzielnie implementowane i testowane, a dopiero później ze sobą łączone. Korzyści są oczywiste – mniejsze powiązanie różnych części aplikacji ze sobą (łatwiejsza implementacja, testowanie), łatwość podziału prac pomiędzy wielu programistów.

2. Podejście abstrakcyjne do implementacji funkcjonalności

Poszczególne moduły aplikacji mogą zostać tak wykonane, żeby mogły być użyte w wielu kontekstach bez dokonywania w nich żadnych, bądź tylko kosmetyczno/konfiguracyjnych zmian. Dla przykładu funkcjonalność oceniania obiektów przez użytkownika można wykonać następująco:

tabela w bazie danych ratings:

• id – primary key
• user_id – id oceniającego użytkownika
• model – nazwa modelu obiektu ocenianego
• foreign_key – id obiektu ocenianego
• rating – ocena

Taka struktura pozwala na ocenę każdego obiektu w serwisie. Do tego można dopisać sobie odpowiedni Behavior udostępniający w wybranych modelach metodę realizującą zapis oceny do bazy i mamy prosty ogólny system oceniania, do którego aktywacji wystarczy dodanie behaviora do $actsAs modelu.

3. Uniezależnienie kontrolerów od interfejsu użytkownika

Akcje w kontrolerach powinny być tak zaimplementowane, by nie było różnicy czy są wywoływane poprzez AJAX czy normalnie. To widoki (a właściwie w tym przypadku layouty) decydują jak zostaną zwrócone dane wynikowe przez akcję.

4. Przeniesienie większości logiki do modeli

To w modelach, nie w kontrolerach powinna być zaimplementowa większość logiki biznesowej systemu – zgodnie z koncepcją “Fat model, skinny controller”. Często wiele kontrolerów korzysta z tych samych modeli wykonując na nich te same funkcje. Przeniesienie tych funkcji do modelu pozwala łatwiej później wprowadzać zmiany i poprawiać ewentualne błędy, ponieważ musimy tego dokonywać tylko w jednym miejscu – w modelu. Podobnie implementacja takich mechanizmów jak caching czy logowanie zdarzeń jest dużo łatwiejsza do wykonania i utrzymania.

5. Elementy

Podobnie jest z elementami. W wielu widokach występują te same elementy, więc powinny być tworzone właśnie w takiej formie. Dla przykładu: formularze dodawania i edycji obiektu z reguły różnią się od siebie co najwyżej wartością atrybutu action, zatem idealnie nadają się, by zrobić z nich element.

To pierwsze modele i kontrolery aplikacji determinują jej strukturę i to, w jaki sposób jest dalej rozwijana. W połowie prac, bardzo trudno zmienić założenia co do struktury kodu, zatem analiza i planowanie powinny odbyć się jeszcze przed rozpoczęciem kodowania. I myślę, że nie należy na nie przesadnie szczędzić czasu, gdyż zwróci się on później na pewno.