Ew PHP, right? High-fives all around. Except that for my generation, the first cool web app you’d create would be written in PHP, often coupled…
Category: Building future-proof software
Future-proof software. For the longest time, I thought that future-proof software consisted in writing software so good you never need to change it. Over the years, I learned that it is actually software you should be able to change easily. Software that would adapt to future requirements while satisfying the current. Testing is a massive part of that. So is refactoring. Here are some blog posts around these topics.
If you are to embrace new requirements, you must design software so that you can refactor it. If you want to refactor your code, you need to have a way to test its current behaviour no matter how. For a web API, you may even go as far as using Postman to build a test suite.
And remember, whenever you build new production code. Write failing tests. Make the failing tests pass. Push to production. That way you never write unneeded code and if a refactoring is needed you have less to worry about. Yet you have enough to be confident while writing changes.
Welcome back to the future-proof series! Today I thought I would present to you a case very close to a code refactoring I made recently…
Today I will tell you why you should say no to git squash merges. Even better I will show you. First, I will explain what lead me to write this post. Then, I will provide you with steps to reproduce a problem that seems ignored. A problem that will eventually bite you if you keep using git squash merges. No spoilers until you get there. Hopefully, you will get my point. Since the aim of this post is to save you time in the future or even now this will also be the latest entry of my future-proof series.
About a year ago, I wrote a really short post about failing fast not meaning that we should not think first. Now that I think about it, I don’t believe I was fully in the right. The saying about failing fast was never about not thinking too long. It seems to be about experimenting with what you have in mind. We all have great ideas 24/7, cool software designs, new paradigms to try and so on. The point is to try to make things work in your first try, and the next one and so on. Which makes me think about refactoring.
Continuous delivery. You may recall that in my previous post I announced that today’s entry would be revolving around continuous integration. And technically it can count as such since we will cover continuous integration along the next step. That next step is continuous delivery. If you are not familiar with these terms and the concepts behind them I will sum them up briefly.
Basically, continuous integration allows verifying that your codebase still builds and passes tests passing whenever you push changes. Add a trigger to deploy your code to production upon success and you pretty much have the idea around continuous delivery.