Coding for Reuse

Sure, you do not want to take a huge amount of time crafting a tiny one-off script or program like it is a micro service infested Saas application supporting hundreds of millions of users. For anything that you write of substantial size, impact, or sphere of influence, you should always code for reuse.

What is coding for reuse? To me, coding for reuse means that, while you do not necessarily build code to accommodate unknown future requirements, you write your code in a way that it does not make implementing future requirements unduly difficult. You can do that if you:

#1 Become a Librarian

Build your code into classes, components, or at the very least files and/or libraries that contain like functionality. Create namespaces from the taxonomies of the problem domains you are addressing. Become a librarian. Keep the books (the code) in your library (the namespaces) well organized throughout the evolution of your project.

#2 Avoid Duplicating Code

Capitalize on what you have written and avoid writing new code when possible. Static analysis tools can help you identify duplicate code “smells”.

#3 Draw Pictures

Before you start new projects, create diagrams of the major components that you will be building. As software developers, we often invent the materials or methods we use for construction. While I would not spend lots of time documenting new architectures in excruciating detail, down to the methods, you should at least know what components are needed at a high level and how those components will interact with each other.

#4 Utilize Dynamic Linking/Service-Orientation

Take advantage of technologies like (gulp) COM (if you want to punish yourself), lazy loading assemblies in .NET and Java, dynamically linked .dll and .so libraries, and dependency injection, to “componentize” pieces of your architecture. Composite applications have highly extensible architectures.

#5 Write, Factor, Refactor

Write your code, factor your code, and refactor your code. If you are working on important code and you write it without refactoring it at least once or twice before checking it in, you are not done.

#6 Test for Reuse

Creating unit tests that test your methods and components in isolation (using mocks) will allow you to update your code over time, generalizing it, while making sure that you don’t break prior functionality. Make creating unit tests part of your process and strategy for creating reusable software.

I am sure there are many more items that we can include in this list to make sure that you are thinking about reuse while writing your code. I am convinced that when you get into the habit of writing code, factoring your code, refactoring it, and then making sure it has kept organized, you will develop a mind for reuse without giving it much thought at all.

Creating reusable solutions makes it possible for your stakeholders, Sales and Marketing and/or your customers for example, to find new and innovative ways to profit from your hard work!