The idea of shift-left has become increasingly popular as teams face pressure to deliver software more frequently and with higher quality. Shift-left potentially speeds up development efficiency and helps reduce costs by detecting and addressing software defects as early as possible in the development cycle, ideally long before such defects get to production.

“Fixing the Pesky PL/SQL Error” could be considered a simple example of shift-left. Another nice thing about shift-left is reduced pain for developers. By front-loading development effort early in the process, we aim to accurately address requirements and produce solid solutions with a minimum of defects. Hopefully, there will be no defects at all.

Software development tools include facilities that can accelerate shift-left adoption. For example, IDEs such as Eclipse, IntelliJ IDEA, and SQL Developer include support for advanced plug-ins. The tool plug-ins can automatically identify code problems and security vulnerabilities. Moving such issues left can only be a good thing.

Summary

Fixing PL/SQL issues should be a straightforward exercise involving examination of log data and other database tables. Having a good development tool such as SQL Developer is indispensable. Once SQL Developer is configured to display line numbers, it becomes easier to correlate runtime error reports with the code that causes the errors.

PL/SQL provides type safety, so you can specify a procedure parameter type. This is always useful for those cases where the order of the supplied parameters is wrong.

Installing a stored procedure in the database is pretty straightforward using SQL Developer. You can verify the procedure has been stored by clicking the refresh button. Once installed, the procedure can be executed by right-clicking and selecting the Run option.

PL/SQL code errors are good teachers. The resolution of such errors forces us to adopt a rigorous approach. Indeed, the shift-left method described in “Shift-Left in Operation” is an example of such an approach, where the main goal is to push errors in the direction of developers rather than users. It is the former who can do something about the errors whereas for the latter, errors can result in a loss of confidence about the solution.

In the next chapter, I’ll apply the scale of resilience to score the PL/SQL code. This will illustrate how good or bad the code is in relation to its potential resilience. It also provides a basis for refactoring the PL/SQL code in order to improve its score.