Przy tworzeniu strony zostało wykorzystane wszystko, co się da, w tym jQuery, Smarty, PEAR, PDO, edytor WYSIWYG, darmowy CMS, a wszystko to spięte kodem PHP napisanym w języku obiektowym, ze wspomaganiem modrewrite. Nie byłoby w tym nic dziwnego, gdyby nie to, że kod strony składa się z 5116 plików i 538 katalogów i służy do obsługi witryny, która składa się z czterech prostych podstron.

Witryna według założeń składa się z podstron: strona główna, o firmie, oferta i kontakt. Wszystkie strony, z wyjątkiem oferty, mają stałą zawartość tekstową. Oferta składa się z trzech działów, z czego każdy zawiera kilkanaście produków. Do obsługi ich listy potrzebny jest panel administracyjny z możliwością dodawania, edytowania i usuwania wpisów, przy czym przez wpis rozumiemy jedno zdjęcie, jedną nazwę i jeden akapit tekstu bez formatowania.

Taka strona jest bardzo prosta do zrobienia. Gdybym ja ją przygotowywał, składałaby się z kilku plików na krzyż. Podstrony o stałej treści, które według założeń mają nie ulegać zmianie, byłyby obsługiwane przez skrypty: index.php (strona główna), o-firmie.php i kontakt.php. Skrypt oferta.php zawierałby w pierwszym kroku wybór jednego z trzech działów, a w kolejnym wyświetlenie produktów z działu przy pomocy funkcji mysql_query i mysql_fetch_array. Do tego dorzuciłbym plik connect.php, służący do łączenia się z bazą danych. Layout strony wrzuciłbym do skryptów index_naglowek.php i index_stopka.php, w których znalazłaby się odpowiednio górna i dolna część kodu HTML strony. Do administracyjnej obsługi oferty zrobiłbym skrypt admin.php, w którym po zalogowaniu się byłaby możliwość zmiany listy produktów z uploadem zdjęć na serwer. Cała strona składałaby się w sumie z ośmiu prostych skryptów PHP i jednej tabeli w bazie danych. Całość byłaby łatwa i szybka w wykonaniu.

A tak wygląda struktura plików tej strony w jej obecnej postaci:

Dlaczego programista który to stworzył wybrał taką, a nie inną drogę? Otóż istnieje pewna filozofia wśród webdeveloperów, aby strony internetowe robić nowocześnie od strony programistycznej. Mówi się, że programowanie obiektowe jest lepsze, wydajniejsze, szybsze i bardziej przejrzyste od klasycznego tworzenia kodu, często pogardliwie określanego jako "spaghetti code", czyli kodu pisanego od "a" do "z" w jednym miejscu, bez podziału na logiczne moduły, klasy, obiekty (choć jest tu duża niesprawiedliwość, ponieważ można stworzyć przejrzysty kod podzielony na logiczne bloki bez korzystania z zalet obiektowości). Mówi się też, że strony powinny być oparte na systemie szablonów, aby odizolować warstwę kodu od warstwy graficznej. Podobno oznaką nowoczesności i objawem profesjonalizmu jest niekorzystanie z wbudowanych w języku PHP instrukcji, na przykład do łączenia się z bazami danych, tylko korzystanie z zewnętrznych bibliotek. Zalety płynące z tego nowoczesnego podejścia do programowania określane są przez szereg zwrotów kończących się na "-ność". Otóż w ten sposób stworzone serwisy mają większą i lepszą: skalowalność, funkcjonalność, przenaszalność, odwzorowalność, konfigurowalność, wdrażalność, czytelność, imperatywność i profesjonalność.

Do powyższych zalet dodałbym jeszcze: kuriozalność.

Programowanie obiektowe, korzystanie z zewnętrznych bibliotek, żmudne tworzenie klas, aby kod wyglądał bardziej "naturalnie" jest dobre, ale w pewnym zakresie zastosowań, takich jak naprawdę duże projekty z perspektywą systematycznego rozwoju, przy których pracuje wiele osób za duże pieniądze. W wielu przypadkach korzystanie z języka obiektowego czy systemu szablonów powoduje jedynie wydłużenie czasu pracy i komplikowanie tego, co miało pozostać proste. W przypadku omawianej strony poddałem się po dwóch godzinach zagłębiania w kod i uczenia się z klas "naturalnego" odwzorowania problemu, przed jakim stał programista, który mimo korzystania z wielu gotowych rozwiązań skomplikował zadanie w stopniu maksymalnym. To tak, jakby ktoś w swoim terminarzu rozpisał plan dnia co do sekundy, gdzie najprostsza czynność typu poranne założenie skarpetek byłaby poprzedzona analizą obiektową, której rezultatem byłoby stworzenie obiektów "człowiek" i "skarpetka", a czynności podzielone byłyby na klasy "znajdź, "weź" i "założ". Następnie algorytm zawarty w kalendarzu przy pomocy różnych metod łączyłby obiekty z klasami, w wyniku czego powstałaby "model zgodny z rzeczywistością" (duża odwzorowalność!), będący w istocie instrukcją niemożliwą do wykonania i - przede wszystkim - niezrozumiałą.

Piszę o tym, ponieważ często natykam się w sieci na dyskusje na temat słuszności tego czy innego podejścia do programowania, w których Programiści (tacy przez duże pe) śmieją się z prostej i klasycznej formy tworzenia skryptów. W pracy często spotykam się ze stronami, które trzeba poprawić, a które z niewyjaśnionych przyczyn zostały niedokończone przez pierotnego autora albo działają wadliwie. W większości są to strony tworzone "nowocześnie", z użyciem języka obiektowego i zewnętrznych bibliotek. Z takimi stronami jest najwięcej problemów, bo z pozoru prosta zmiana w praktyce okazuje się czasochłonna. Nie wiadomo wtedy, czy robić poprawki w wielu miejscach na sztywno, omijając rozrosłą strukturę, czy zagłębiać się w zawiłości kodu, dopisując jego kolejny kawałek. Nowoczesne podejście do programowania i zarządzania projektami informatycznymi jest ważne, ale nie w każdym przypadku i nie za wszelką cenę.

Sławomir Wilk

Czytaj także: PhpDoc – ułatwiajmy sobie i innym życie