Quick Read: Managing Complexity #171
Description
Tips Managing Complexity
Now that you'll start developing apps when many moving parts, it's time to start thinking about how to manage complexity. That is the next step from "knowing how to code", since you now understand the basic principles of software development.
The approach I recommend to designing a complex app is to build small chunks of functionality end-to-end. I'll use the Shifts Logger as an example. We can separate the functionality for this app in a few big groups:
1 - CRUD UI
2 - CRUD Back-End
3 - Extra functionalities UI
4 - Extra functionalities Back-End
Each of these can be subdivided into small chunks. Let's use Item 2: CRUD Back-End as an example. You can create similar sub divisions for all items listed above.
2.1 - GetShifts endpoint
2.2 - GetShiftById endpoint.
2.3 - DeleteShift endpoint.
2.4 - UpdateShift endpoint.
2.5 - AddShift endpoint.
Another example: extra functionalities Back-end.
4.1 - Filtering
4.2 - Sorting
4.3 - Searching
4.4 - Validation.
As you already know by now, so many moving parts can get out of control very quickly. Even though the first step is done (dividing the development of the app in groups of tasks and sub-tasks), the next step is even more important. It consists in make sure that each functionality is tested and backed up before moving onto the next.
An example: If you start with GetShifts, you want to be able to call that endpoint from Postman (I insist in the use of postman because you can save your requests). You also want to have a BRANCH (not a simple commit) in Github with a very clear name (e.g. Step 7 - Getshifts endpoint), that will contain the state of the app at that point in time. This gives you peace of mind. If you get stuck in the next step you can always go back to a working version.
The worst mistake you can make is to try to implement 2.2, 2.3, 2.4, 2.5 without testing and creating branches for each. If you get stuck, you'll have to go back to 2.1 having lost many hours of work. That will take a dent in your morale. In postman you can even create automations that let you test all end points in one click.
Another example would be to try to implement filtering, sorting, searching and validation all at the same time. It will be hard to figure out exactly what's wrong if you don't test each separately.
To finalize (for now), another thing I mentioned is to create an end-to-end functionality. That's what I used to do when I first started. I'd create the GetShifts endpoint and then create the UI for it (menu + service + API call + table display). This way you'd group your tasks in end-to-end functionalities. I used this approach when I first started. And still use it when I have to add new functionality to an existing app. However, when developing new apps I tend to create all of the back-end first, followed by all of the front-end. It's up to you really and you'll figure out your style with experience.
The main take away: Divide, test, back-up and conquer.