Resilient Oracle PL/SQL

Chapter 10. Conclusion

In this chapter, we’ll draw together the main strands discussed throughout the book. Is it feasible to learn a new language and at the same time deliver resilient solutions? I think so, but it requires a disciplined approach. An important element is having a simple process. Rather than using complex documents at each stage of the development journey, it is possible to have a simple, 11-item checklist. Each of the resilience requirements introduced in “Requirements for Resilience: What Versus How” guides the developer in ensuring that the code delivered is compliant.

Is the code easy to understand? Is it modular? Does it capture all errors and exceptions? The checklist keeps these questions at the front of the developer’s mind as the project progresses. In this way, a simple process aids the developer and acts as a constant reminder that for code to be resilient it also has to survive a combination of new author additions and new requirements.

By structuring the resilient code as a testable feature, it has a macroscopic identity that subsumes the microscopic elements of which it is comprised. By using a feature orientation, it also becomes possible to open projects up in a meaningful way to other stakeholders, including more junior developers.

In Part III, the idea of a feature-oriented project is demonstrated with a simple invoice generator feature. The invoice starts life once a project is created (one row in a PROJECTS table) and then it becomes possible ...