Over the years I’ve had to revisit or work on software projects created by other developers. Outside of an effective test suite, there four things that I really appreciate when work in a codebase that I am not familiar with:
# Good Build Documentation
# Extensive Logging
# Support for Localization
# Configurability
Good Build Documentation
Nothing is more frustrating than spending hours figuring out how to setup a development environment _just_ so to get the application to run. Modern frameworks provide quite a bit of built-in automation for setting up an application. However, it is still useful to provide insight into what commands need to be run to set it up. Moreover, if there are external dependencies that are not built in into any command (databases, language, third-party tools, etc.), it’s nice to call those out explicitly in the README.
Extensive Logging
Good logging will provide a ton of insight into any issues or unexpected behavior that may arise in an application. It will save a ton of time when trying to diagnose an error that is occurring on a customer installation as well. The customer will also appreciate that you had the foresight to build these tools into their product. This way, when something bad _does_ happen (and it always does), you’ll be able to act on the issue quickly because of the logging.
Support for Localization
Adding support for localization (multiple languages) is easy to do in most modern application frameworks. It’s usually a good idea to start off on the right foot by building in support for localization from the very beginning. This is especially true if the product you are working on is going to be for a company that serves customers in multiple countries. It will save a future developer (which could be you) a ton of time and effort when the customer decides to add support for a new language.
Configurability
This is a new one I’ve added to my list after seeing the benefits of it on a project where I experimented on making it highly configurable. If an application has a number of different behaviors that could potentially be tweaked, I recommend making them configurable. It doesn’t have to be an expensive solution; these options could simply be stored in a file on disk. By making certain aspects of the application configurable, it makes it easy to tweak certain variables to test out new behavior or adapt for use cases you didn’t foresee when the project first started.