Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Tworzenie oprogramowania dobrej jakości

Wielokrotnie przeglądając forum, konkretnie wątki poświęcone problemom programistów, bardzo często ręce mi opadają i wcale nie dziwię się, że ludzie mają problemy a ich kod nie działa. Kod ten jest pisany bez większego planu i pokazuje braki programisty z zakresu podstaw inżynierii oprogramowania. Jednak nie to najbardziej kłuje w oczy. Największym problemem który dostrzegam to braki w znajomości podstawowych wzorców projektowych w związku z czym i brak podziału na warstwy w pisanych aplikacjach. Drugi z problemów najczęściej dotyczy koderów PHP, u innych pewnie nie byłoby o wiele lepiej gdyby platforma nie wymuszała uruchamiania np. komunikacji przez sieć lub operacji I/O na innym wątku.

Opiszę dziś jeden z podstawowych problemów czyli umieszczanie w plikach widoków (zawierających kod HTML) kodu odpowiedzialnego za walidację oraz komunikację z bazą danych. Poniżej przedstawiam odnośnik do przykładu z życia wziętego.

Przykład złego kodu z życia wzięty

r   e   k   l   a   m   a

Jak widać na poniższym przykładzie mamy całkiem niezły makaron, pomieszanie widoku i zagnieżdżone kilka odwołań do funkcji komunikacji z bazą danych. Być może dla początkującego programisty nie wygląda to najgorzej. Jednak gdy spojrzeć na ten kod z perspektywy osoby która miałaby go rozwijać przez najbliższe kilka lat nie jest już tak kolorowo. Pozwolę sobie opisać najbardziej złe nawyki oraz podać informację jak pisać się powinno aby uniknąć problemów.

Wielokrotne odwoływanie się bezpośrednio do funkcji mysqlowych.

Przypuśćmy że mamy takich „widoków” 20 i w każdym odwołujemy się bezpośrednio do funkcji mysql. Nagle po roku przychodzi klient i mówi że przepinamy się na bazę postgresa, oracle lub Bóg wie co jeszcze. Chyba potraficie sobie wyobrazić ile pracy was czeka aby zrobić taką przepinkę. Co można zrobić żeby uniknąć takiej sytuacji? Mamy kilka opcji.



  • Możemy skorzystać z pomocy ORM’ów, w PHP osobiście używam Propela. Oprócz niego istnieje Doctrine, z którym nie miałem nigdy styczności. ORMy poza pośredniczeniem między bazą danych, mapowaniem wyników zapytań na obiekty itp., oferują jeszcze zabezpieczenie przed atakami SQL Injection. ORMy to podstawa w większości zintegrowanych frameworków PHP takich jak Symfony, Zend, Kohana.

  • Jeśli z jakiegoś powodu nie możemy/chcemy korzystać w projekcie z ORM’a możemy napisać prosty adapter w którym uwzględnimy zapytania sql, oraz który będzie nam zwracał konkretne wyniki.
    Np. Tworzymy klasę UserDao (DAO – Data Access Object) z metodą createUser, której parametrami będą: nazwa użytkownika, imię, nazwisko, hasło itp. W body owej metody wpiszemy:

    
    mysqli_query($link, "insert into users (login, haslo, imie, nazwisko, email) values ('$login',md5('$haslo'),'$imie','$nazwisko','$email')");
    

    Później zamiast wywoływać wszędzie mysqli_query możemy wywołać metodę z naszej klasy. Dzięki temu wystarczy zastąpić naszą klasę odwołującą się do mysql inną odwołującą się do np. postgresa, ale implementującą ten sam interfejs, aby zmienić silnik bazy danych w naszej aplikacji. Klasa UserDao, powinna mieć metody wyszukania, skasowania oraz wylistowania użytkowników.

Pomieszanie widoku z kodem biznesowym.

Wyobraźmy sobie że tworzymy naszą aplikacje w sposób taki jak w linku, który podałem wcześniej. Po jakimś czasie okazuje się, że nie jesteśmy już w stanie rozwijać aplikacji w pojedynkę i postanawiamy zatrudnić webdeveopera i fachowca od HTML, CSS, JS czyli frontendu. Aby podrasował wizualnie naszą aplikacje. Problem w tym że ów fach nie ma zielonego pojęcia o PHP i bazach danych. Wystarczy że wytnie przez przypadek jedną linie za dużo i katastrofa gotowa. Rozwiązań jak zwykle jest kilka.


  • Możemy skorzystać z gotowego systemu szablonów np. Twig lub Smarty. Dzięki czemu część biznesową przetworzymy w PHP, do szablonu przekażemy jedynie to co niezbędne do wyświetlenia informacji dla użytkownika. W takiej sytuacji jeśli webdevoloper popełni błąd logika biznesowa, walidatory itp., dalej będzie działać bez problemu.

  • Jeśli nie możemy/chcemy skorzystać z systemu szablonów możemy część widoku umieścić w osobnym pliku PHP, który zostanie dołączony na końcu przetwarzania naszego skryptu i który wyświetli jedynie wynik naszemu użytkownikowi.

Podsumowując

Brak sensownej architektury w aplikacji może doprowadzić w późniejszym etapie jej rozwoju do wielu błędów i niejednokrotnie zwiększy nam koszty (to nie tylko pieniądze ale też czas, który można by wykorzystać na coś innego) utrzymania takiej aplikacji. Osobiście polecam wykorzystać do tworzenia aplikacji webowej jakiegoś frameworku. Jeśli Zend lub Symfony jest zbyt ciężki polecam Kohane.

Osobiście zawodowo programuje w wielu językach programowania min. Java, ActionScript3, PHP, JavaScript. Z własnego doświadczenia wiem, że jeśli ktoś potrafi dobrze programować to nie powinien mieć problemu z programowaniem w żadnym języku. Mam nadzieje że mój wpis się wam spodobał. Jeśli tak, postaram się w przyszłości stworzyć więcej poradników jak tworzyć dobrej jakości kod. Jeśli macie jakieś pomysły na kolejny odcinek zapraszam do komentowania.
 

bezpieczeństwo porady programowanie

Komentarze