Most of developers spend most of time on developing applications rather than writing libraries. However, writing a library used by multiple applications is quite different than developing an application. When working on a library, there are many challenging topics that developers will not contemplate compared to applications. Here is a couple of examples:

Dependencies

Writing a library is a good way to force yourself to think about dependencies. Let us take logging for example. When creating an application, you may add your (or your organization’s) favorite logging framework to your project without blinking an eye. But when creating a library, you are not allowed to do that because library users may have their already-used logging framework.

Same principle is applicable to any kind of dependencies. There are couples of design pattern that can help the issue such as Factory Pattern and Dependency Injection. Think twice before you adding them to your project.

Awareness of Breaking Change

This is also something that unlikely happens in application development. Changing the type of a method’s return value from string to integer in your own application is not really a big deal. But for libraries, you are unable to foresee how great the impact will be because their applications are not under your control.

Breaking changes usually come out with migration guide. But in any situation, a library author should avoid breaking changes as much as possible. Even if the breaking changes are inevitable, they should only appear in major release. This forces you to think what should be and what should not be exposed to your library users to ensure that refactoring, bug fixes, performance improvement can be done without affecting library users.

Exception Throwing

Because library users are not easy to know what is happening under the hood, your library should be able to provide error information as clear as possible — as long as it does not violate best practices of security. As a service or application, the error information usually only tells the caller that something is wrong as well as error code because of security concern. But as a library, the exception message should not only tell something is wrong, but also tell where or how to debug the error.

Simply put, the main difference between the error messages coming from library level and service/application level is debugging information. Working on libraries will make you think what exceptions are helpful for your library users to debug.

Conclusion

There are still many topics that are not mentioned in this short article. But in any case, working on libraries (especially open source libraries, I highly recommend you to take a look at how the popular libraries in the world are made on GitHub) will force you to deal with them. And during the process, your skill will be sharpened and bring benefits to any kind of development.