In this era of “move fast and break things,” organizations often fail to consider the long-term costs of decisions made for short-term gains. When projects cut corners, lack documentation and/or tests, and are regularly changing it’s not uncommon for them to quickly become too expensive to maintain or, at the very least, technical pits of despair. Software doesn’t need to be painful, however, and a little pragmatism goes a long way towards mitigating so-called “technical debt.”
When I made the transition from hobbyist to professional programmer, I discovered it isn’t enough for my code to work; it also has to be easy to maintain. At first, I wasn’t sure how to make it happen. Then, when I read Robert Martin’s book *Clean Code*, I discovered good code is written with people in mind, follows a consistent format, has short functions, uses meaningful names, and avoids comments. Applying these principles has dramatically improved my code and can change your life as well.
Cloud technology can give applications greater flexibility, but it can be more complicated to maintain, especially for a monolithic legacy application. However, with a few tweaks, even older codebases can run in the cloud. Let’s take a look at how an older application which needs to scale can benefit from running in the cloud.
In part one, we laid the practical groundwork for using test doubles. Let’s explore the parts of Mockery that, in some cases, exit the realm of everyday usage and see how it can help us in dealing with scenarios we might have thought impossible to test like static method calls, spying on objects, and more.
The tech industry is a relatively young industry, and in many ways, it shows. In one of my favorite books, Hackers: Heroes of the Computer Revolution, Steven Levy talks about the birth of the open source industry going back to the late fifties and early sixties. Many of his descriptions of programmers then are not vastly different than programmers today. These problems are not technical and can drive good programmers away. What can we do to avoid these issues?
This month I’m running with a collection of odds and ends of Laravel which I feel strongly about or that answer some common questions about Laravel and the related ecosystem. I find these issues to be common among people who ask me about Laravel on social media or in person at conferences or user group meetups.
In this series, we look at using Behavior-Driven Development (BDD) and specification by example to develop a RESTful API. In Part Two we introduce Behavior-Driven Development as a way of communicating with non-developers, our stakeholders.
Every successful development team has two things in common: they’ve shipped a product, and they accepted compromises to make that shipment possible. Every team and every project has technical debt. It comes with the territory when you start building software. Usually, the term “technical debt” is seen as a negative, but that’s not always true.
Most people are aware of how the Composer revolution came about, and the goal of getting everyone to play nicely together. For the most part, it seems to have worked, and more and more developers are coming on board with avoiding “Not Invented Here” and embracing the more than 1.2 million versions of packages available today. With so many packages it can sometimes be difficult to know where to begin. “I’m going to look at some packages from the open source community you might find useful if you’re not already using them!
One of the fantastic things about the PHP language is that we, the community, are constantly evolving it. If you take a look at PHP code from just a few years ago, it can appear alien compared to anything written in modern PHP today. In fact, I’ve often stated that PHP was, in fact, unique among all the programming languages that exist currently. Yes, quite a few of them are open source; however, PHP is the only one truly embracing the open source concept. It is continuously changed, and not by a single gatekeeper but by a broad and vast team of engineers who use the language every day.
Leave a comment
Use the form below to leave a comment: