Mech Retriever Dev Blog
Last post I talked about the architecture of Mech Retriever and what it allows me to accomplish.
One of the major things it does for me is allows me to have decoupled code.
By that I mean that the code isn’t just one big tangled blob–there are discrete pieces that do specific jobs, so that they can each do their jobs well. But another advantage is that I can swap out components for test versions that allow me a portal to test the system more easily.
This is essential software architecture stuff you may already know. But basically software architecture is driven by the SOLID principles, especially the first and last letters: S(ingle responsibility) and D(o not repeat yourself). Finding the balance between those is key to good code.
What’s interesting is you can use Test Driven Development with a decoupled architecture and swap out a component as mentioned above (specifically the view) and then you can develop the core logic of the code before you have to write any code that deals with displaying and graphics. This helps immensely, but it’s a bit of a strange leap to make–since you can’t see the results of your code on the screen, the tests become your eyes. Like a sixth sense, you learn to rely on your ability to test the code instead of a visual screen.
Of course you have to go back, implement the visuals, and manually test it with your real eyes later. But even then, it’s more useful to have developed that sixth sense, because it’s another major stream of information and will make writing and debugging your code much easier–sorta like the ability to hear the bugs sneaking up behind you even if you can’t see them.