Dzisiaj jest środa, 28 czerwca 2017
Historia mojego... sukcesu?Adobe StockJAK wkurzyć grafika (i nie tylko)
Mój własny framework #02

Mój własny framework #02

piątek, 2010-08-200

Czytałem kiedyś, że głównym celem zaprojektowania języka C było programowanie przy jak najmniejszej ilości stuknięć w klawiaturę. Każdy chyba przyzna, że autorom się udało. To co np. w Pascalu zajmuje kilka (-naście?) linijek kodu, w C/C++ można zapisać w jednej. Przy czym jest to najszybszy (zaraz po assemblerze) język programowania a na pewno najszybszy z języków wysokiego poziomu.

Może właśnie z tego powodu składnia C stała się wzorem dla innych języków, w tym także sieciowych takich jak JavaScript czy PHP. W zasadzie przerzucenie się z C na PHP to tylko kwestia poznania nowych funkcji systemowych (ale od czego manual php.net). Przy czym PHP ma dużo więcej ułatwień (np. brak definicji typów zmiennych czy konieczności alokowania pamięci). Jest też niestety bardzo wolny, chociażby ze względu iż jest językiem interpretowanym a nie kompilowanym. Wiem, wiem, serwer potrafi sobie go skompilować i trzymać skompilowaną wersję gdzieś w pamięci podręcznej, ale i tak to nie jest to samo co program skompilowany pod konkretny procesor. Ale nie o tym tu chciałem.

Jak już wspomniałem, PHP daje dużą swobodę programiście (większą nawet niż C). Początkujący bardzo go lubią, bo jest łatwy do nauczenia ale jednocześnie pozwala na "niechlujne" programowanie, przez co bardzo łatwo o błąd, zwłaszcza gdy w grę wchodzą operatory przypisania i porównania. Także nieznajomość kolejności operatorów czy punktów sekwencji potrafi spowodować dziwne zachowanie programu. Dlatego ważne są dwie znane (ale jak zauważyłem, rzadko stosowane) reguły: KISS (Keep It Simple Stupid) i DRY (Don't Repeat Yourself).

Buziaczek

Zaglądałem w kody źródłowy różnych programów, funkcji i klas (albo żeby znaleźć rozwiązanie na swój problem albo w celu rozbudowy aplikacji napisanej przez kogoś innego) i często ręce mi opadały. Cała masa komentarzy, stałych i zmiennych, prostych wyrażeń rozbitych na kilka mniejszych. Kilka razy dokumentacja przekraczała objętość kodu właściwego a na każdą linijkę kodu przypadało kilka linijek komentarza.

Jedną z podstawowych zasad programowania jest pisanie kodu samokomentującego się, a komentarze nie powinny zajmować więcej niż 10-20% całego kodu. Osobiście uważam, że dokumentacja powinna być w oddzielnym pliku, jeśli w ogóle zachodzi taka konieczność.

Może pod tym względem jestem dziwny, ale kod przekomentowany jest dla mnie zbyt nieczytelny. Osobiście lubię mieć na ekranie jak najwięcej kodu, żeby mieć w niego wgląd bez konieczności przewijania (podobnie wydruk - wolę mieć na jednej kartce niż dziesięciu).

Druga sprawa to rozwiązłość funkcji. Skoro język daje taką możliwość (a PHP daje), to uważam, że powinno się pisać jak najzwięźlej. Niedawno na jednej z grup dyskusyjnych spotkałem się z następującym wyrażeniem:

if ($warunek == 1)
{
$wynik = "wartość 1";
}
if ($warunek !=1)
{
$wynik = "wartość 2";
}

A dlaczego tego nie zapisać tak:

$wynik=($warunek==1)? "wartość 1" : "wartość 2";

Zyskujemy kilka linijek i zyskujemy na czytelności (wzrok od razu widzi całość wyrażenia). Skoro jesteśmy przy kodzie, to pokażę przykład błędu. Jeśli w warunku napiszemy "=" zamiast "==" to wynikiem będzie ZAWSZE "wartość 1". Oczywiście dotyczy to obu wersji kodu, przy czym w pierwszej można zrobić jeszcze kilka innych błędów.

Słyszałem kiedyś stwierdzenie, że programista będzie w stanie zająć całą dostępną pamięć. Niestety często jest to prawda. O ile z aplikacją desktopową problem będzie miał tylko użytkownik danego programu o tyle zasobami serwera musimy dzielić się z wieloma innymi użytkownikami. Dlatego najważniejszą zasadą jest: jeśli coś się da zrobić prosto, to tak właśnie róbmy. Nie komplikujmy na siłę programu (oczywiście nie kosztem czytelności, bo można przecież używać zmiennych jednoliterowych, stałe wpisywać bezpośrednio do wywołań funkcji, itp.). W dużym programie łatwiej o pomyłkę (nawet literówkę). Nie mówiąc już o rozbudowie. Więc im mniej miejsc potencjalnego błędu tym lepiej.

Na sucho

DRY jest w zasadzie uzupełnieniem KISS i w sumie też powinna być znana przez każdego kodera. Niestety z wielu względów nie jest stosowana i nie może być stosowana. Kiedyś miałem taką fazę, że wszystkie dane do wyświetlenia, które powtarzały się co najmniej dwa razy, wrzucałem w tablicę i wyświetlałem w pętli. Szybko się okazało, że często sama pętla jest bardziej skomplikowana. Niemniej pętla foreach wciąż jest moim najlepszym przyjacielem, zwłaszcza po odczytaniu tablicy z bazy danych.

Tak naprawdę to w DRY chodzi raczej o wrzucenie powtarzających się podobnych kawałków kodu do funkcji i wywołanie jej z odpowiednimi parametrami. W miarę jak rozbudowuję swój system, coraz częściej natykam się na takie sytuacje, że niezależne moduły mają podobne fragmenty (które zresztą często były pisane na szybko i spokojnie można użyć krótszych konstrukcji). Wrzucam więc je do funkcji (a czasami tworzę klasę) i z miejsca zyskuję kilka kB i łatwość pisania kolejnych modułów, gdzie zamiast kopiować duży fragment kodu, kopiuję tylko wywołanie funkcji.

Miałem taką sytuację z wysyłaniem e-maila z formularza kontaktowego. Za każdym razem musiałem pisać kilkanaście linijek kodu (w sumie to je kopiowałem). Teraz wysłanie e-maila to wywołanie jednej funkcji SendMail a cała reszta (formatowanie, walidacja i wysyłanie wykonuje się gdzieś w funkcji).

Oczywiście nie należy przesadzać. Bo może dojść do tego, że funkcja, w zależności od przekazanych parametrów będzie robić różne rzeczy (tak też pisałem). Ale potem może się okazać, że rozbudowa takiej funkcji to dużo więcej zabawy niż to ma sens, trzeba ją rozbijać na podfunkcje a te znowu... We wszystkim trzeba zachować umiar i zdrowy rozsądek.

Jak to się ma do mojego frameworka?

Optymalizacja, optymalizacja i jeszcze raz optymalizacja. Staram się pisać jak najzwięźlej, nie tworzyć skomplikowanych struktur (kodu, jak i danych - o budowie tablic już pisałem i pewnie jeszcze wspomnę). Podczas rozbudowy ciągle znajduję miejsca, gdzie można by coś skrócić. A czasami przepisuję od nowa całe kawałki kodu, bo okazuje się, że w międzyczasie wpadłem na pomysł całkiem nowego podejścia do problemu. Pisanie frameworka jest dla ludzi mających czas, zapał i motywację. Moją motywacją jest coraz szybsze tworzenie serwisów internetowych. A co za tym idzie mam coraz lepszy stosunek zarobków do czasu pracy, czego nie miałem, gdy korzystałem z WP.

Czytaj dalej

Spodobał Ci się wpis? Udostępnij go w Social Media:
Jeśli podoba Ci się wpis,
koniecznie zalajkuj,
skomentuj i zapisz się na