Swoole 2019: Simplify complexity and break cocoons into butterflies

The Swoole open source project has a history of nearly 7 years since its first version was released in 2012. During these seven years:
8821 code changes submitted
287 versions released
Received and resolved 1161 issue feedback
Merge 603 pull requests
100 developers contributed code in total
Harvested 11940 stars at GitHub
Contributors
Synergetic process
In 2018, we launched a new version of Swoole4. Prior to this, the main programming method for Swoole was synchronous blocking mode or asynchronous callback. The new CSP programming based on coprocessor implementation has gradually become the only recommended programming mode we use. Collaborative programming greatly simplifies the complexity of asynchronous programming. Using Swoole4 coroutine is both simple and powerful. In the future version of Swoole5, we plan to remove non coprocessing related features and code, reduce historical burden, improve stability, reduce complexity, reduce unnecessary options, and achieve pure coprocessing.
In the past 6 years, our team has mainly focused on part-time development, with most of the team members coming from top domestic internet companies such as Tencent, Alibaba, Didi, Baidu, 360, and Xiaomi. Some of them are foreign PHP developers, and even Dmitry Stogov, the author of the ZendVM kernel for the PHP language, has contributed code to Swoole. In addition, we have also recruited some college students to write code for Swoole, gradually cultivating the younger generation of developers.
In July 2018, we established a full-time development team focused on the development of the Swoole kernel, as well as the native components and ecosystem of the Swoole Cloud cloud. Say goodbye to the past reckless team and transform into a professional open source technology research and development team.
Our goal is to make the Swoole project an industrial level technology such as Node.js and Go, and a cornerstone of the PHP programming language in asynchronous IO and network communication.
R&D management
After establishing a full-time R&D team, we gradually established a very comprehensive R&D management system to improve the software quality of Swoole. Mainly including the following aspects:
Test Driven (TDD)
Now we are investing a lot of effort in implementing unit testing scripts, pressure testing scripts, and automated testing to improve unit testing coverage. Currently, there are 680 test cases and 17 pressure testing projects, and the compilation and testing results of each Commit and Pull Request can be seen on the Travis CI platform.
The research and development work is also based on TDD. When developing new features, refactoring, and bug fixes, corresponding unit test scripts will be written first, covering all scenarios of code changes.
unit testing
Code Review
Conduct cross code reviews and code reviews among team members, and fully evaluate and discuss the details of code changes.
For major changes, a team review will be conducted, spending hours or even days discussing the details of each line of code change.
RFC mechanism
For non bug fixes, non performance improvements, non refactoring, new features, or changes that may change underlying behavior, we will proceed in four steps.
Initiate an RFC proposal, https://github.com/swoole/rfc... The proposal will provide a detailed explanation of the causes and consequences of this change, related configuration items, scope of impact, usage methods, and examples.
Proposal discussion, we will conduct a thorough discussion of the proposal, delve into the details, analyze the pros and cons, and refine the details. After all issues are discussed clearly, the project is finally approved and implementation begins.
The development leader creates a Git branch, writes unit test scripts, writes code, implements all the content in the proposal, and ultimately initiates a Pull Request
Cross review, check the code, propose improvement suggestions, provide feedback to the development leader, and continue to improve the details. Finally merged into the backbone.
The entire process was conducted publicly on the GitHub platform, and anyone interested in the Swoole project can participate.
Swoole RFC
Grayscale test
To ensure the stability of the official version, we will conduct grayscale tests on internal projects before release to verify the stability of the new version.
In addition, we have established contact with most authors of the Swoole framework, and the new version will be sent to authors of major frameworks for early trial. Significant underlying changes or incompatibilities will be communicated in advance with other open-source project authors on Swoole.
summary
In the past few years, the Swoole project has not been very professional, with many bugs and difficult to use areas, which has also caused many users to step into many pitfalls. After establishing a full-time R&D team in the past six months, we have made rapid progress in R&D management, and the stability and maturity of Swoole are no longer the same as before. Stability always comes first, and we will be more cautious and rigorous in the future to ensure quality.
reconfiguration
In the second half of 2018, we conducted multiple refactoring of the underlying code and made many optimizations in terms of code structure, readability, reusability, and encapsulation. Make Swoole software more concise and elegant.
In terms of programming language, we are gradually replacing C language with C++. The object-oriented, intelligent pointers, containers, templates, and other features provided by C++can help us further improve the development efficiency of our team.
We also welcome everyone from PHP to participate in the Swoole project and contribute code.
document
The documentation of Swoole is also a widely criticized aspect by developers. In 2018, our team gradually increased its investment in documentation. Rewrite and organize the document, add rich example programs, add more detailed illustrations, fix details, remove emotional statements, and be more objective, neutral, and rigorous.
2019 Future
In the new year, we mainly focus on three directions.
Subtraction
Remove non collaborative features, remove unnecessary modules, reduce historical burden, improve stability, reduce complexity, reduce unnecessary options, simplify complexity, and make things simpler.
The Swoole kernel will continue to continuously refactor and streamline, reduce the number of code lines, clean up redundant code, and achieve code reuse as much as possible.
Deep project
By the end of 2018, we had gradually established connections with companies that heavily use Swoole in production environments, including Tencent Cloud, Yuewen, TAL, Momo, Youxin, and others. Understand practical application scenarios and business models, engage in in-depth communication and cooperation, provide suggestions, help enterprise technical teams better solve business problems, and receive feedback to improve the underlying.
Ecological chain
In 2019, we will develop some supporting tools and components based on the Swoole4 collaboration to make up for the shortcomings of PHP in the Cloud Native era ecosystem.