As your teams add real functionality to their stub code, they will discover that one interface needs an extra variable passed in or that another interface was missed entirely. You can add this functionality at any time. When you make these changes, publicize them so that other teams that use the same interfaces won’t be surprised. If need be, just add a new interface with the extra variable instead of pulling one out from under another team. Remember that you never break the builds in a tracer bullet project. Any code that you add should extend the system, not break it. You will also realize at some point that code you’ve written needs to be thrown out. Maybe the code is too slow or it returns the wrong results. Any one of a thousand things may be wrong with it. Feel free to completely refactor or rewrite code, as long as the interface still works the same way. You can make these changes at any time in a Tracer Bullet Development project. The rule is that you can’t change the interface that the other teams use without consent, but you can change the code behind those routines at will. As long as the interface works the same way, the other teams won’t be aware that you’ve changed the code. Their code should still use your interface the same way, only now it runs faster or returns the correct data.
Tip 23: An encapsulated architecture is a scalable architecture
I'm thinking that the term "scalable" refers to the number of developers that can productively work on a system, not how much additional load it can handle. If the touch points are well defined you can have one or many developers working on a layer and the other parts of the system won't know or care.
No comments:
Post a Comment