Strona głównaFacebookTwitterInstagramRSS
Dzisiaj jest niedziela, 30 kwietnia 2017
Historia mojego... sukcesu?Rozdzielczość druku wielkoformatowegoSklep z koszulkami
Mój własny framework #01

Mój własny framework #01

wtorek, 2010-08-030

Kilkakrotnie już pisałem, że lubię wyważać otwarte drzwi. Ci, którzy mnie znają, znają też mój pogląd na korzystanie z gotowych rozwiązań, które może są uniwersalne i łatwe do wdrożenia, ale często przysparzają więcej problemów, zawłaszcza na dłuższą metę. Zresztą jest coś w powiedzeniu: "jak coś jest do wszystkiego to jest do niczego". Chciałbym tu zaproponować ambitnym czytelnikom rozważenie napisania własnego Frameworka lub chociaż CMSa, na którym można budować serwisy internetowe. Oczywiście nie podam tu żadnego gotowego rozwiązania, być może nie będzie ani kawałka kodu. Chciałbym raczej przedstawić moją przygodę z pisaniem takiego systemu. Może komuś się to przyda. A przynajmniej podbuduje swoje ego śmiejąc się z gościa, który chyba cierpi na nadmiar wolnego czasu :)

Tytułem wstępu

Na wstępnie chciałbym zaznaczyć, że nie mam żadnego wykształcenia związanego z programowaniem w jakimkolwiek języku (nie licząc kilku zajęć na Politechnice), w związku z czym mogę czasami pisać bzdury z punktu widzenia zawodowców. Jestem samoukiem praktykiem, wiedzę czerpię z książek i internetu. I chociaż nie rozumiem większości tematów prowadzonych na grupach dyskusyjnych a dziedziczenie, wirtualizacja i inne takie są dla mnie abstrakcją. Nie przeszkadzało mi to jednak w zaprojektowaniu własnego CMSa i kilku nieźle działających bibliotek, które można nazwać czymś w rodzaju frameworka. Co prawda sam system nadaje się raczej do małych i średnich serwisów niż poważnych aplikacji, ale nie oszukujmy się - na takie strony jest o wiele większy popyt.

Może nie jest to majstersztyk sztuki programowania, ale system wdrażam z powodzeniem, strony działają bez błędu a, co najważniejsze, szybko, np. w porównaniu z serwisami stawianymi np. na WordPressie czy Joomli. Nie stosuję żadnych zaawansowanych technik cache'owania kodu czy odczytanych danych z bazy, co może jest istotne przy dużych portalach, ale nie średnich serwisach.

Być może moja nieznajomość zagadnień teoretycznym dała mi tą korzyść, że nie miałem żadnych naleciałości programistycznych i pozwoliła mi spojrzeć na temat z zupełnie innej strony. Nie będę ukrywał, że mój kod najpiękniejszy nie jest, w ciągu roku pracy nad nim, zmieniłem wiele rzeczy i wciąż zmieniam w miarę jak go rozbudowuję. Cały czas staram się pilnować, żeby był krótki i po każdej łacie czyszczę go ze zbędnych śmieci. Zajmuje to trochę czasu, ale ważne jest dla mnie trzymanie kodu w ryzach.

W tej chwili pisze moduł do obsługi forum i czuję, że nie będzie to proste zadanie.

Wyważanie otwartych drzwi

Pisałem o tym już nie raz i powtórzę kolejny. Dla większości może się to wydawać bzdurą i stratą czasu, bo po co pisać od nowa coś, co już istnieje i działa? Problem w tym, że funkcje czy klasy udostępnione publicznie są pisane tak, aby były jak najbardziej uniwersalne. Ma to ten plus, że czytamy dokumentację i po prostu korzystamy z funkcji nie wnikając, co w niej siedzi. W praktyce jest to często nawet 90% zbędnego kodu. Niedawno zostałem poproszony do sprawdzenia błędu na jednej stronie, postawionej zresztą na Zendzie. Znalazłem odpowiednią klasę (ponad 25kB), wywaliłem całą masę komentarzy i sampli, potem usunąłem kod wstecznej kompatybilności i zostało mi około 1kB kodu właściwego, gdzie dopiero znalazłem literówkę. W ogóle byłem zaskoczony, po co pisać klasę dla tego zadania, skoro można go było sprowadzić do kilkunastu komend PHP (mam w swoim systeme analogiczną funkcję, ale jest ona tylko dodatkiem do zupełnie innej klasy).

Inna sprawa, że pisanie czegoś od nowa pozwala wiele się nauczyć. Mógłbym korzystać z gotowych klas np. do obsługi bazy danych i wciąż nie wiedziałbym jak to działa na najniższym poziomie. A czasami taka wiedza się przydaje.

