Use third-party code
Sometimes when we use third-party packages or open source code, or rely on code from other teams in the company, we have to cleanly integrate it into our own code. In plain English, it is more appropriate to add a layer of encapsulation to use these third-party libraries for your own business.
Learning test
Learning tests cost nothing. We had to learn the API to use anyway, and writing tests was an easy way to get that knowledge without affecting the rest of our work. Learning tests are precision tests that help us improve our understanding of the API.
Whether or not you need to learn by learning tests, there should always be a set of output tests that are called in the same way as in production code to support clean boundaries. Without using these boundary tests to ease the labor of migration, we might be tied to the old version longer than it should be.
Use code that does not yet exist
There’s another kind of boundary, the one that separates the known from the unknown. There are always places in the code that are beyond our knowledge. Sometimes, that side of the border is unknown. Sometimes we don’t look over the border.
In my opinion, this non-existent code is like the mock data we use, using code that does not yet exist to simulate data that does not yet exist. The simulation API code mentioned in the book is the same, the API has not been developed, but it can not affect our development schedule, so we can define the interface we want first. If the third party is ok, we will dock again.
Clean boundaries
Interesting things happen at the border. Modification is one of them.
Good software design that can be modified without heavy investment and rewriting. When working with code that we can’t control, we have to be extra careful to protect our investment and make sure that future changes aren’t too costly.
The code on the boundary needs to be clearly segmented and defined with the desired tests. Our code should be kept from knowing too much about specific information in third-party code.