PHP – pisanie większych projektów – porady

PHP - Tips & Tricks Zostaw komentarz

Ten wpis powstał na bazie moich doświadczeń podczas pisania większych skryptów w PHP. Postaram się tutaj udzielić kilka słów odnośnie tego, jak należy pisać skrypty w PHP, aby później było jak najmniej pracy przy ewentualnej rozbudowie. Jako przykłady ilustrujące omawiane zagadnienia dość często będę się odwoływał do PP Mapa Zdrowia, który wdrożyłem.

Otóż pierwszym krokiem jest zaplanowanie co ma robić dany skrypt, jakie ma mieć funkcjonalności itp.
Przykładowo: wdrażając PP Mapa Zdrowia zaplanowałem takie funkcje:

  • Zapisywanie w cookies ID partnera, z którego polecenia przyszedł potencjalny klient
  • Obsługa procesu zamówienia (formularz zamówienia)
  • Funkcje do naliczania prowizji w momencie, gdy zamówienie zostaje opłacone, w tym wysyłanie maila do partnera z informacją o naliczeniu prowizji
  • Panel partnera do przeglądania statystyk
  • Panel admina (przeglądanie statystyk partnerów, zamówień, dodawanie wypłat itp.)

To jest oczywiście taka uproszczona lista rzeczy do zrobienia. Bo np. sam punkt panel partnera można rozbić na kilkanaście podpunktów. Ale z grubsza chodzi o zaplanowanie pewnych rzeczy, aby było wiadomo, co trzeba zrobić.

Oprócz planu (co ma zawierać dana aplikacja) trzeba też przemyśleć strukturę bazy danych.

Jak już masz jakiś plan, to można przystąpić do kodowania. Ważne, aby plan był w miarę szczegółowy, bo łatwiej jest od razu zrobić kilka dodatkowych funkcjonalności, niż np. po pół roku w gotowym kodzie na żywym organiźmie coś grzebać (o ile zmiany kosmetyczne są proste do zrobienia, to np. jakaś większa zmiana struktury bazy danych, albo zmiana procedury składania zamówienia może wymagać sporo wysiłku). Warto jest również tak kodować, aby później jakieś modyfikacje były łatwiejsze. Czyli staraj się nie zakładać z góry pewnych ograniczeń. Może tak jest teraz łatwiej, ale później rozbudowa może być niemożliwa, gdy założysz zbyt wiele ograniczeń.

Kolejna ważna rzecz, to parametryzacja. Podam to znów na przykładzie PP Mapa Zdrowia. Otóż nie warto jest na sztywno zakładać, że np. PP ma 2 poziomy poleconych, prowizja za drugi poziom wynosi 10% prowizji pierwszego poziomu i na sztywno wszędzie wpisywać odpowiednie cyferki (np. $poziom2=$poziom1*0.1) Dlaczego? Po pierwsze: jak właściciel PP będzie chciał zwiększyć prowizję za 2 poziom to będziesz musiał sam ręcznie edytować pliki (a co gorsza, jeśli tego typu kawałki kodu są zapisane w 3 różnych miejscach bo np. prowizja może być naliczona w 3 przypadkach, a Ty wyedytujesz owe równanie tylko w 2 miejsacach to zrobi się potem niezłe zamieszanie). Po drugie: załóżmy, że ktoś inny chce, aby mu wdrożyć moduł PP, ale on chce mieć np. 3 poziomy poleconych. I co? Wtedy trzeba od nowa gotowy fajny kod przerabiać. A pisząc dany kod nieco uniwersalniej będzie mniej przeróbek do zrobienia (i potem konserwując kod edytujesz jedną klasę dla dwóch klientów a nie równolegle dwie bliźniacze klasy).

Odnośnie parametryzacji to tutaj jest jeszcze jedna drobna uwaga: warto jest parametryzować np. maile. Otóż w PP Mapa Zdrowia na początku wszystkie maile były zapisane w plikach PHP w stylu:
$temat="Naliczenie nowej prowizji";
$tresc="Cześć $imie
Właśnie została Tobie naliczona prowizja w wysokości $ile
Za sprzedaż produktu $produkt
Gratuluje$stopka";
mail($do, $temat, $tresc, $from);

Tego typu rozwiązanie jest bardzo wygodne bo szybko się pisze kod. No ale ma to też swoje wady. Otóż załóżmy, że zrobisz w treści maila literówkę. I co? I właściciel PP zawraca Tobie głowę, abyś wyedytował treść maila a Ty zastanawiasz się, w którym pliku jest zaszyta treść tego e-maila.

Mało tego – takich mailii jest więcej np. mail o naliczeniu prowizji, o odrzuceniu prowizji, mail z potwierdzeniem rejestracji w PP, mail o najliczeniu premii za aktywność, mail do klienta z podziękowaniem za złożenie zamówienia itp. Ogólnie w PP Mapa Zdrowia jest kilkanaście e-mailii. I teraz sobie pomyśl: w każdym mailu może być np. w stopce zapisany adres pocztowy siedziby firmy. I firma zmienia adres siedziby. Ty jak głupi musisz edytować kilkanaście plików PHP szukając w każdym z nich e-maila i go korygując. Mało tego – pewnie i tak zapomnisz o wyedytowaniu jakiegoś jednego pliku.

