Trup w szafie - poprawność kodu PHP Opcje

[hombrerro]

Od jakiegoś czasu współpracuje z dość dużą firmą hostingową, chyba ogólnie znaną. Praca polega na przepisaniu autorskiego (tzn. powstalego wlasnie w tej firmie) kodu systemu administracji kontami użytkowników. Dostałem konto na specjalnym developersko-testowym serwerze będącym "kopią serwera produkcyjnego" z opcjami "developerskimi". Opcja developerska polegała na włączeniu wyświetlania błędów na ekran a nie ich logowaniu.

Tyle tytułem wstępu.

Jak na serwer testowy monitowanie tylko o błędach typu E_ERROR jest dość odważnym posunięciem a tak właśnie było ustawione. Nikomu z wesołych programistów z firmy to najwyrazniej nie przeszkadzalo.
Ja jednak poszukałem dziury w całym, szczególnie po wstępnej analizie kilku plików, i wyprosiłem zmianę ustawień serwera.
Warningi i notice zajmowały srednio na kazdej ze stron około 2 ekranów.

Tyle tytułem rozwinięcia.

Błędy typu E_NOTICE i E_WARNING to też są błędy w kodzie i to czasem poważne i groźne.
Jednak mało kto zwraca na to uwagę chociaż np. w innych językach tego typu błędy są traktowane jako krytyczne zatrzymujące wykonywanie kodu.
php swą popularność (zasłużoną) uzyskało właśnie dzięki uproszczeniu zasad programowania, nie ma kontroli typów zmiennych, deklaracji zmiennych, gospodarowania pamięcią itd. Każdy może przeczytać byle jaki "tutorial" w internecie i programować. Najczęściej php jest pierwszym językiem z jakim takie osoby się zetknęły.
I to jest właśnie bół. php moim zdaniem nie jest wcale dobrym językiem dla początkujących gdyż nie narzuca ścisłych zasad programowania, nie wymaga "sterylności" kodu. Jaki procent osób piszących skrypty php przejmuje się np. wykorzystaniem zasobów systemowych? W php można olewać pewne reguły i wszystko działa na "stronce". I działa i działa i działa, pojawiają się nowe rozwiązania: bazy danych, szablony, CMSXFCPSy czy cokolwiek a nawyki a właściwiie ich brak zostają na zawsze. I są tak zwanym trupem w szafie.
Później tak się życie potoczy, że może trzeba będzie zrobić coś poważniejszego, jakąś "profeskę". Oczywiście zostanie zrobione, nawet fajnie będzie wyglądać...
I nawet będzie działać, tylko ( życie się toczy ) że wkrótce z aplikacji zacznie korzystać 100 razy więcej osób niż się to zakładało i zaczną się schody. Bo wszystko zacznie się sypać, zapychać, zawieszać, zapętlać a serwer zacznie umierać.

Przykład "systemu administracji" pokazuje to wszystko w praktyce.
I tak:
inkrementowane zmienne nie mają początkowej wartości ( a co najśmieszniejsze ta sama zmienna jest używana kilkakrotnie w module i jest inkrementowana od niewiadomo jakich wartości. Jedna z takich praktych powodowała błąd widoczny dla użytkowników)
- zmienne pochodzące z tablic $_POST, $_GET, $_COOKIE są ledwo co sprawdzane - zakłada się tylko, że zmienna jest albo jej nie ma. To są jedyne dwa stany istniejące w świadomości programistów.
- indeksy w tablicach są stałymi: $tablica[cos_tam]
- funkcje coś robią ale nie wiadomo czy im się udało
- itd.

Ale niestety nie jedyny przykład. Jakiś miesiąc temu instalowałem gdzieś system CMS - zdaje się że było to Envolution - też pojawiło się pare takich "gniotów" choć poziom zdecydowanie wyższy (i tu jest to chyba nieuwaga a nie olewactwo).

Dodatkowo dzisiaj ściągnąłem sobie ze strony php.skryptoteka.pl kilka okazów - no i to już jest "wolna amerykanka", oprócz kilku wyjątków, bałagan totalny. A najgorsze jest to, że ktoś sobie napisze "prosty licznik odwiedzin" który działa chyba tylko dlatego, że ma szczęście, wydali go do sieci z której pobierze go 1000 osób i wszyscy będą już "prosty licznik odwiedzin" mieli za sobą. A autor takiego oprogramowania zyska poważanie w środowisku (1000 downloadów).

Przepraszam jeżeli kogoś znudziłem ale postanowiłem dać upust swoim frustracjom spowodowanym poprawianiem bylejakiego kodu od patrzenia na który aż oczy bolą.
Wysłałem ten post na forum PRO bo uważam, że poprawne kodowanie jest największym profesjonalizmem. Myślę, że powinno się na to zwracać uwagę wielu osobom korzystającym z tego portalu - szczególnie początkującym. A tak przy okazji: fajnie w sumie, że tak gęsto i często odsyłacie błądzących do manuala może gdyby zapoznać się z nim a nie z tutorialem w sieci jakość kodu trochę by się podniosła.

[patrycjusz]

no to pozwole się wtrącić (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)
co do kodu autorstwa mojej firmy sądze że raczej nic poważnego nikt nam nie zarzuci (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
ale mam właśnie ostatnio doczynienia z takim kodem jaki opisał autor tematu, ba
nawet bałagan tam jest większy a serwis liczy miliony odsłon miesięcznie (średnio 5-7 mln), żadnych bardziej zaawansowanych mechanizmów, o jakimś keszowaniu nie wspomne, czy też o szablonikach, wszystko przemieszane na przemian (html/php/sql).
Długo się zastanawiałem jaka jest przyczyna takiego stanu rzeczy, i chyba już mam (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Programista - nie - a dlaczego ma odpowiadać za coś co mu firma (projekt menedzer) każde skodować, i to najczęściej "na wczoraj" i chłopak zapierd.. jak wółka leśna, nie wiele mu płacą itd, ja bym się nie spuszczał nad takim rozwiązaniem i zrobił na szybko raz dwa i po sprawie,
Projekt Menedzer (w firmie sprzedającej rozwiązanie) - to właśnie on jest współ winny całej sytuacji, powinnien inaczej dzielić czas wśród pracowników, inaczej negocjować prace itd,
Dodatkowo firma która zamawiała oprogramowanie, no przepraszam bardzo czy przy zakupie rozwiązania za 200 tyś, robionego prawie rok, nie można wziąść dwóch nie zależnych malućkich firm (za 5 tyś) które by audytowały kod?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)
Tak więc moim zdaniem, w takich sytuacjach wina leży raczej pośrodku i trochę dalej od samego programisty, to PM ma obowiązek rozplanować prace tak aby było ok, i to firma zakupująca rozwiązanie ma obowiązek sprawdzić co kupuje.
Proponuję Hydepark nie php Pro (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
pzdr