We have a lot of stored procedures in our system. They are pretty much bunbled together in packages. Since our database is Oracle, the packages had a specification and a body. The spec is the view of exported procedures to the outside world. While the body contains the implementation along with internal helper functions.
This is a pretty good setup. You only see procedures you can use in the spec. Details are hidden away in the body. You would think this is some good design. Well most of our job consists of identifying and correcting bugs in the software. This is difficult when the bug is in a stored procedure housed in a package. Many bugs only show up in production. That version of the code is secured very tightly.
Often times we need to run the code and output some debug statements. Usually we will extract the portion of code that is in question into a stand alone script. This is easy if the code extracted does not reference other private functions in the body. But if it does, you got a lot more work to do during extraction.
I often find myself making a lot more visible in the spec than I immediately need. This is because I anticipate the need to make a call to some of the helper functions from the outside for testing or debugging purposes. However that defeats the whole purpose of information hiding in the first place. It is almost a catch 22.
Check Your Subroutines - We are delivering our latest release to internal test today. Had a code review yesterday. Many issues were found. We are fixing the highest priority probl...