Sometimes creating great software isn't a sprint, but a journey. Learning from your mistakes and going back to the drawing board can pay big dividends.
Join the DZone community and get the full member experience.Join For Free
Sensu is an open source monitoring event pipeline. Try it today.
After a lot of long days, finally, you are nearly finished with your project. Everything looks good.
But, one day, the tester said that your project is running too slowly. They played with some actions and it took a lot of time. It’s not acceptable, we can't deliver a software like that to our customer.
From a developer's view, you saw that when you click to 1 button, it’s not a simple action. They have a lot of actions behind the screen: validating data, checking constraints, adding related data, etc. But the customer doesn’t know and doesn’t care about that. They just want to see it faster and faster.
So, what can we (developers) do? Just try our best to make our project faster. That’s reason I’d like to talk about the 'Journey of Performance.' I hope that by sharing this post, you can make your project faster.
I won't go into technical detail because there are many reasons for performance problems, but I will show you the way in which you can fight to create better performance.
The First Step: Count the Project Performance
You can’t see if your project is getting faster if you don’t have anything to compare it to. At the least, you have to monitor the runtime of each feature.
There are several ways to count runtime, but the easiest way is to add log time inside your source code.
The first time you run this code, it will take time more than on subsequent runs. This is because the first time you run it the code has to the read data for a cache, which is why we have to run one feature a few times.
The Second Step: Make Your Source Code Better
The purpose: customize your source code, try to make it better.
Have a Senior Developer Look It Over
On each team, there are different coding styles and developers with different skill sets. Some people just try to make a function works or they don’t have the experience yet to make highly performant code. That’s why having an expert or senior look over the code is a good idea. This will help to make the source code better.
Focus on Improving Slow Functions
Some people try to review every function and customize them one-by-one. From my point of view, this isn't a good idea. For each project or each feature, there are a lot of functions, and it takes time to review them all. Due to the monotony of the task, it's very possible that the code reviewer could miss an error made in the original code. So, the idea is to just focus on reviewing functions that perform slowly.
Oop, but the question is, which ones are slow?
To answer this, use a performance testing tool to time each function.
For example, after testing a login feature, I got the following results:
You can see that the login feature has 4 main functions, after counting time. We can now easily see that if you want to improve the performance of this feature, just focus on
anthenticateUser() because the other functions don’t take a lot of time to run.
The benefit is we just focus on the main problem and ignore other functions.
The Third Step: Make it Different
After the second step, if the performance of your project is still far away from the expectations of the customer, then it's time to change the project structure or source code flow.
Why we have to do it? The answer is simple, you tried your best with the current structure and source code flow, but the performance wasn't acceptable, and you want to meet customer’s expectation so you have to work with another way.
When you change the structure it doesn’t mean you have to code everything again. It just means you change the way the functions work together. Sometimes just a small change in the workflow can lead to a big improvement.
In my team, we had a very similar situation. The customer had some libraries which they sent to us with an example and told us to follow a certain procedure. During development, we ended up applying too many features, but at that time we couldn't see any problems. At the end of the project, they asked us to improve the performance. So, after we changed the way to apply these libs, the software ran much faster.
The Last Step: Enjoy the Performance Journey
Sometimes it’s boring with normal coding, but it’s so exciting when you’re working on a performance topic. You can see the big picture of your project, you can see how the data comes in and goes out, how the database is really working, and so on.
Don’t think it’s too serious. Just enjoy the Performance Journey, make your project faster and faster, and after each step, you will feel so excited. Take it easy, enjoy your journey, and you can go faster.
Opinions expressed by DZone contributors are their own.