Let’s make a screen that tells us whether it’s a good time to have ice cream.
Writing some pseudocode
Turn the pseudocode into unambiguous method calls
Notice that the methods do not yet exist. Also, we lack the data from the server to grant the third wish. We’ll leave that one as psudocode for now. Mark it as a TODO: so that we can quickly search and come back to it later.
Now it compiles. Run it for our sanity, so that we can be sure that any code that doesn’t compile or run properly is due to the code that we wrote a few seconds ago, not minutes ago.
Now we stare at the method names, and repeat the process.
We did not yet introduce any new behavior up to this point. We are simply elaborating the specifications in the right context.
Here we see a common elements. We’ll make the method signature common among the two labels. Let’s refactor the method names, even before we write the methods.
Good. Let’s make some blank methods with those names and parameters, then fill them in.
We notice also that there is common behavior among the three view elements.
The common behavior is that we have to put the views in various positions of its superview. Meanwhile, refactor the order of these methods to reflect what’s actually on screen.
serverProxy is a global singleton that does not yet exist. updateViewOnWhetherI(Bool) is empty. To enable its function, those methods need to be filled out. Like a tree, the method keeps on sprouting until the behavior is added completely.
Sprout method encourages human-readable, self-documenting code really easily. Because the code chunks are so short and parameters present themselves naturally, code re-use is natural and little refactoring is required after passing the tests.
An additional benefit to sprout method for adding behavior is that you become immune to interruptions. By putting //TODO: heads where you’re not finished, you can recontextualize really quickly after being interrupted by your boss or coworker. No grand plan survives a lengthy discussion in human memory.