When creating a new app module, or modularising an existing one, it becomes easy to forget who might be consuming it. It becomes easy to forget that every decision you make will affect how it is used, or in the worst case, abused. We’re told that code should document itself, but how do these design decisions reflect in the understanding of intended use?
Just because we might not be exposing a module as a public or open-sourced library, doesn’t mean we can’t benefit from making good decisions towards an effective and sensible API. By taking the stance that every piece of code we write is an API we can build more versatile and scalable applications.
In this talk, I’ll discuss how you can apply best practices from the open-source world to your project, to guard implementations, provide concise and specific contracts, practical documentation mechanisms, and how doing so can aid (or harm) your build time.