我心中的应用框架
今天在infoQ看到一批文章，题为《代码重用的价值被严重高估？》。文中介绍了一篇Dennis Forbes写的一篇很有争议的关于代码重用的旧文章。通过infoQ中文版的介绍，当然内容已经是转过三手的了，先是有人发到英文infoQ，再有国内的热心人士翻译成中文。所以我看了infoQ上的介绍后还是到Dennis Forbes的主页上阅读了他的原版文章《Internal Code Reuse Considered Dangerous》。
Dennis Forbes在他的文章中指出的在实际开发中代码重用的实际价值并没有人们期望的那么高，不好的重用甚至影响开发。但他并不是想表达不需要代码重用，而是想提醒人们，对于代码重用需要谨慎考虑。
应用框架是代码重用的一个重要体现，但是就像Dennis Forbes文章中说的不好的代码重用会让你变得，积累的代码越多，你就越不能脱离现有开发人员，新的开发人员也变得难以上手，特别是在缺乏文档的情况下。 这些正好和我最近对应用框架的思考有些吻合。
在我心中好的应用框架应该具备几点：
- 易用
- 文档完备
- 高质量
- 足够的伸缩性
Ruby on Rails是“易用”这一点上表现最突出的，我想这也是它成功的重要原因。Rails框架有一个脚手架(Scaffold)概念，Rails能帮你针对表结构生成一个Scaffold，它包括了Model, View, Controller, Unit Test等等，生成完就直接可以对表做GRUD操作。这个自动生成的Scaffold通常和实际需要差别很大，但是它让新手可以知道他可以从哪些地方入手，有哪些事情要做，并且马上可以看到框架的命名约束。
Rails的文档也很全面，不过我没有在它的文档上有什么特别的感受。我觉得从Rails身上学到的最重要的东西就是“脚手架”概念。其实看看国外比较成功的开源项目都是文档比较完备的。
一个好的应用框架应该保证自己的质量，有足够的单元测试，性能方面应该也有必要的测试数据。才能保证基于这个框架的产品的质量。不管是做内部应用框架还是开源的应用框架，我觉得都应该是如此。
文档和单元测试是降低对现有开发人员依赖的很重要方式。降低对现有开发人员的依赖不是说让公司想踢人就踢人。从公司角度考虑团队难免出现人员流动，所以开发任务需要可以快速转接，这时候完整的文档是很必要的。
伸缩性包括模块的可分裁剪性，还有可扩展性。我觉得应用框架不应该强迫别人实用它的所有功能，一个应用框架通常有了很多内容，应用框架的设计应该要可以支持实用者只实用其中的一小部分，并让使用者可以扩展自己的实现。
我发现国内的开发人员设计的框架都有一个特点，都很少考虑到扩展第三方实现，包括我较早的一些设计也是同样的毛病。比如我觉得你的应用框架的日志管理模块很好，但数据操作模块不是我习惯的方式，或者执行效率不能让人满意，这时候我要单独用日志管理模块就会出现一定要使用特点数据操作模块的局面。这样就让应用框架的灵活性大大降低了。
以上只是个人的一些小看法，欢迎拍砖 :-)