Sådan ser moderne PHP ud

Titlen er virkelig prætentiøs, ikke? Ja det er. Selvom jeg har arbejdet med PHP i årevis, hvordan kunne jeg angive, hvad der er de bedste fremgangsmåder og værktøjer til jobbet? Jeg kunne ikke, men jeg vil gøre det.

Jeg ser en reel ændring i den måde, udviklere gør deres job med PHP på, ikke kun ændrer sproget sig drastisk for at blive mere modent og robust med nye versioner og forbedringer, men hele økosystemet omkring det ændrer sig.

Nye værktøjer, biblioteker, rammer og artikler oprettes, mønstre defineres for at gøre koden mere elegant og let at forstå. Flere mennesker overvejer måder at gøre arbejdet (og dit liv som udvikler) mere produktivt, rent og sjovt.

Jeg er ikke en tidlig antager af nye tendenser, faktisk vedtager jeg kun et nyt værktøj, når jeg er sikker på, at der er et samfund bag det, og jeg tror virkelig, det vil forbedre mit arbejde. Hvad jeg altid gør er at prøve at skrive min kode efter de bedste fremgangsmåder.

På grund af det tog det mig tid at begynde at bruge ting som Composer og PHPUnit. For omkring et år siden har jeg mere eller mindre åbnet mit hjerte for alle de skinnende nye ting.

PSR kom først, derefter Composer, PHPUnit, Travis-ci og flere andre biblioteker og fantastiske værktøjer. Jeg bruger endda en IDE nu (Vim FTW, men PHPStorm med XDebug-integration er et must for en sund arbejdsgang)!

Hvad er moderne?

Der er masser af artikler på nettet om, hvor forfærdeligt PHP er, hvordan dit liv ville være forfærdeligt, hvis du skulle arbejde med PHP-kode, hvordan sproget er grimt og hvad du ellers kunne tænke dig!

Hvis du skal arbejde med ældre kode, måske vil dit liv ikke være så godt, men hvis du har mulighed for at arbejde på et nyt projekt og er i stand til at bruge alle de nye værktøjer, vil du se denne nye PHP Jeg taler om.

Jeg har flere problemer med at arbejde med PHP på daglig basis, men man kan ikke lukke øjnene for de ændringer, der finder sted i sprog, samfund og økosystem. Der er en lang vej fremad, men tingene bliver modne i PHP-landet.

Jeg begyndte at oprette en SDK til en intern API i den virksomhed, jeg arbejder for, ligesom et kæledyrsprojekt, og besluttede at følge bedste praksis. De fleste af dem gjorde jeg allerede, men jeg har foretaget få ændringer i den måde, jeg gør nogle ting på. Disse ændringer, og hvad jeg lærte det sidste år, er genstand for denne artikel, og hvad jeg kalder Modern PHP.

Lad os starte med arbejdsgangen

Som sagt er jeg en nybegynder i denne IDE-ting, men det var kærlighed ved første øjekast. PHPStorm er et fantastisk stykke software. Det er min første og eneste IDE. Det var min knytnæveforsøg, og jeg behøvede ikke engang at prøve andre.

Integrationen med XDebug er perfekt, PHP namespace-opløsning, komponistintegration, git-integration, auto-komplet, kodegenerering, kode refactoring. Jeg kunne fortsætte og fortsætte.

Jeg tror ikke, du skal bruge en IDE, faktisk er dette punkt helt personligt. Du skal bruge det, der passer til dine behov - Vim, Atom, Emacs, Bracket, NetBeans, PHPStorm, Eclipse, uanset hvad. To vigtige punkter her er produktivitet og ergonomi. Din IDE / teksteditor skal være der for at hjælpe dig.

Men for mig er et godt punkt debugger-integration. For at skrive kode til store projekter (faktisk også for de små) skal du bruge en anstændig debugger. Lad os glemme disse var_dumps og print_rs. Du skal poke disse variabler ved kørsel, analysere stakspor, indstille breakpoints. Disse ting er vigtige og letter udvikling og refactoring.

Jeg ved ikke engang, om der er andre muligheder her, XDebug har alt, hvad du har brug for. Har du et par minutter? Hvis du ikke har gjort dette endnu, skal du tage et øjeblik på at konfigurere XDebug og integrere det i din IDE eller teksteditor. Start fejlretning af din kode ved hjælp af de rigtige værktøjer.

Det andet værktøj, jeg vil henlede opmærksomheden på, er GitHub. En anden hel artikel kunne skrives om, hvor god Git og GitHub er, og hvorfor du skal begynde at holde din kode under et versioneringssystem. Men jeg vil vise dig en anden grund.

Fokus her er integration.

Der er flere værktøjer, der integreres med GitHub, og du skal begynde at bruge dem. Disse værktøjer kan generere metrics, køre tests, køre job til dig under en kontinuerlig integrationsproces og gøre alle mulige ting i din arbejdsgang. Integration er en god grund for dig at begynde at bruge GitHub, alle de andre er genstand for et andet øjeblik.

