If there is any constant in the software world, it is that dependencies are constantly changing. Thus, this brings us to our second principle: modern applications must have an upgrade path for dependencies.
In the PHP world, this often means managing the Composer dependencies we rely on for our application. We should be aware of and willing to implement changes in the libraries we directly depend upon. This has two impacts on our code: first, it forces us to regularly follow along with the projects we use, and second, it forces us to pare down the list of dependencies that we ultimately depend on.
Projects are constantly changing, and it’s up to us to know what those changes are and follow along. While we may not understand every bug that goes into a release for a minor version, we should be aware of and planning for changes in major versions. We should know if a project uses semantic versioning or some other version, and we should be careful to limit our Composer updates to guard against unwanted versions. And if possible, we should consider supporting the author of the package, and being involved in its development.
In addition, the list of dependencies we accept in our application should be as small as possible. We should write our own code in cases where we might integrate a package for a single function. Packages that do make the cut and get integrated into our project should be proxied through our own adapters, to ensure we can easily remove them if they pivot or introduce changes that are incompatible with our needs. We should be careful not to depend on “third party dependencies” – those dependencies that other packages depend on, but we do not explicitly depend upon. And we should regularly review and clean up unused or underused dependencies. Tests around the integrations should be solid, as well.
These changes will help applications to have clear paths forward when packages upgrade, and eliminate the fear and uncertainty of upgrading by limiting the risk. By eliminating risk, we increase the chances we will do the upgrades, and this will increase the chances that the upgrades are pain-free or minimally painful overall.
Saturday, December 26th, 2020 @ 9:00 am | Comments (0) | Categories: Dependency Management
The first principle that a modern application must follow relates to testing. Specifically, how well the application is tested, today. This principle is simple, and stated as:
Modern applications must be well-tested.
It is not merely enough that an application be testable, but a modern application should be well-tested. There is a world of difference between the two: the first assumes that an application could, if the developer wanted, write tests. The latter assumes that the tests have been written and are in practice as a component of the application. This is ultimately the goal we are seeking with a modern application.
That’s not to say an application cannot be on the path to modernization if it lacks tests; however, it is impossible for an application to be truly modern without them. Applications must be simple to maintain and easy to change in order to be truly modern, two things that are impossible without an adequate test suite.
Note that I have not specified what kinds of tests are required here. I have not said you must have unit tests, or functional tests, or acceptance tests. Indeed, it is up to the developer, the business, and the team to determine the right balance of tests, the right coverage amounts, and the proper distribution of resources to provide for a test plan. This leaves the measure somewhat subjective, but it always was: code coverage has always been a poor metric of code and test quality.
A modern application must be well-tested. It is the only way the application can be sure to mature and change over time, without stress, without bugs, and without failure.
Friday, December 25th, 2020 @ 9:00 am | Comment (1) | Categories: Testing
| Newer Entries » |