20 STYCZNIA 2012 / TECHNOLOGIE / 9 KOMENTARZY
W PROGRAMOWANIU TRZEBA UMIEĆ ZACHOWAĆ UMIAR
Kilka dni temu zostałem poproszony przez znajomą firmę o zmianę kilku rzeczy w funkcjonowaniu jej strony. Sprawa dość prosta, normalnie powinna zająć kilka minut i po sprawie.
Po wejściu na serwer i sprawdzeniu jak strona została wykonana złapałem się za głowę. 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 nie korzystanie 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ę być 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
Artykuł opublikowany został w serwisie Dziennik Internautów www.di24.pl.
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 nie korzystanie 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ę być 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
Artykuł opublikowany został w serwisie Dziennik Internautów www.di24.pl.
| atcom | 2012-01-20 15:52 |
Panie Slawku,
A zapomnial pan o pozycjonowaniu.
Ta strona nie ma az tylu odstron chodzi o robota google i pozycjonowanie.
Prosze spytac pierwszej lepszej osoby sie tym zajmujacej (promowanie stron w wynikach wyszukiwania).
Pozdrawiam
A zapomnial pan o pozycjonowaniu.
Ta strona nie ma az tylu odstron chodzi o robota google i pozycjonowanie.
Prosze spytac pierwszej lepszej osoby sie tym zajmujacej (promowanie stron w wynikach wyszukiwania).
Pozdrawiam
| sirC | 2012-01-20 16:42 |
Ta strona o której piszesz nie została zrobiona przez programistę, tylko przez informatomatołka, który sam nie potrafi nic zaprogramować. Robi więc kompilację różnych gotowców, spina wszystko kodem napisanym na wzór w książce i potem takie coś trzeba poprawiać i jest z tym udręka. Współczuję, ale takie sytuacje są nagminne, trzeba się uodpornić i przyzwyczaić.
| FFFUUU | 2012-01-20 17:59 |
bo OOP w założeniach miał służyć do modelowania pewnych rzeczywistych (lub nie) obiektów tymczasem grupka idiotów zrobiła z tego religie i powód do onanizowania się nad swoim niezrozumiałym kodem (podobnie zresztą z programowaniem funkcyjnym). Inni "specjaliści" w odpowiedzi na ten obiektowy burdel proponują powrót do starego (nie zawsze) dobrego C i się robi taka szopka że tam gdzie byłoby dobre podejście obiektowe durnie piszą pseudo-obiektowy kod w C a tam gdzie potrzeba prostego strukturalnego rozwiązania tworzy się obiektowe chuj-wie-co.
| Mateusz | 2012-01-20 18:05 |
A co powiedział Pan klientowi? :)
Pozdrawiam
Pozdrawiam
| azet | 2012-01-20 23:03 |
Nic nie zrozumiałem, ale brzmi bardzo przekonująco.
| Piotr Sarnacki | 2012-01-21 02:57 |
Nie mam zielonego pojęcia dlaczego programowanie obiektowe łączysz z przerośniętymi aplikacjami. To kwestia podejścia. Zawiłą aplikację można stworzyć niezależnie od wybranego stylu, myślisz, że jakby te 5000 plików było napisane w pełni strukturalnie, to byś się połapał? Większość kodu, który widziałem w PHP była pisana strukturalnie, bo to było jakieś kilka lat temu i nie przeszkadzało to wcale w stworzeniu potworków, które trzeba było rozszyfrowywać godzinami zanim można było coś zmienić.
Inna sprawa jest taka, że obiektowość w PHP jest bardzo kiepska, a większość programistów tego po prostu nie umie robić. Nie wiem też w jaki sposób używanie bibliotek do obiektowej obsługi bazy danych przy *prostych* aplikacjach może cokolwiek utrudnić, zakładając oczywiście . Szczerze mówiąc zaczynam się już w tym gubić, bo raz przeciwnicy używania ORMów twierdza, że nie sprawdzają się przy większych aplikacjach, a raz że nie sprawdzają się przy prostych. Nie piszę już od dawna w PHP, ale jeżeli rzeczywiście pisząc z użyciem nowoczesnych technik trzeba robić jakieś wielkie przerośnięte kolosy i jedyną możliwością poprawy jest ucieczka do programowania strukturalnego, to bardzo się cieszę, że wiele lat temu od pehapa uciekłem.
Inna sprawa jest taka, że obiektowość w PHP jest bardzo kiepska, a większość programistów tego po prostu nie umie robić. Nie wiem też w jaki sposób używanie bibliotek do obiektowej obsługi bazy danych przy *prostych* aplikacjach może cokolwiek utrudnić, zakładając oczywiście . Szczerze mówiąc zaczynam się już w tym gubić, bo raz przeciwnicy używania ORMów twierdza, że nie sprawdzają się przy większych aplikacjach, a raz że nie sprawdzają się przy prostych. Nie piszę już od dawna w PHP, ale jeżeli rzeczywiście pisząc z użyciem nowoczesnych technik trzeba robić jakieś wielkie przerośnięte kolosy i jedyną możliwością poprawy jest ucieczka do programowania strukturalnego, to bardzo się cieszę, że wiele lat temu od pehapa uciekłem.
| jacek | 2012-01-21 15:16 |
Wszystkiemu jest winny niski próg wejścia do branży webdeweloperskiej. PHP to prosty język do opanowania, ale co po znajomości języka, skoro brak obycia w rozwiązaniach praktycznych. Założę się, że opisana przez Pana strona jest niezabezpieczona przed atakami sql_injection, a wykorzystany darmowy CMS (założę się że to popularna w naszym kraju Joomla) jest dziurawy jak sito, jeśli strona powstała kilka lat temu i nikt nie zaktualizował bebechów. Patalogią w branży jest to, że za stawianie stron i sklepów na darmowych i dziurawych gotowcach "wykonawca" bierze tyle samo pieniędzy co programista który zrobi to samo, ale porządniej i często szybciej. Normą w branży jest coś co ja nazywam "poprawianie po fachowcach", do mnie ciągle zgłaszają się klienci którym ktoś zrobił stronę, przerwał w połowie lub na ostatniej prostej i przestał odbierać telefony, najczęściej taką stronę trzeba zrobić od nowa, zaczynają od wywalenia phpbb, joomli i masy pluginów.
| Peter_D | 2012-01-22 12:57 |
To jest bardzo dobry przykład czegoś co można nazwać strzelaniem do muchy z armaty. Korzysta się z takich kolosów tylko po to by klient miał serwis składający się z kilku prostych podstronek. Można to nazwać głupotą, niedouczeniem albo megalomanią ;)
| Łukasz | 2012-01-23 20:24 |
Dziwniejszej tezy jeszcze nie widziałem. Nowoczesne i obiektowe programowanie komplikują kod??
Mylisz podstawowe pojęcia, na takim poziomie, że nawet nie wiadomo od czego zacząć.
Zastanów się - gdybyś obsługiwał 200 klientów - to też byś każdą stronę klepał od zera? Nie zrozum mnie źle, ktoś w tym przypadku ostro przesadził ze skomplikowaniem nawet jak na dużą ilość klientów, ale jak można porównywać jedno oderwane zlecenie do takiego systemu?
Pisałem CMSa, na którym obsługiwałem docelowo 40-50 klientów z różnymi potrzebami i teraz pomyśl sobie - klepałbyś to za każdym razem od zera? Jeśli tak to gratuluję.
Wyciągnąłeś gruszkę, piszesz o pietruszce, tyle w temacie.
Mylisz podstawowe pojęcia, na takim poziomie, że nawet nie wiadomo od czego zacząć.
Zastanów się - gdybyś obsługiwał 200 klientów - to też byś każdą stronę klepał od zera? Nie zrozum mnie źle, ktoś w tym przypadku ostro przesadził ze skomplikowaniem nawet jak na dużą ilość klientów, ale jak można porównywać jedno oderwane zlecenie do takiego systemu?
Pisałem CMSa, na którym obsługiwałem docelowo 40-50 klientów z różnymi potrzebami i teraz pomyśl sobie - klepałbyś to za każdym razem od zera? Jeśli tak to gratuluję.
Wyciągnąłeś gruszkę, piszesz o pietruszce, tyle w temacie.
Dodaj komentarz: