With this combination of formatters, short hair, and build tools, I was able to create fully testable, fully portable solutions that met PSR coding standards.


Use the Makefile and make the most of it #

Most developers use Makefiles, but few use them effectively. Here’s an example of my typical Makefile:


container=app

up:
    docker-compose up -d

build:
    docker-compose rm -vsf
    docker-compose down -v --remove-orphans
    docker-compose build
    docker-compose up -d

down:
    docker-compose down

require:
    docker-compose run ${container} composer require

require-dev:
    docker-compose run ${container} composer require --dev

run:
    docker-compose run ${container} php index.php

jumpin:
    docker-compose run ${container} bash

test:
    docker-compose run ${container} ./vendor/bin/phpunit ./tests/

test-file:
    docker-compose run ${container} ./vendor/bin/phpunit ./tests/ --group $(FILE)

stan:
    docker-compose run ${container} ./vendor/bin/phpstan analyse $(FILE) --level 7

cs-fixer:
    docker-compose run ${container} ./vendor/bin/php-cs-fixer fix $(FILE)

tail-logs:
    docker-compose logs -f ${container}
Copy the code

The command that

Up, down, and build in their own words. These make it easy for me to interact with Docker and save some keystrokes. I also make sure that each project has the same command. So I always know which shortcuts I can use.


Require and require-dev are used to interact with the Composer installation located in my application container. I find it useful to run composers only in the Apps container. Why? In the past, I’ve had problems installing packages for different VERSIONS of PHP, for example, my host is 7.1, but the project I’m working on is 5.6. Running Composer in the container will isolate my application and ensure that only the correct packages are installed.


Run speaks for itself, while jumpin is just too lazy to save when I type docker exec-it <container-id> bash


Test can certainly run my entire test suite, but this is where things get interesting.


Hook the IDE into the make command

All of the following commands have been created to integrate into my IDE. My IDE of choice is PHPStorm.


Test-file is run every time the file is updated. It takes one argument, FILE. In PHPStorm, I set up the file monitor as shown below.

Stan provides more information below, but sometimes I run this command while the file is saved to statically check my code in real time.


Php-cs-fixer is a great tool to ensure that your code matches the Coding Standard [PSR] (PSR-1: Basic Coding Standard)


Run everything in Docker

When I say running everything in Docker, I mean applications, Composer, unit tests, and finally code specification fixes. By running everything in Docker, you can make your project 100% portable so that anyone on any machine can simply clone a copy of code and start right away.


As you have seen in the makefile above, each command is running in my Docker image. This will allow anyone to clone code, run tests, and run applications on any platform. None of this has PHP installed on your local machine.


Use CS-Fixer to enforce coding specifications

As mentioned above, A CS Fixer is a good way to ensure that all members of the development team follow the coding specification uniformly, see THE PSR Coding Standard. The documentation recommends that you install it globally, but following my rule of doing everything in containers, I recommend using:

composer require friendsofphp/php-cs-fixerCopy the code

Use PHP to Stan

PHPStan is a must for any project that uses PHP > = 7.1. Essentially, it statically parses the code to catch errors. You’ll have to use parameter type hints and return types, but by adding PHP Stan to your workflow, you’ll quickly notice subtle errors that already exist in your code and catch other future errors. This one has to be!


Use.editorConfig in the team

The last proposal is.editorConfig. This file is checked in to your source control and configured for team members’ ides. This ensures that everyone is using the correct format when working with the code base. Saves you unnecessary code conflicts and arguments over what TAB type to use and what TAB size to use.


[*]
end_of_line = lf
insert_final_newline = true

[*.php]
indent_style = space
indent_size = 4

[Makefile]
indent_style = tab
indent_size = 4

[.html]
indent_style = space
indent_size = 2

[{composer.json}]
indent_style = space
indent_size = 4
Copy the code

To learn more, please visit:

How to become an architect from a coder

zhuanlan.zhihu.com

I hope the above content can help you. Many PHPer will encounter some problems and bottlenecks when they are advanced, and they have no sense of direction when writing too many business codes. I have sorted out some information, including but not limited to: Distributed architecture, high scalability, high performance, high concurrency, server performance tuning, TP6, Laravel, YII2, Redis, Swoole, Swoft, Kafka, Mysql optimization, shell scripting, Docker, microservices, Nginx, etc.