So sieht modernes PHP aus

Der Titel ist wirklich anspruchsvoll, nicht wahr? Ja, ist es. Obwohl ich seit Jahren mit PHP arbeite, wie kann ich die besten Praktiken und Tools für den Job angeben? Ich konnte nicht, aber ich werde es tun.

Ich sehe eine echte Veränderung in der Art und Weise, wie Entwickler ihre Arbeit mit PHP erledigen. Nicht nur die Sprache ändert sich drastisch, um mit neuen Versionen und Verbesserungen reifer und robuster zu werden, sondern auch das gesamte Ökosystem um sie herum.

Es werden neue Tools, Bibliotheken, Frameworks und Artikel erstellt und Muster definiert, um den Code eleganter und verständlicher zu gestalten. Mehrere Leute überlegen, wie sie die Arbeit (und Ihr Leben als Entwickler) produktiver, sauberer und unterhaltsamer gestalten können.

Ich bin kein früher Anhänger neuer Trends, eigentlich nehme ich ein neues Tool nur an, wenn ich sicher bin, dass eine Community dahinter steckt und ich denke wirklich, dass es meine Arbeit verbessern wird. Ich versuche immer, meinen Code gemäß den Best Practices zu schreiben.

Aus diesem Grund habe ich einige Zeit gebraucht, um Dinge wie Composer und PHPUnit zu verwenden. Vor ungefähr einem Jahr habe ich mehr oder weniger mein Herz für all diese glänzenden neuen Dinge geöffnet.

Zuerst kam PSR, dann Composer, PHPUnit, Travis-ci und mehrere andere Bibliotheken und erstaunliche Tools. Ich verwende jetzt sogar eine IDE (Vim FTW, aber PHPStorm mit XDebug-Integration ist ein Muss für einen vernünftigen Workflow)!

Was ist modern?

Es gibt unzählige Artikel im Internet darüber, wie schrecklich PHP ist, wie schrecklich Ihr Leben wäre, wenn Sie mit PHP-Code arbeiten müssten, wie hässlich die Sprache ist und was auch immer Sie sich sonst noch vorstellen könnten!

Wenn Sie mit Legacy-Code arbeiten, ist Ihr Leben vielleicht nicht so gut, aber wenn Sie die Möglichkeit haben, an einem neuen Projekt zu arbeiten und alle neuen Tools verwenden können, werden Sie dieses neue PHP sehen Ich werde darüber reden.

Ich habe mehrere Probleme mit der täglichen Arbeit mit PHP, aber man kann die Augen nicht vor den Veränderungen in Sprache, Community und Ökosystem verschließen. Es liegt ein langer Weg vor uns, aber im Land von PHP werden die Dinge reifer.

Ich habe angefangen, ein SDK für eine interne API in dem Unternehmen zu erstellen, für das ich arbeite, nur als Haustierprojekt, und mich entschlossen, Best Practices zu befolgen. Die meisten davon habe ich bereits gemacht, aber ich habe einige Änderungen an der Art und Weise vorgenommen, wie ich einige Dinge mache. Diese Änderungen und das, was ich im letzten Jahr gelernt habe, sind Gegenstand dieses Artikels und das, was ich Modern PHP nenne.

Beginnen wir mit dem Workflow

Wie gesagt, ich bin ein Neuling in dieser IDE-Sache, aber es war Liebe auf den ersten Blick. PHPStorm ist eine großartige Software. Es ist meine erste und einzige IDE. Es war mein erster Versuch und ich musste nicht einmal einen anderen versuchen.

Die Integration mit XDebug ist perfekt, PHP-Namespace-Auflösung, Composer-Integration, Git-Integration, automatische Vervollständigung, Code-Generierung, Code-Refactoring. Ich könnte weiter und weiter machen.

Ich denke nicht, dass Sie eine IDE verwenden müssen, eigentlich ist dieser Punkt ganz persönlich. Sie sollten alles verwenden, was Ihren Anforderungen entspricht - Vim, Atom, Emacs, Bracket, NetBeans, PHPStorm, Eclipse, was auch immer. Zwei wichtige Punkte sind hier Produktivität und Ergonomie. Ihr IDE / Texteditor muss da sein, um Ihnen zu helfen.

Ein großartiger Punkt für mich ist jedoch die Debugger-Integration. Um Code für große Projekte zu schreiben (eigentlich auch für kleine), müssen Sie einen anständigen Debugger verwenden. Vergessen wir diese var_dumps und print_rs. Sie müssen diese Variablen zur Laufzeit stecken, Stapelspuren analysieren und Haltepunkte festlegen. Diese Dinge sind wichtig und erleichtern die Entwicklung und das Refactoring.

Ich weiß nicht einmal, ob es hier andere Optionen gibt. XDebug bietet alles, was Sie brauchen. Hast du ein paar minuten Wenn Sie dies noch nicht getan haben, nehmen Sie sich einen Moment Zeit, um XDebug einzurichten und in Ihre IDE oder Ihren Texteditor zu integrieren. Beginnen Sie mit dem Debuggen Ihres Codes mit den richtigen Tools.

Das andere Tool, auf das ich Sie aufmerksam machen möchte, ist GitHub. Ein weiterer ganzer Artikel könnte darüber geschrieben werden, wie gut Git und GitHub sind und warum Sie beginnen müssen, Ihren Code unter einem Versionsverwaltungssystem zu halten. Aber ich möchte Ihnen einen anderen Grund zeigen.

Der Fokus liegt hier auf der Integration.

Es gibt verschiedene Tools, die in GitHub integriert sind, und Sie sollten sie verwenden. Diese Tools können Metriken generieren, Tests ausführen, Jobs während eines kontinuierlichen Integrationsprozesses für Sie ausführen und alle möglichen Dinge in Ihrem Workflow erledigen. Die Integration ist ein guter Grund für Sie, GitHub zu verwenden. Alle anderen unterliegen einem weiteren Moment.

Abhängigkeitsmanagement

Ein weiterer Punkt in diesem modernen PHP-Ökosystem ist das Abhängigkeitsmanagement, und Composer ist das Werkzeug für diesen Job.

Der Komponist ist 5 Jahre alt, aber es scheint mir, dass vor ein paar Jahren eine massive Adoption stattgefunden hat. Vielleicht, weil ich kein Early Adopter bin oder weil PHP-Entwickler sich nur ungern ändern.

Dieses Tool bietet ein Front-End für Packagist, ein PHP-Paket-Repository, das aus PHP-Bibliotheken, -Projekten und -Tools besteht und dessen Quellcode in Github (oder anderen Orten wie BitBucket) gespeichert ist.

Alle Bibliotheken, über die ich in diesem Artikel spreche, und vielleicht eines Ihrer Lieblingsprojekte, können mit einem einfachen zu Ihrem Projekt hinzugefügt werden

$ composer require package_vendor/package_name

Wenn Sie den Anbieter eines Pakets nicht kennen, können Sie searchfür ein Paket das richtige finden und installieren.

$ composer search package_name

Composer wäre ein großartiges Tool, wenn es nur diese Arbeit erledigen würde, Abhängigkeiten verwalten würde, aber es macht viel mehr. Nehmen Sie sich Zeit, um Composer zu installieren, und lesen Sie die Dokumentation.

Befehlszeilenschnittstelle richtig gemacht

Ich probiere Ideen sehr gerne schnell über CLI-Schnittstellen aus. Für mich ist IPython eines der besten REPL-Tools. Es hilft Ihnen dabei, Ihren Code automatisch zu vervollständigen, Funktionen einfach zu definieren, den Zugriff auf die Dokumentation zu vereinfachen und einige andere erstaunliche Funktionen zu nutzen. Der Nachteil für uns ist, dass das Tool für Python und nicht für PHP ist.

In der PHP-Welt gibt es einen sogenannten „interaktiven Modus“, auf den das Terminal durch einfaches Tippen zugreifen kann

$ php -aInteractive mode enabled
php >

Zu diesem Zeitpunkt befinden Sie sich im interaktiven Modus und können mit dem Testen beginnen. Es funktioniert, aber das Tool ist einfach zu unintuitiv. Ich habe es mehrmals versucht, aber da ich wusste, was IPython konnte, konnte ich es nicht weiter verwenden.

Zu unserem Glück gibt es eine coole neue CLI (Command Line Interface) auf dem Block und der Name ist Psysh. Psysh ist ein erstaunliches Tool mit vielen interessanten Funktionen, das mit Composer global oder pro Projekt installiert werden kann.

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

Dies ist ein Mantra, das ich mir jeden Tag sage. Wie viele Leute teste ich meinen Code nicht so oft, wie TDD vorschlägt. Ich fange jetzt an zu testen und mache das seit einem halben Jahr, und es liegt ein langer Weg vor mir.

Ich habe mich entschlossen, bei der Arbeit mit einem komplexen Legacy-Projekt etwas über Tests zu lernen. Der Code war so zerbrechlich und starr, dass jedes Mal, wenn wir Code hinzufügten, etwas kaputt ging. Neue Funktion? Etwas umsetzen und kaputt machen! Einen Fehler beheben? Erstellen Sie eine andere.

Das war ein großes Problem, das ich in einem anderen Artikel besprochen habe und das mich dazu brachte, Tests eine Chance zu geben.

Das erste Tool, das mir vorgestellt wurde, war PHPUnit. Wie auf der offiziellen Website angegeben

PHPUnit ist ein programmiererorientiertes Testframework für PHP.

Es ist eine Instanz der xUnit-Architektur für Unit-Testing-Frameworks.

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
  • Composer: dependency management and other useful features
  • Packagist: package repository
  • Twig: template engine

The title was really pretentious, I know. What I really wanted to show here is that PHP is evolving and the ecosystem is evolving at the same (maybe faster) pace.