开源项目如果应用在实际工程了，被人诟病最多的就是两点，第一是代码的品质，第二就是文档不够丰富。除非一些流行的明星框架，其他的新生小框架基本根本没有足够的人力写作庞大的文档。这些问题在我设计Nutz 的时候就意识到了。

针对文档的问题，我想没有别的办法，自己一行一行的写呗。但是真的没有办法吗？ 请大家想一想，Hibernate，2.7 M，Nutz 400多K，针对一个 2.7M 的东西写出的文档想必要比针对 400多K的东西要多吧？是的，在一开始我尽量控制代码体积的努力，开始回报我了。并且，纯粹的 Nutz.Dao （不包括 Mvc 和 Ioc) 甚至更小，只有 234K。剩下的问题就是时间了，我会逐渐丰富 Nutz 各个部分的文档，搭建 Wiki，办一个专有的社区，发布 API 详细的文档，这些都已经加在我的时间表里了。平日里，我思考最多的事情就是如何让我把这些事情做得更加有效率。

针对代码的品质，截至到现在为止，Nutz 一共通过了225 个JUnit 测试。在一个功能告一段落以后，我通常会花1－2个晚上在一边咂着廉价的红酒一边颇有成就感的书写JUnit测试。通常我会用 JUnit 把我自己击溃，紧接着的那几天我都努力让那个该死红条变绿，之后，又想方设法写出新的Junit测试试图让它再度变红。并且我还要保证所做的修改不能让代码膨胀，这的确让我死掉了不少脑细胞。这些测试中，不仅涵盖各种功能上的测试，也涵盖了一些跨越线程的测试。在以后，我会针对代码执行的效率加入一些新的测试。

我能保证的就是Nutz的代码是小巧的，以及通过尽可能多的 JUnit 测试。但是所有我能做的也就只是这些了，找出剩下的那些代码上的缺陷，就应该交给 Nutz 第一批“小白 ”们了。“小白”们，加油！我支持你们...