Fast moving teams don’t have the time to make the same mistake twice

(Before you read this, “Effective partnerships” provides context)

Some APIs are hard to use correctly. Imagine that you’ve just been bitten by an API that is hard to use correctly. You might look for a module that presents a simpler, safer interface that does what you want. If you don’t find one, you might write one.

Awesome! But now you’ve got a problem. Other people on your team might have the same problem. You can send an email and let people know. But what if your team is rapidly growing? Every new team member shouldn’t have to read over old emails to avoid your problem.

It’d be nice to have a way to recognize new uses of problematic APIs and guide developers away from them. If there’s someone in your organization who understands how to use the APIs properly, pointing devs towards them can help bring different peoples’ strengths to bear.

Linter rules can help in some cases. The attack review testbed adds another tool that prevents some sensitive modules from being require()d except by modules on a list. When that happens, it prints a message that can explain alternatives and how to get extra help, or get uses approved.

Mechanisms that steer developers away from problematic APIs increase the value developers invest in creating safe, reliable abstractions.

By putting this information in a configuration file, the developer can always add their use, finish developing the feature, and provide a PR that shows the feature enabled by allowing use of the risky API.

Later I’ll talk about how to make sure that the right reviewers see
changes to sensitive files like the configuration file and code that
builds safe abstractions on top of unsafe APIs.