Code re-usability was something that was highly emphasized upon in college. In fact, if there's one thing I remember (and only one thing) it's probably that. Except we never really learned 'how' to implement it effectively. And if you think that simply having a function addNumbers() somewhere in your code and calling it twice is considered reusable, then you still have a ways to go.
So in this post I will be going over a more advanced technique for code re usability, and one that has saved me countless hours and headaches in my coding career. This has been particularly more helpful in my freelancing career than anywhere else, as you tend to work on similar problems on different projects, normally with the same solutions.
Centralizing your code
If you want to truly be able to leverage your code, you have to have an effective method of centralizing it. What do I mean by that? I mean that your code needs one single place to live (forever). Whether that be in a directory that you include in every single project or in an online storage space that you pull from in real time, you need to have your code an arms reach away.
Note that I am not referring to keeping your code in source control, such as Github. That, you should be doing regardless of the project. I am more referring to the method that your projects can 'reference' this code in real-time regardless of the project. If you update a function for example, you ideally want every project that you own to receive this update.
I personally leverage the power of dynamic-link libraries to store my server-side coding modules. Essentially I manage one giant project comprised of many different namespaces, classes, objects and the like and continuously update and maintain it. Every new project that I create or work in will reference this DLL file. To read more about how I handle that, you can check out my post on DLL implementations. Note that this will depend on your current technology stack. As a .NET developer, I leverage this built in functionality in Visual Studio.
Once you decide on where you want to store your generic coding libraries, next up you will want to modularize it.
Modularization
Your coding logic can be categorized into various areas, such as cryptography, math, database operations, string manipulation and really anything that you are specializing in. If you are working with machine learning and A.I. algorithms for example, then you would ideally want to have this code separate from your database operations.
Here is a look at a small portion of my primary framework.
As a web developer primarily, I work a ton with security, databases, authentication protocols and API implementations. And that is the primary role that my Core framework plays. Each one of these namespaces/classes can include dozens or hundreds of functions and they can co-interact with each other as well. For example, the API namespace can very well use the functions available in the Database namespace, again making every bit of code more reusable.
This is where knowledge in OOP principles can be vital and can save you a fair amount of work. Being able to detect when inheritance or polymorphism are an effective tool can lead to more robust code.
Start with the concept of "Core" functionality an work your way downward solving your own problems in your current projects. That is the best approach when creating a centralized framework.
Functionality
Now to look at what each of these namespaces and classes offer. Again, this will depend on your specific type of work and your specific requirements. Let's take a look at the Security namespace from above.
More specifically the Cryptography class. There are various functions that can be implemented when dealing with cryptography. A few that you could implement might be the following:
private string GetMD5Hashed(string content)
private string GetMD5Hashed(string content, string salt)
private string GetSha256(string content)
private string GetVigenereCipher(string content)
Essentially functions dealing with the world of cryptography. Notice that each function is a standalone method and is only dependent on the input being provided. This follows the black-box coding model, which everyone should be aware of.
Content goes in, and you get the desired result without having to wonder how it was implemented. This is also why naming conventions can be crucial as well as the names of your functions should give away their functionality.
Maintenance
And lastly, I have to talk about maintaining your libraries once you have figured out centralization and modularization. If you don't maintain your code, it will inevitably stop working or slow you down in the long run, in which case you will stop using your frameworks and inevitably making this entire process collapse. I've seen it happen and it isn't pretty.
This isn't as simple as it sounds. If you have a function being used in 90% of your projects, you can't just delete or modify it on a whim. A process that I personally follow is to introduce new functionality into my libraries and slowly transitioning old code into the newer counterpart as I work on each project. If it isn't broke, don't fix it. But if you are improving upon it, then keep it up to date is important. Once none of your projects are using the old code, then you can continue forward with deleting it.
Note that I have been working on my particular framework for over a decade now, with hundreds (maybe thousands) of functions and spanning dozens of different namespaces. It is an ever evolving process as I continue to work with newer technologies.
The next time you write a line of code ask yourself "Can I use this code again in the future?". And if the answer is yes, then add it to your library.
If you found this article helpful and informative, give it a thumbs up and comment down below how you keep your code centralized and your particular tech stack.
- Walt