Podstawowe założenie

Minimalizm. Wychowałem się na komputerach 8-bitowych (głównie Atari 65XE), gdzie każdy bajt i cykl procesora był na wagę złota. Stąd mam zamiłowanie do optymalizacji, optymalizacji i jeszcze raz optymalizacji. Nie było to łatwe. Pierwsza wersja systemu powstała bez wcześniejszego planowania i była w zasadzie zlepkiem funkcji. Potem nastąpiło gruntowne przeprojektowanie całości. W wyniku czego zmniejszyłem ilość tablic w bazie z 12 do 6 (przy jednoczesnej rozbudowie ich funkcjonalności). Ostatecznie powstała klasa, która te tablice obsługuje.

Częstym zarzutem do frameworków, o jakich czytam na grupach dyskusyjnych, jest niemożność zrobienia czegoś niestandardowo lub obejścia założeń systemu. Ja wychodzę z innego założenia, mianowicie programista wie co robi (a jeśli nie wie, to nie powinien się za coś brać) i udostępniam wszystkie narzędzia. Do bazy można się więc dobrać metodami związanymi z konkretnym typem danych, metodami ogólnymi lub bezpośrednio za pomocą klasy obsługującej bazę MySQL. Czy to dobrze podejście? Nie wiem. Ale dopóki sam korzystam z systemu, ma to więcej zalet niż wad.

Jak już wspomniałem - minimalizm. Minimalna ilość folderów, minimalna ilość plików. W panelu admina ten sam plik obsługuje m.in. listę wpisów, edycję danego wpisu a także akcje związane z nim. Z jednej strony można mieć zarzut, że niepotrzebnie wszystko siedzi w jednym miejscu. Z drugiej strony jest to logiczne. W końcu to wszystko służy do jednego zadania. Po co więc tworzyć dodatkowe pliki i potem się w nich gubić, skoro i tak nie będą użyte nigdzie indziej? Udało mi się sprowadzić cały system do około 60 plików (nie licząc edytora TinyMce, który zostawiłem - jest to jedyny komponent, którego nie napisałem po swojemu).

Nie zawsze ta droga jest słuszna, zwłaszcza jeśli chodzi o wydajność. Czasami trzeba napisać nieco więcej kodu, który docelowo przyspieszy działanie serwisu, zwłaszcza mocno obciążonego. Ale to się sprawdza przy większych aplikacjach i nie powinno być podstawą systemu. Lepiej niech to będą opcjonalne moduły, które będzie można dołączyć do już istniejących. Jako przykład podam funkcje wysyłającą e-maila. Zazwyczaj wystarcza mi zwykła funkcja mail dostępna z poziomu PHP. Kilka razy jednak natknąłem się na serwer, który ze względów bezpieczeństwa miał ją zablokowaną. Wtedy musiałem skorzystać z klasy PHPMailer, którą bez problemu podpiąłem do istniejącej mojej klasy. Nie opieram jednak na tym systemu, inaczej rozrósłby się do gigantycznych rozmiarów. Jeśli ktoś chce stawiać prosty serwis na wielkiej kobyle, niech skorzysta z WordPressa.

Baza danych

Największym wyzwaniem było zaprojektowanie tablicy zawierającej wszystkie treści. W pierwszej wersji bloga miałem osobną tablicę na kategorie, osobną na wpisy, osobną na kategorie linków, osobną na linki, pliki itp... Bardzo szybko mi się to rozrosło. A gdybym chciał dodać galerię czy jakieś inne dane?

Podpatrzyłem więc strukturę bazy WordPressa i wzorując się nieco, utworzyłem jedną uniwersalną tablicę. Oczywiście jej uniwersalność jest umowna, nie zrobię na niej sklepu czy forum. Ale do większości typowych zastosowań jest idealna. Sprowadza się do tego, że jedna z kolumn zawiera ID rodzica, dzięki czemu mogę tworzyć strukturę drzewa, zaś inna zawiera typ danych np. newsy czy pliki. Już słyszę głosy, że przy dużych serwisach to się nie sprawdzi. Odpowiem tak: nie nie wiem, nie próbowałem, będę się martwił przy dużym serwisie. Inna sprawa, że do dużych serwisów i tak podchodzi się indywidualnie, więc uważam, że nie ma sensu sztucznie tworzyć sobie problemów.

Na zakończenie

Rozpisałem się i być może zanudziłem czytelników. Postaram się, żeby następne części były krótsze i skupiały się na konkretnych problemach :)

Czytaj dalej

Jeśli podoba Ci się wpis,
koniecznie zalajkuj,
skomentuj i zapisz się na