We have our design, so let's step a little closer and examine the parts of the application where a little more detail may be required. For example, we have a controller method called onAddClick that will be handling the process of adding a new record, but what will this actually entail and are there any pain points hidden within? Here's what needs to happen when this handler is done with its job:
- Ask the user for a name for the new page
- Create a new blank record with default values and the page name
- Add the page as a child node of the current page
- Load the record in the detail panel
- Show the new record in the tree
That's a lot for a single controller action. Let's look at how we might code it to see whether we're trying to do too much. We'll write some pseudocode (fake code) to drill down into some detail:
newPageName = promptUser 'Please enter a page name'
newPageModel = new Page {
text = newPagename
}
pageTree.addAndSelect newPageModelThere's no JavaScript here, no Ext JS classes in use. We're just writing the code we wish we could write if there weren't any language or framework constraints. Given that, this code looks good—it's clear what's happening and we're not doing too much.
One thing to notice is that Ext.panel.Tree doesn't have a native addAndSelect method. We'll need to write this, but if it makes our controller code cleaner and shorter, then that's a good thing.
There's a truism in software development that code is harder to read than it's to write. Comprehending someone else's code without having the reasoning behind it can be difficult. Having said that, there's a difference between code that's a little hairy, a little scary—something that doesn't shout out its intent via comments, variable naming or method naming, and code that shows consideration for future maintainers.
In writing pseudocode, we're trying to ensure that the concepts behind our code are well fleshed out beforehand and that any difficulties are taken care of before we really start work on our application.
In complex cases, pseudocode won't go far enough. We'll have to write some real code in the form of a spike. In Kent Beck's Guide to Better Smalltalk: A Sorted Collection, SIGS, he talks a bit about this:
"Sometimes I call this a "spike", because we are driving a spike through the entire design. […] Because people variously associate "spike" with volleyball, railroads, or dogs, I have begun using "architectural prototype" to describe this implementation."
When creating a spike, we're pushing through any assumptions we have and testing our design decision on a tiny prototype (the smallest code snippet or application we can build to prove our idea).
This firms up our design by eliminating further unknowns. We can be sure that a UI component will support the feature we require because we've actually tested it in a practical example. If it's an architectural code spike, we can see whether the various elements of our design hang together in a way that "feels right", if it works within the framework being used, and the design patterns that have been chosen.
We can perform a spike on the addAndSelect method described previously, but we know that Ext.tree.Panel already has an add method and that the underlying selectionModel will allow us to mark a node as selected. Therefore, now that we have alleviated our concerns with pseudocode, there's no need to continue on to real code until we implement the real deal. As developers working under constraints of time and money, we need to be pragmatic, as long as we are certain that due diligence has been performed.