Jak ja to robię? Otóż są 2 sposoby: można np. wszystkie maile przechowywać w plikach tekstowych w jednym katalogu na serwerze (masz wtedy porządek, bo wszystkie maile są w jednym miejscu) albo w bazie danych (tutaj trzeba zrobić prosty panel do edycji mailii, ale to nie jest trudne). Następnie kod za wysłanie e-maila jest nieco zmieniony:
$tresc=PobierzZBazy($idmaila);
$find=array('{imie}', '{login}');
$replace=array($imie, $login);
$tresc=str_replace($find, $replace, $tresc);
mail($do, $temat, $tresc, $from);

Skąd to str_replace?? Otóż w mailach są pewne dane, które trzeba spersonalizować np. imię partnera, jego login, kwota naliczonej prowizji. Dlatego w szablonach mailii należy stosować specjalne znaczniki np. {imie}, które potem funkcja str_replace podmieni na zawartość danej zmiennej.

Pisanie kodu, który można w wielu miejscach sparametryzować jest bardziej pracochłonne (podczas pisania kodu), ale to rozwiązanie ma wiele zalet:

  • Właściciel PP sam może zmienić wiele rzeczy bez zawracania Tobie głowy (np. poprawić literówkę w mailu wysyłanym do partnera z informacją o naliczeniu prowizji)
  • Nie pisząc kodu z licznymi ograniczeniami późniejsza rozbudowa może być łatwiejsza
  • Możesz ten sam kod (albo jakiś fragment) drugi raz komuś sprzedać bez potrzeby dokonywania licznych przeróbek (bo przecież wszystkie treści mailii, nazwa firmy itp. są zapisane w bazie danych a nie bezpośrednio w kodzie)
  • Większość rzeczy jest w jednym miejscu (np. w bazie danych) i np. edycja wszystkich mailii jest łatwiejsza niż edytowanie wielu porozrzucanych plików po różnych katalogach

Jeszcze jedna rzecz: warto jest zapisywać różnego rodzaju logi. Otóż załóżmy, że zdarza się taka sytuacja: jakiś partner ma dziwne saldo konta a zamówień z jego polecenia jest w bazie mniej niż by to wynikało ze stanu konta. Można skorygować partnerowi konto i zapomnieć o problemie. Ale nadal pozostanie pytanie dlaczego tak się stało? Załóżmy, że w danym kodzie jest najpierw wywoływana funkcja naliczająca prowizję, a później wywoływana jest funkcja zapisująca w bazie danych informację o nowym zamówieniu. Jeśli przeglądniesz logi to zobaczysz, że została zapisana informacja o naliczeniu prowizji za zamówienie o ID: X, ale nigdzie w logach nie ma informacji o dodaniu informacji o nowym zamówieniu o ID X. I tutaj jest dla Ciebie wskazówka, że przyczyną owej nieprawidłowości pewnie było „wysypanie się skryptu” pomiędzy naliczeniem prowizji a dodaniem do bazy nowego zamówienia. Więc znasz przyczynę dzinwego zachowania i z grubsza wiesz, w którym miejscu trzeba szukać błędu.

Oto przykładowa struktura tabeli w bazie danych zapisującej logi:
– ID akcji (autoincrement)
– ID czynności (np. 1-nowe zamówienie, 2-zmiana statu zamówienia na zatwierdzone, 3-naliczenie nowej prowizji za 1 poziom, 4-odrzucenie prowizji za 1 poziom itp.)
– ID zamówienia którego tyczy się akcja
– ID partnera, którego tyczy się akcja
– wartość (np. w akcji naliczenie prowizji jest wartość prowizji, w akcji nowe zamówienie jest to wartość zamówienia)
– data wystąpienia danej akcji

W ten sposób można bardzo łatwo i wygodnie filtrować wszystkie zdarzenia dotyczące zamówienia o konkretnym numerze ID, lub zdarzenia dotyczące partnera o konkretnym ID

Podsumowując: pisząc większą aplikację w PHP pamiętaj o:

  • planie
  • parametryzacji
  • zapisywaniu logów

Tagi: , , , ,

Zanim dodasz komentarz, zapoznaj się z kilkoma podstawowymi zasadami:

  1. Jeśli zamiast imienia (lub pseudonimu) wpiszesz jakiś mało logiczny ciąg znaków np. asdfg, to taki komentarz zostanie usunięty.
  2. Jeśli się za kogoś podszywasz, to taki komentarz zostanie usunęty
  3. Jeśli zamiast imienia (pseudonimu) wpiszesz jakieś słowo kluczowe (np. tani hosting), to taki komentarz zostanie usunięty
  4. Jeśli Twoim jedynym celem jest zareklamowanie się, to taki komentarz zostanie niezwłocznie usunięty
  5. Komentarze nie związane z tematem notki są kasowane.
  6. Komentarze, które zawierają wulgarne słowa, bądź są obraźliwe (nie dotyczy konstruktywnej krytyki) są kasowane.
  7. Komentarze z mailem typu "nie.podam@coś.tam.pl" są kasowane
  8. Komentarze pisane niechlujnie (bez interpunkcji, w błędami ortograficznymi, z licznymi literówkami, pisane WIELKIMI LITERAMI) są kasowane

Zostaw komentarz

WordPress - Hosting: Twój hosting - Skórka: N.Design Studio - Spolszczenie: Adam Klimowski.
RSS wpisów RSS komentarzy Zaloguj się