Mythical Man-Month: Code Reuse and Discoverability
January 7, 2012
Fifth and final installment in a series. "The best way to attack the essence of building software," Dr. Brooks writes, "is not to build it at all." (p222). With this he introduces a brief discussion of the importance of code reuse, and of its challenges.
Building software for reuse is expensive: it requires greater attention to architecture and more hardening. Perhaps more importantly, it is difficult to user and learn. Code intended for general use often must be more flexible, with a greater number of parameters, which makes it harder to understand. The biggest problem of all I call discoverability; that is, how does anyone know what code is available for reuse?
There are many tools and methods available to help software developers today. Brooks himself refers to the power of object orientation, inheritance and polymorphism for enabling reuse. Refactoring, combined with a complete set of automated unit tests, should significantly reduce the up-front cost of developing for reusability. Language features such as Generics and Anonymous Delegate allow for a great deal of flexibility in reusable code.
Static code analysis tools can help spot common flaws in security, design, naming, and more – thereby helping to improve not only the maintainability but also the discovery of functionality. For the .Net developer, Pex's automatic discovery of unhandled exceptions can do much to improve, quickly, the code hardening efforts.
XML code comments, which can be enforced in static analysis, are quite helpful in explaining the purpose of a class and its methods. Brooks mentions the importance of code samples, beyond general documentation, for explaining complex reusable code. These can be embedded in the Remarks section of an XML comment. For the .Net developer, these comments can be compiled into web pages using Sandcastle. Load these pages into IIS. Perhaps configure a search engine. Take a suggestion from Brooks by publishing a weekly summary of the new/updated documentation.
FFor all that, the human touch is probably the most potent approach; peer review and pair programming provide ample opportunity for sharing about available components and modules.
With all these advantages today, the only excuse for not building your code to be reusable is that you know it won't be reused. In that case, don't waste your time. Refactor later if you were wrong.
TrackBack URL: http://www.safnet.com/fcgi-bin/mt/mt-tb.cgi/59