Development approach

This section will discuss some ideas for an approach to developing software whilst using Scaffolds. They are all opinions and ideas, useful for a starting point. Over time it will become apparent the way which will work best for your team.

Commits & Pull requests

When using Scaffolds it is important to think about the commit strategy that you will use. This way of working generates a large amount of code, so thinking about how you will use version control can help to save you time when it comes to reviews, merging or undoing any mistakes.

Due to the Scaffolds generating a large amount of code it can make for a very long pull request, especially if Scaffolding multiple pages at once. One way to mitigate the risk is to generate and commit all Scaffolded code first. This means that all the code within the commit is generated by scaffolds and therefore other than checking the names of the classes, there isn't a great need for a detailed review of this code. Subsequent changes to pages should then be done in new commits, so that new functionality such as content, navigation and validation can all be reviewed with a much smaller and more relevant diff. When it comes to reviewing the overall PR it can still be large, but because of the well thought-out commits, it can be reviewed commit by commit with confidence and thus reducing the time taken for the review.

Fixing mistakes

If you are Scaffolding code, the main mistake that you will come across is to do with 'naming things'. This will mainly come from the class name [MyNewClass]: property. This is the prefix for all controllers, views, models - everything. So there will definitely be a time when you wish you named something better. The easiest/fastest way to fix this is simply to delete all of the generated files and re-scaffold the page. If you have already migrated the page you will also need to undo the various changes to messages, routes and generators. This is another reason why it is recommended to get all the scaffolded code reviewed and committed sooner rather than later. Another alternative approach is to scaffold and migrate and then commit one page at a time, this will take you slightly longer, but it means that you could revert an individual commit which would be quicker than trying to delete/undo individual files.

Working with the wider team

The final point of consideration is collaboration with the wider team. Working with Scaffolds provides a lot of benefit as it can allow you to very quickly create a Walking Skeleton version of the service. This means that you can start getting feedback from the design team, stakeholders and even users very early in the service lifecycle.

This fast iteration requires great collaboration with the Design team and BA/PO when creating the tickets and workflow. There needs to be enough information up front for the development team to know which pages will be required for the flow. The bonus here is these pages need not be final - content, URLs and other aspects can and will change again multiple times before release. But the existence of a design of the initial flow allows the developers to get started on the journey quickly.

A great way to review and change content, URLs and validation is a closely collaborative review of the journey with the design team where you can talk about the pages in the context of their journey and make changes there and then as you go.