Transparency as the Key to Reuse

Prev  Chapter�燫euse Next

Transparency as the Key to Reuse

广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元

We field-tested the tale of J. Random Newbie on a number of experienced programmers. If you the reader are one yourself, we expect you responded to it much as they did: with groans of recognition. If you are not a programmer but you manage programmers, we sincerely hope you found it enlightening. The tale is intended to illustrate the ways in which different levels of pressure against reuse reinforce each other to create a magnitude of problem not linearly predictable from any individual cause.

So accustomed are most of us to the background assumptions of the software industry that it can take considerable mental effort before the primary causes of this problem can be separated from the accidents of narrative. But they are not, in the end, very complex.

At the bottom of most of J. Random Newbie's troubles (and the large-scale quality problems they imply) is transparency — or, rather, the lack of it. You can't fix what you can't see inside. In fact, for any software with a nontrivial API, you can't even properly use what you can't see inside. Documentation is inadequate not merely in practice but in principle; it cannot convey all the nuances that the code embodies.

In Chapter�a>, we observed how central transparency is to good software. Object-code-only components destroy the transparency of a software system, On the other hand, the frustrations of code reuse are far less likely to bite when the code you are attempting to reuse is available for reading and modification. Well-commented source code is its own documentation. Bugs in source code can be fixed. Source can be instrumented and compiled for debugging to make probing its behavior in obscure cases easier. And if you need to change its behavior, you can do that.

There is another vital reason to demand source code. A lesson Unix programmers have learned through decades of constant change is that source code lasts, object code doesn't. Hardware platforms change, service components like support libraries change, the operating system grows new APIs and deprecates old ones. Everything changes — but opaque binary executables cannot adapt to change. They are brittle, cannot be reliably forward-ported, and have to be supported with increasingly thick and error-prone layers of emulation code. They lock users into the assumptions of the people who built them. You need source because, even if you have neither the intention nor the need to change the software, you will have to rebuild it in new environments to keep it running.

The importance of transparency and the code-legacy problem are reasons that you should require the code you reuse to be open to inspection and modification.[140] It is not a complete argument for what is now called ‘open source’; because ‘open source’ has rather stronger implications than simply requiring code to be transparent and visible.

 

[140] NASA, which consciously builds software intended to have a service life of decades, has learned to insist on source-code availability for all space avionics software.

 

 

 

Prev  Up Next

The Tale of J. Random Newbie  Home 燜rom Reuse to Open Source