diffon the different versions of files that were the same, and discovered that some had additional functions, that were removed when a newer version was put in place, but these functions were not removed from the core application. This caused the necessity to create additional files, and include lines in the application.
We would see include lines such as:
All within the same exact file, but being called for the necessity of various functions. It started to make our heads hurt.
The solution to this conundrum was to create a centrally located functions file in a location like
includes/functions.asp where we could then include one file, and as errors were thrown, we could pull the functions from the original 3 functions files, and fill in our new global file.
This allowed us to see what functionality was still being used, and trim off the fat, so to speak about what was not. After roughly 2 days of messing with the
functions.asp file, we have a single global include that now has all the required functionality needed to operate the software. This means that we were able to remove the other files, saving a few MB of disk space. And if you are familiar with AWS, Azure, Google Cloud Platform, you know that these MB of disk space mean money.
git commit and a few messages related to what we did later, and we have a more streamlined application, that we can continue to add global functionality to in a single location.
== v0.0.1 ==
* Initial commit of original project source to repository.
This is what we experienced when we took over the Vend-Trak VMS project. Not only is it written in a language that has minimal support now, but the hosting associated with it is still relatively specialized.
The project codebase is written in ASP Classic, and the source was never kept under version control. This makes for an interesting challenge to maintain. The previous developer wasn’t really a developer at all. Which is surprising, due to the fact that much of the code is well written. The issue is that there are 6 versions of the same exact file in 6 different folders, due to the lack of knowledge in maintaining a codebase.
When we received the .zip file that contained the project source, we just sat and reviewed it for days. This allowed us to become familiar with the how the layout affected the operation of the project. After taking a few days to review and become familiar with the code, we did what we felt was the absolute most important thing to do. We ran a shell command in the folder. One simple command,
git init. It wasn’t enough for us to have the .zip file that we could always refer back to. What happens if the computer crashed, or we accidentally deleted the .zip file. This was unacceptable in our shop.
After committing the source to a git repository, we started to make changes. Slowly, committing every change we made, so we had a rollback point. This allowed us to prune the codebase down, and produce a maintainable setup.
We started with the
default.asp file, which is the launching point of our application, and slowly changed paths, again, committing after every small change, due to the fragility of the application. Pushing these changes to the server after testing, allowed us to know that we were slowly bringing the code to a smaller footprint, allowing for optimizations at a later date.
That’s where we are right now, maintaining a smaller version. It is just that though, maintenance, we have not really made any structural changes to the code as of yet.]]>