Requirements for Resilience: What Versus How – Resilient Software and PL/SQL
Requirements for Resilience: What Versus How
I should note that even the world’s greatest developer will occasionally write code with bugs. Regarding bugs, PL/SQL is no different from any other programming language. In later chapters, I’ll look more closely at ways to structure PL/SQL to allow for a more resilient end result.
In the meantime, let’s establish some guiding principles or requirements. The merit of this approach is that it separates the what from the how. In other words, I will merely state what it is I want to achieve (i.e., resilient code) without making any demands on how that will occur in the implementation phase.
Differentiating between what and how helps avoid one of the most destructive of all modern software development habits: coding too soon. If you focus too much or too early on the how, then you miss out on an opportunity to elucidate exactly what you want the solution to achieve. By thinking about the what in this fashion, you can avoid complexity in the final offering.
Later in this chapter, you’ll see an example of an antipattern—the big block of SQL. We can replace the big block of SQL with a modular and more powerful block of PL/SQL.
Clearly separating the what from the how also lays the groundwork for future additions to code. This is because you have invested effort up front in articulating what it is you wish to achieve with the solution. Only then is the solution coded as part of the how stage of development.
To set the scene for what I’ll look at, the following are some broad coding requirements that can be useful in achieving resilience:
Ability to capture all errors and exceptions
Recoverability
Observability
Modifiability
Modularity
Simplicity
Coding conventions
Reusability
Repeatable testing
Avoiding common antipatterns
Schema evolution
Do these 11 requirements just sound like commonsense programming practice? That’s exactly what they are, but they will provide a kind of mental framework for achieving resilience. We’ll revisit these requirements in detail later and illustrate them with concrete PL/SQL code examples.
Process Versus Outcome
Developers (myself included) traditionally have a turbulent relationship with process issues. For example, few developers tend to actively prefer documentation to coding. Many of us see API creation as coding rather than as a form of design. Deep end-to-end testing can often appear to be a bit of a chore. Programmers like to program.
All of these process activities are, of course, pretty much driven by requirements definition, which is another process task that many developers may generally prefer to leave to others, such as business user groups.
For creating resilient solutions, it is preferable for developers to adopt a more holistic approach. In other words, developers should aim to acquire strong credentials across the process spectrum. This is not as difficult as it sounds. Developers can become excellent at defining or refining requirements because they have intimate knowledge of the workings of the code. Even better, the developer can structure code to facilitate future requirements even before such requirements have been articulated. These ideas will be further discussed in Chapter 5, where I cover feature-driven development.
Just like learning PL/SQL, it’s not an onerous task to get better at process stuff. We’ll see in later chapters that if you become an ace integration tester, you will often save yourself from having to revisit and repair code many months after having written it. Over time, it’s not uncommon to completely forget how a given block of code works. You’ll thank your younger self later for having had the foresight to write a test case (you’ll see this in Chapter 4) or even just a short wiki article. The test case is often invaluable because it directly verifies whether the code being tested works correctly. A failing test can be just as useful as a successful one because a failing test may indicate that the code is being called incorrectly or that some key design assumption is not being met.
The main point here is that skillful adherence to and use of process can materially improve outcomes. The development process is your friend; it is wise to treat it well.
Let’s dive into the motivation for learning and aiming to write resilient PL/SQL.