Hook scripts are flexible in their implementation. I want to show an easy way how to overcome the obstacle of system routines which contain high volatile code due to environmental changes like company changes, mergers and other changes within the logic of any system.
Hook scripts are normally scripts which are started in special situations on a server or within a software system. Hook scripts can be used to do some customized work during a process in an standard environment, they can be used to trigger other external systems or do a lot of other work which could no be done within a closed systems. Therefore, hook scripts are a great way to provide customers well defined points in a system which can be customized for special needs. I strongly recommend to consider hook scripts as customization solution for larger software systems. A good example are Subversion’s hook scripts.
During my professional life I faced several situations were I already knew that one or more parts of my new designed and implemented system were to be changed some weeks later on and that this might not be the last time a change was necessary. One time, I faced this situation shortly after a merger of my company. We had to change the convention of lot numbers to the new company standard. We had to face a transition time when we were forced to handle two different types of lot number which were totally different in nomenclature. What could be done here? I designed a system in C/C++ with approximately 100k lines at this time. I didn’t want to implement the reason for the next minor release straight into the system.
My idea to solve this situation was to use hook scripts to do jobs which perform tasks for volatile specifications and for volatile production environments which are characterized by continuous improvements and permanent updates and optimizations. I had this idea some years before for a part of the system which was also threatened by a volatile production environment. Volatile environments mean a permanent potential reason of change in any software system. I am a lazy guy and therefore, I did not want to make the changes deep within the C/C++ code every time again.
To stay at the example from above, I had designed my system in a way that lot number conventions did usually not matter. A lot number was equal to another if the string comparison was equal. Plain and easy. But I faced the need for a conversion of split lot numbers to root lot numbers. The conversion for split lot numbers also did change. The old convention we had were plain numbers for lots like “nnnnnnn” (n = decimal number). A zero in the 7th position was for root lots and was changed for splits to other decimal number. The new convention was “lnnnnn” (l = letter, n = decimal number) and split lots were marked with additional letters at the end, changing even the length of the lot number. I had to face the situation that I needed a method which could translate any lot number to root lot numbers…
The implementation was done in C/C++ with a simple call to POSIX’s system command which called a script which was stored within my normal shared system files somewhere at /usr/share/. The script was called hook_split2rootlot.pl. I implemented a simple logic with less than 20 lines there for the simple translation. Everytime I have to change the convention of translating these lot numbers I just need to change this little and easy to understand script and ready is my work. Due to the implementation in Perl, it is very easy to add a more sophisticated logic for other purposes, too.
A serious trade-off is only speed due to POSIX system calls are quite expensive in time. Hook scripts should only be used for functions which are not often called. For system parts which run very often and have to be fast another solution is to be implemented.
Hook scripts, if implemented in the right way, can make a system very flexible, customizable and also easy to administrated. I recommend to consider hook scripts during architectural development as a possible solution for flexibility.