After doing a substantial bit of work, it is often a good idea to take a step back and look critically at your work to see if things could have been done better. Quite often, the insight gained in the development process can be used to good effect in any new code or even to refactor existing code if the benefits are so substantial that they warrant the extra work.
Often, such a critical reappraisal is motivated by observed shortcomings in the application, like poor performance, or by noting that requested changes take more time than we like because the code is designed in a less than optimal way.
Now that we have designed and implemented several applications in the last few chapters based on a simple entity/relation framework, it is time to have that critical look and see if there is room for improvement.
Examine each major piece of code (often a Python module that you implemented) and ask yourself the following questions:
- Could I reuse it without changes?
- How much extra code was needed to actually use the module?
- Did you really understand the documentation (even if you wrote it yourself)?
- How much of the code is duplicated?
- How easy is it to add new functionality?
- How well did it perform?
When we ask these questions about the entity and relation modules we developed, we see that:
- It was quite easy to reuse the modules
- But they do require quite a bit of extra code, for example, to initialize tables and threads
Also, we deliberately wrote specific modules to deal with domain-specific code, like input validation, but it is worth examining this code to see if we can discover patterns and enhance our framework to better support these patterns. One example is that we frequently require auto completion so it is worth looking at how this is implemented.
Performance-wise, we saw in the books application that we have hardly addressed the way in which large lists of books are browsed and this certainly needs attention if we wish to reuse our framework in settings that deal with large lists.
Now that we have pointed out several areas where our framework modules might be improved, it is time to consider if it is worth the effort.
Framework modules are intended to be reused by many applications, so a redesign that will allow the modules to be used with less additional code is a good idea, as less code means less maintenance. Of course, rewriting may mean that existing applications need to be rewritten if they want to use these new versions, but that is the price to pay for better maintenance.
Refactoring existing functionality is often less problematic, but benefits greatly from a good test framework to check if the new implementation still behaves as expected. Likewise, adding completely new functionality is likely to be even less of a problem, as existing applications do not yet use this functionality.
Because, in our case, we judge the advantages to outweigh the disadvantages, we will rework the entity/relation framework in the next section. We will not only focus on using less code, but also on making the definition of the new Entity and Relation classes easier to read. This will provide for a more intuitive use of these classes.
We will also devote a section to developing functionality to browse through lists of entities in a way that scales well, even if the lists are large and need to be sorted or filtered.