| |
Unix Programming - Basics of the Unix Philosophy - Rule of Extensibility: Design for the future, because it
Rule of Extensibility: Design for the future, because it
will be here sooner than you think.
If it is unwise to trust other people's claims for “one
true way”, it's even more foolish to believe them about your
own designs. Never assume you have the final answer. Therefore,
leave room for your data formats and code to grow; otherwise, you
will often find that you are locked into unwise early choices because
you cannot change them while maintaining backward compatibility.
When you design protocols or file formats, make them sufficiently
self-describing to be extensible. Always,
always
either include a version number, or compose the format from
self-contained, self-describing clauses in such a way that new clauses
can be readily added and old ones dropped without confusing
format-reading code. Unix experience tells us that the marginal
extra overhead of making data layouts self-describing is paid back
a thousandfold by the ability to evolve them forward without
breaking things.
When you design code, organize it so future developers
will be able to plug new functions into the architecture without
having to scrap and rebuild the
architecture.
This rule is not a license to add features you don't yet need; it's
advice to write your code so that adding features later when you
do
need them is easy.
Make the joints flexible, and put “If you ever need
to...” comments in your code. You owe this grace to people who
will use and maintain your code after you.
You'll be there in the future too, maintaining code you may have
half forgotten under the press of more recent projects. When you
design for the future, the sanity you save may be your own.
[an error occurred while processing this directive]
|
|
