Welcome back to our 3-part blog post series on how to build a new feature for your application. This step-by-step guide will help you with your development process.
Last week we started with Analysis, this week we’ll dive into the Implementation phase. This will be the most involved part of our series. We will tackle schema, impact and the actual building itself.
Let us dive right back in!
Step 1: Draw a schema of how the new feature fits in your current application
We now have a clear idea of what and how we are going to implement our feature. Next, let’s create a visual schema of how the new feature will fit into the application. Try to visualize which existing parts have to be changed, and what has to be added. Use a color code (and a legend communicating it to other readers) to help you figure out how everything is going to fall into place.
In order to finish the whole schema you’ll have to go over everything you’ve learned through the process described in our previous post. By doing so you might also rethink some of the design decisions that were made in the past to make sure your new feature will fit into your application in a reasonably elegant way.
So make sure you take your time, and think everything through. You won’t be able to finish the schema without changing your mind about a thing or two, I suggest you use a tool that allows you to easily adapt your schema to inevitable changes. I personally prefer using Draw.io, a simple tool offering presets for software development.
Example schema:
Step 2: Make a list of existing things that will be impacted
When your schema is finished you should be able to see which parts of your application are going to be affected. Take your time to create a impact list of all these parts of your application. Make sure you also take note of how critical a change is going to be. The critical parts of your system should already have test coverage, so if you change them you can use those tests to see if you broke them or not. If you don’t have test coverage for risky bits yet, it’s not too late to add them now.
The reason we make this overview beforehand is because we want to have a clear threat assessment of which part of our application should be getting extra monitoring when our new feature is released. The impact list can also be used to let your product owners know which parts might conceivably be affected by the new feature, so they can keep an eye out for any difficulties as well.
Step 3: Ask feedback
Just like we did during analysis, make sure to get feedback from the product owner. If you’re developing in a team environment, ask someone to look at your schema and impact list to get a second opinion.
Ask your product owner for their thoughts on the impact list. They might have some extra concerns you’ve overlooked, and help you complete the list. The more feedback you get at this stage the more secure you’ll feel about the decisions you’ve made.
Step 4: Build your feature and write tests
Now it’s time to actually build stuff. Implement the actual new feature according to your well-thought-out plan and write tests for it during this process (or beforehand, if you’re doing TDD). Writing tests is a crucial concern here. The more tests you have, the easier future implementations will become and the less chance you have of introducing new bugs.
Step 5: Test your feature
This step is pretty self-explanatory, when you create something make sure you test every part of it yourself.
Over the years I’ve seen many people deliver code without actually testing some parts because ‘they should work‘. This makes you look foolish when basic functionality fails (invariably during a demo). Take a second to go over your complete feature and test every aspect, no matter how bullet-proof it may seem.
Step 6: Test your impact list
In step 2 we took some time to make an impact list. Once you think your feature is ready and you tested it thoroughly this is the time to test every part of the application you’ve mentioned on your impact list. Make sure all affected functionality is still working like before. You can do this by running associated tests for example ;-)
Step 7: Write/Test migrations for your data
Your feature is ready to be released but your application changed slightly and your old data might not be working in the new setup.
Now is the time to create a migration plan. Doctrine Database Migrations might be what you’re looking for if your database needs to be altered.
When you’ve finished your migration process, make sure you test it on real data, not just development data. Make sure you test it on a production backup and do it multiple times, in the exact same way you will execute the migration in the production environment when the time comes to release your work.
CONCLUSION:
Implementation started with drawing up a schema and impact list, and concluded with the actual development and testing of the new feature. Once we were done writing code we made sure we had a migration plan.
After all this hard work we are almost ready to release our feature. But not quite yet! You can now go to our final step: Releasing.