Afhængighedsstyring

Et andet punkt i dette moderne PHP-økosystem er afhængighedsstyring, og Composer er værktøjet til jobbet.

Komponist er 5 år, men det ser ud til, at massiv adoption fandt sted for et par år siden. Måske fordi jeg ikke er en tidlig adopter, eller måske fordi PHP-udviklere er tilbageholdende med at ændre.

Dette værktøj giver en frontend til Packagist, som er et PHP-pakkelager, der består af PHP-biblioteker, projekter og værktøjer, hvis kildekode er gemt i Github (eller andre steder som BitBucket).

Alle de biblioteker, jeg taler om i denne artikel, og måske et af disse kæledyrsprojekter, kan føjes til dit projekt med en simpel

$ composer require package_vendor/package_name

Hvis du ikke kender leverandøren af ​​en pakke, kan du searchfå en pakke til at finde og installere den rigtige.

$ composer search package_name

Komponist ville være et godt værktøj, hvis det bare gjorde dette arbejde, administrerede afhængigheder, men det gør meget mere. Tag dig tid til at installere Composer og læse dokumentationen.

Kommandolinjegrænseflade gjort rigtigt

Jeg kan godt lide at prøve ideer hurtigt ved hjælp af CLI-grænseflader. For mig er IPython et af de største REPL-værktøjer. Det hjælper dig med at autofuldføre din kode, lade dig nemt definere funktioner, lette adgangen til dokumentationen og flere andre fantastiske funktioner. Ulempen for os, værktøjet er til Python, ikke PHP.

I PHP-verdenen har vi noget, der kaldes "interaktiv tilstand", som man kan få adgang til via terminal, bare ved at skrive

$ php -aInteractive mode enabled
php >

På dette tidspunkt er du i den interaktive tilstand og kan begynde at teste noget. Det virker, men værktøjet er bare for intuitivt. Jeg har prøvet det flere gange, men da jeg vidste, hvad IPython var i stand til, kunne jeg ikke fortsætte med at bruge det.

Til vores held er der en sej ny CLI (kommandolinjegrænseflade) på blokken, og dens navn er Psysh. Psysh er et fantastisk værktøj, fyldt med interessante funktioner og kan installeres globalt eller pr. Projekt ved hjælp af komponist.

The nicest Psysh feature for me is inline documentation. Accessing the doc for a PHP function without heading over to Php.net is great. The downside is that you need to do few things before it is fully functional.

After installing it, type the following commands (I’m using Debian here, this may not work for everyone) in order to get it working properly

$ apt-get install php7.1-sqlite3$ mkdir /usr/local/share/psysh$ wget //psysh.org/manual/en/php_manual.sqlite -o /usr/local/share/psysh/php_manual.sqlite

The first command is not mandatory and if you have the Sqlite already installed you can skip this step. The second command creates the directory to store the documentation and the third line downloads and save the doc into the previously created directory. Remember, all these commands must run as root.

Now you have this

Head to Psysh and learn more about this awesome tool.

You should start testing

Dette er et mantra, jeg siger til mig selv hver dag. Som mange mennesker tester jeg ikke min kode så meget som TDD antyder. Jeg går ind i test nu og har gjort det i det sidste halve år, og der er en lang vej fremad.

Jeg besluttede at lære om test, når jeg arbejder med et komplekst arveprojekt. Koden var så skrøbelig og stiv, at når som helst vi tilføjede noget kode, brød den noget. Ny funktion? Implementere og bryde noget! Retter du en fejl? Opret en anden.

Det var et stort problem, som jeg diskuterede i en anden artikel og fik mig til at begynde at give prøver en chance.

Det første værktøj, jeg blev præsenteret for, var PHPUnit. Som anført på det officielle sted

PHPUnit er en programmererorienteret testramme for PHP.

Det er en forekomst af xUnit-arkitekturen til enhedstestningsrammer.

So, PHPUnit is a framework for helping you create tests for your projects, unitary tests. It gives you several functions to test the outcome of your code and generate a nice output with the result from those tests.

Since I started thinking about tests, reading and talking to people about it, I’ve discovered another great tool, which complements the work you’ve put in those unitary tests, it is calle Behat, which is a BDD framework for PHP.

BDD (Behavior-Driven Development) is a development process which came from TDD (Test-Driven Development). Those acronyms are not important now, what is important is that you can specify your tests using a more natural language, a language that non-technical folks can understand.

This language is called Gherkin and is used to describe the expected behavior being tested. A test description, using Gherkin, looks like this

Behind those lines there is PHP code that is called whenever there is a match between a line and a regex pattern specified in the PhpDoc of the method. This code implements those steps and what a real user would do, using your SDK, application or web system.

The workflow with Behat is so smooth. After everything properly configured, you start writing all possible scenarios for testing a feature. The first time you run Behat, it gives you all the method templates you should add to your PHP Context class in order to implement each step in a scenario.

After that, you start writing the actual code for each step and keep repeating this cycle.

  • Implement PHP code for a step
  • Run tests
  • If everything is fine, write PHP code for another step
  • If something is broken, fix it

After half an hour of configuring and reading documentation, you are prepared to use Behat, you’ll see that in the end it is all PHP code and you already know how to program with it.

Continuous Integration

Continuous integration (CI) is a process - a way to do something, and this thing, for us software engineers, is creating software.

In plain English, it is the act of incorporating small chunks of code constantly (maybe several times a day) into your code base. Code which has been tested and did not break anything. CI helps you automate the building, testing and deployment of your applications.

With a few clicks you can integrate your GitHub project with Travis CI and every push to your repository will run those tests you created with PHPUnit and Behat, telling you whether the the last feature you’ve implemented is ready, or not, to be merged. Besides that, you can use Travis CI to deploy your code to production and staging.

Having a nice pipeline of work with a well defined process is great and Travis CI can help you with this job. Follow this nice Getting started and discover how interesting it is to think about the process of software development, not just the code itself.

Adhere to PSR-1 and PSR-2

If you don’t know what PSR is, you should. Actually, PSR stands for PHP Standard Recommendations and is proposed by PHP-FIG (PHP Framework Interop Group), a consortium formed by members from the biggest PHP projects, frameworks and CMSs, which are thinking about the future of the language, ecosystem and discussing standards to be followed.

For a long time, PHP had no coding style. I’m not that old, but every time I looked into someone’s project or library, it was following a different style. Sometimes the bracket was left in one position, sometimes it was put in the next line, different approaches were used to deal with long lines and every other combination of style and preference you could think of. It was a mess.

PHP-FIG does many other jobs, but by proposing a single unity of code, they are saying “Let’s stop worrying about code style, let’s everyone follow a standard and start thinking about creating great software”. Now, whenever you take a look at someone’s code you just worry about understanding how it works, not blaming the format, the structure.

There are, until the end of this article, 9 accepted PSRs proposing common solutions for common problems. But if you don’t know anything about those standards, start with the PSR-1 and PSR-2.

These standards propose the modern PHP coding style. Make sure you read them before start using them. Don’t think you’ll remember all of them when coding, it is a process, but to make you sure, there are tools to help you with it.

PHP CodeSniffer is a tool you can find on Packagist that you can install with Composer. I don’t think the repository name was the best choice, because it ships two different tools, phpcs and phpcbf.

Phpcs is the code sniffer, it will scan your entire code, looking for parts that are not following the configured coding standard.

You can use several coding standards with phpcs and you can even create your own. At the end of the code scan, phpcs shows you a list of the pieces of code not following the standard. It is great.

Now, how to change everything which is wrong? You could open every file, change the code, run phpcs again, see the error not being shown, and repeat the process. It’ll be extra boring.

To solve this problem, PHP CodeSniffer came with another tool, called phpcbf, or PHP Code Beautifier. You run phpcbf, following the same rule set and, voilá, it fixes everything for you, or it tries to do its best without breaking your code.

Try to create the habit of running phpcs and phpcbf before pushing any changes in your code to the repository, this will ensure that all of your code adhere to the standards and if someone likes your tool/project and wants to contribute, they will have no problem reading it.

Frameworks

I’m not going to dedicate too much time discussing frameworks. There are several good ones out there, each one with its ups and downs. Personally, I prefer not to use those big frameworks, with everything inside. I like the idea that you must use just what you need.

If you need a HTTP client, use Guzzle. If you need a template engine, use Twig. If you need a router, find a good component which suits your needs and use it. Glue these components together and create your application.

Symfony is doing a great job towards this concept. You can use the entire framework for a project, or you can just take whatever you want and use it. Simple as that.

However, whenever I need a framework to write an application, I chose one of the so called microframeworks. They are really small, offer just the basics and are easy to customize and easier to make them follow your project structure.

My microframework of choice is Slimframework and I think you should read about it. It is simple for doing small projects, but it gets a bit more complex for bigger ones.

By the way, and this is for those who are starting with programming, I really think that before adopting a framework and dying for it, you should try to create your own. This will give you the understanding of the whole mechanism and ease the adoption of a big one.

The Modern PHP Toolset

Let’s finish this article with a list of links. To me, these components, tools and libraries represent a great deal of what Modern PHP is:

  • Slimframework: a nice and cool microframework
  • Symfony: a bigger framework which is filled with great and reusable components
  • Guzzle: a simple and easy to use HTTP client
  • PHPUnit: a framework for unitary testing
  • Behat: a framework for Behavior-Driven Development
  • PHPCS/CBF: code sniffer and code beautifier
  • Faker: fake data generator
  • Psysh: a runtime developer console (CLI) full of amazing features
  • Komponist: afhængighedsstyring og andre nyttige funktioner
  • Packagist: pakkeopbevaring
  • Kvist: skabelonmotor

Titlen var virkelig prætentiøs, ved jeg det. Hvad jeg virkelig ville vise her er, at PHP udvikler sig, og økosystemet udvikler sig i samme (måske hurtigere) tempo.