Prezentacja na phpCE Polska 2017. Omawiam historię PHP oraz sposób, w jaki wykorzystujemy go dzisiaj. Pokazuję, w jaki sposób wybierać narzędzia i architekturę, aby nasze projekty żyły na produkcji długo i szczęśliwie.
3. Skąd popularność PHP?
●
Niski próg wejścia (łatwo zacząć).
●
Bardzo dużo tutoriali, książek.
●
Duża społeczność na całym świecie.
●
Stosowany zarówno w małych domowych
projektach, jak i dużych serwisach
komercyjnych
●
Stale rosnąca wydajność
4. PHP powstał w 1994 roku jako prosty zbiór narzędzi do monitorowania ruchu na
stronie – Personal Home Page Tools, upubliczniony dopiero rok później.
PHP/FI 2.0 – prosty język skryptowy:
Suppose you have a form:
<FORM ACTION="/cgi-bin/php.cgi/~userid/display.html" METHOD=POST>
<INPUT TYPE="text" name="name">
<INPUT TYPE="text" name="age">
<INPUT TYPE="submit">
</FORM>
Your display.html file could then contain something like:
<?echo "Hi $name, you are $age years old!<p>">
It's that simple! PHP/FI automatically creates a variable for each form input field in your form.
źródło: http://php.net/manual/phpfi2.php
5. ●
PHP 3: przepisany silnik, zwiększona wydajność
i bezpieczeństwo
●
PHP 4: początki programowania obiektowego
●
PHP 5: modyfikatory dostępu do atrybutów/metod,
stopniowe ulepszenia w kolejnych wersjach: PDO,
obsługa wyjątków, namespace, domknięcia, wyrażenia
lambda
●
PHP 6: nieudana próba obsługi unicode, projekt
porzucono
●
PHP 7: taki, jaki znamy dziś: znaczny refaktoring
silnika, mniejsze zużycie RAM i czasu procesora;
skalarne typy parametrów (int, string), nowe
operatory (coalesce, spaceship)
7. Popularne błędy bezpieczeństwa
w skryptach PHP (małych i dużych)
●
brak odpowiedniego filtrowania danych wejściowych
●
SQL injection
●
cross-site scripting
●
file inclusion
●
nadpisywanie zmiennych globalnych
8. Co wyszło z użycia?
●
magic_quotes: niezgrabne zabezpieczenie przed SQL Injection, zależne od
konfiguracji serwera, polegało na automatycznym dodawaniu backslasha
przed cudzysłowami i apostrofami w danych wejściowych; sprawiało więcej
szkód niż pożytku, zastąpione przez PDO i prepared statements
●
register_globals: zmienne tworzone automatycznie na podstawie GET i POST,
co przyczyniało się do dziur bezpieczeństwa
●
funkcje mysql_* - zastąpione przez obiektowe odpowiedniki lub PDO
9. Problemy z programowaniem w PHP
●
Dużo przestarzałych materiałów
●
Sprzyja pisaniu "na szybko"
●
Nie wymusza jednego paradygmatu
●
Brak konsekwencji w budowie biblioteki
standardowej (str_pad, strstr...)
●
Zachowanie często zależy od konfiguracji
●
Jest interpretowany, więc wiele błędów wychodzi
po uruchomieniu – dlatego przydaje się statyczna
analiza kodu
13. Pułapki "małych" projektów
●
"To będzie prosta aplikacja"
●
"Tego nikt raczej nie będzie zmieniał"
●
"Niewielu ludzi będzie z tego korzystać"
●
"To taki wewnętrzny projekt, tylko dla nas"
●
"To tylko na chwilę, za miesiąc to zaoramy"
●
"To się raczej nie zdarzy"
Projekty informatyczne prawie zawsze rozrastają się
i działają dłużej, niż przewidywano
14. Korzystaj z dorobku innych!
●
standardy PHP-FIG: PSR-2, PSR-4, PSR-7…
●
frameworki ze wsparciem komercyjnym
●
popularne paczki Composera, np. http://moneyphp.org/
●
wzorce projektowe Gang of Four adaptowane dla PHP
https://github.com/domnikl/DesignPatternsPHP
●
Domain-Driven Design: https://leanpub.com/ddd-in-php/read
●
Architektura warstwowa:
http://alistair.cockburn.us/Hexagonal+architecture
15. Narzędzia są tworzone
przez ludzi takich jak Ty
– omylnych.
Twórz elastyczne systemy,
w których narzędzia można łatwo
wymieniać.
16. Composer
●
zastąpił PEAR
●
podobny do bundlera z Ruby
●
łatwa, semantyczna kontrola wersji
●
automatyzacja
●
generuje autoloader PSR-4
●
dobry sposób na modularyzację własnego kodu
18. Statyczna analiza kodu
●
Wykrywa popularne błędy, niedoróbki (code smells)
●
Bada złożoność kodu, liczbę zależności, czytelność,
podatność na błędy...
●
Pilnuje standardu formatowania kodu PSR-2
●
Uruchamiana lokalnie, przed commitem
oraz automatycznie po umieszczeniu kodu
w repozytorium (część Continuous Integration)
●
Przykładowo: PHP Code Sniffer, PHPMetrics, PHPStan
19.
20. Skąd wiesz, że Twój program działa?
●
Najpierw testy, potem implementacja.
●
Wykonywane przed i po commicie.
●
Są formą dokumentacji.
●
Kod nie może pójść na produkcję, jeśli testy się
nie powiodły.
class OrderTest extends PHPUnitFrameworkTestCase
{
public function testTotalAmount()
{
$order = new Order();
$order->addItem(new Product(), Money::PLN(‘100’), 3);
$this->assertEquals(30000, $order->getTotalAmount());
}
}
21. ●
Projektanci i testerzy piszą testy akceptacyjne,
które mogą być automatycznie uruchamiane
●
Testy akceptacyjne są formą dokumentacji,
która żyje, a nie idzie w zapomnienie jak
dokumenty Worda
Skąd wiesz, że Twój program działa?
22. Behat:
Feature: ls
In order to see the directory structure
As a UNIX user
I need to be able to list the current directory's contents
Scenario: List 2 files in a directory
Given I am in a directory "test"
And I have a file named "foo"
And I have a file named "bar"
When I run "ls"
Then I should get:
"""
bar
foo
"""
źródło: http://docs.behat.org/en/v2.5/quick_intro.html
Skąd wiesz, że Twój program działa?
23. PHPSpec:
namespace spec;
use PhpSpecObjectBehavior;
class MarkdownSpec extends ObjectBehavior
{
function it_converts_plain_text_to_html_paragraphs()
{
$this->toHtml("Hi, there")->shouldReturn("<p>Hi, there</p>");
}
}
źródło: http://www.phpspec.net/en/stable/manual/getting-started.html
Skąd wiesz, że Twój program działa?
24. Codeception:
class LoginCest
{
public function tryLogin(FunctionalTester $I)
{
$I->amOnPage('/');
$I->click('Login');
$I->fillField('Username', 'Miles');
$I->fillField('Password', 'Davis');
$I->click('Enter');
$I->see('Hello, Miles', 'h1');
}
}
źródło: http://codeception.com/docs/04-FunctionalTests
Skąd wiesz, że Twój program działa?
25. Czas wykonania kompletu testów powinien
wynosić maksymalnie kilka minut
źródło: https://www.symbio.com/solutions/quality-assurance/test-automation/
26. Dlaczego nie stosujemy TDD?
„U nas się takich rzeczy nie robi”
„To się nie opłaca”
„To tylko w książce tak dobrze wygląda”
„Terminy nas gonią”
„Musimy utrzymywać stary kod”
Brakuje nam wprawy w używaniu TDD.
Brakuje wprawy w pisaniu dobrych, pożytecznych testów.
Jeśli robimy to codziennie, mamy to w nawyku
– wtedy robimy to łatwo, przyjemnie i z korzyścią.
27. Debugowanie
●
"Metoda wędrującej d...py"
●
Xdebug – debugowanie linia po linii, zdalne
debugowanie, sprawdzanie pokrycia kodu testami
●
"Whenever you are tempted to type something
into a print statement or a debugger expression,
write it as a test instead" – Martin Fowler
29. Jaką architekturę wybrać?
●
surowy PHP nie wystarczy
●
Model-View-Controller (pożyczone z Ruby on Rails)
●
proste "modele" CRUD-owe nie wystarczają
w dużych systemach
●
Action-Domain-Response
●
architektura warstwowa/heksagonalna...
30. Baza danych
●
Ponoć jest tylko "szczegółem implementacyjnym"...
"The Principles of Clean Architecture by Uncle Bob Martin"
https://www.youtube.com/watch?v=o_TH-Y78tt4
●
Kiedyś: zapytania sklejane ze stringów, częste błędy
SQL injection, powolne wyszukiwanie...
●
Dziś: systemy mapujące relacje na obiekty (Doctrine,
Propel, Eloquent)
●
Dziś: nierelacyjne bazy danych; MongoDB, Redis
●
Dziś: szybkie wyszukiwanie (ElasticSearch)
●
Dziś: Command-Query Responsibility Separation
32. Vagrant, Docker czy localhost?
●
php -S – prosty serwer deweloperski
●
Vagrant: maszyna wirtualna z przygotowaną
konfiguracją (bash, Ansible, Chef...)
●
Docker: kontenery, które łatwo można deployować
na serwer testowy lub produkcyjny
●
Środowiska deweloperskie, testowe i produkcyjne
powinny być jak najbardziej zbliżone do siebie!
33. ●
Sentry: automatycznie zbiera i grupuje raporty, wykrywa
regresje; dostępne jako SaaS lub samodzielna instalacja)
Raportowanie błędów