回复fireflyc：Nutz 的设计以及提高程序员生产力
程序员文章站
2022-03-01 15:37:56
...
@fireflyc 在 晓风的这篇博文 的回复，引起了我的一些思考，考虑到内容较多，就单独写成一篇博客吧：
-------------------下面是正文的分隔线-----------------------------------
那么我也聊一下 Nutz 这个框架的设计思想，或者叫做“精神”，或者随便怎么叫它。
我希望 Nutz 是你一个乖巧的奴仆
并且它不是你唯一的奴仆
Nutz 框架对使用者的态度
不是：
“要这样编程序！”
而是：
“我能为你做些什么？”
它存在的意义是想努力帮大家处理一些编程工作中很烦琐的问题。
它对自己的最低要求就是：“不招人讨厌”
它努力的在理解现在的程序员主人真正喜欢什么，又讨厌什么
比如 ORM：
为什么大家用 ORM 呢？因为大多数人都讨厌拼 SQL，很麻烦。但是有时候又不得不用一下 SQL。所以 ORM 对大多数程序员主人的最大的意义(虽然不是唯一的)就是：
因此 Nutz.Dao 就替你拼 SQL。 实际上，它是 Hibernate 和 iBatis 的一个折中。
它可以支持你随便怎么写自己的 SQL，也可以根据一个对象，替你拼出 SQL
但是
它仅此而已。
至于分页，条件查询什么的，则是顺理成章的事。
比如 Ioc
Ioc 的意义就是
我发现有很多程序员其实不习惯 Ioc 方式。
有些经验的人，拥有自己的解耦方式。
当然更多的人喜欢 Ioc 的方式，他们使用 Spring 。
Spring 的 XML 配置语法过于繁琐，而新的基于Java注解的 Ioc 框架（比如 Guice），实际上就是把耦合写在另外的一堆 Java 文件里，并且部署后似乎很难修改。
所以 Nutz.Ioc 默认选用了 JSON，（又是一个折中：书写不麻烦，但是部署以后可以随时修改）
当然，它也支持你把耦合写成任何样子，如 XML，甚至数据库，扩展它一个接口就可以了。
关于这一点， 这里有详细的描述: http://code.google.com/p/nutz/wiki/ioc_ioc_loader
比如 Mvc
至于Mvc，其实什么要放到 M 里边，什么要做成是 V，哪一个又需要写成 C，程序员主人们的理解都有或多或少的偏差。但是无论如何，他们最起码需要做的就是：
Nutz.Mvc 力图做到刚刚够用，只负责粘合 M-V-C， 关于权限，日志，验证，UI 组件的支持统统没有。
同时也不限制你的扩展，比如模板引擎，比如要想支持 freemarker， 添加起支持来很自然。
它努力让配置，约定的形式最自然
比如 Nutz.Dao 中的各种注解， 比如 Nutz.Ioc 的 JSON 配置文件语法。
基本上，现在还没有人抱怨它们很难懂。-- 当然现在 Nutz 使用的人很少也是一个主要原因。
我们还在不断聆听来自各方的抱怨，我们对于批评，尤其是具体的批评，是很饥渴的。
说点形而上的东西
对于现有工具和框架进行改良我是支持的，但是“改良”是一种手段，不是我们追求的目的，不是吗？
Nutz 追求的是让它的程序员主人们最大限度的少写代码：
这些在我们看来，都是有很有意义的
所以 Nutz 的任何设计，都会考虑到是不是能利用程序员主人现有的知识。
它只假设你熟悉 JAVA，SQL 和 Tomcat。
因为我们的工作要能变得轻松一些，
当市场让老板让我们修改一些代码时，我们不用加班，加班很毁身体。
而且我们也知道如何修改，
因为我们的工具很简单，它让我很容易摆弄，我总能让它服服帖帖的干活，
虽然我们只会 JAVA，SQL 和 Tomcat 的配置
当然 Nutz 不能帮你做到这一点，它不是“银弹”，甚至它是不是“银色的”的都是个问题。
但是起码我希望它能 “在你构思你的项目时，不会是你的另外的一个问题”。
你不会说，我要维护 XXX 的配置文件，我要维护 XXX 的支持类，好累啊。
我不希望它成为程序员主人们的另一个负担，
程序员主人们对待这个框架不需要小心翼翼的，不需要学习很多约定和规则。
我希望使用它不会为你增加工作量，相反，在很多时候，我希望它会帮你降低一点点工作量。
能做到这点我就很满足了。
如果通过改良 SSH 能做到这一点，我当然很高兴，因为能省了不少事。
但是真的能吗？
能做的彻底吗？
SSH 是头几年的设计，在它们发布之初，的确蕴含着很多创新的思想。
但是现在呢？
我想，你已经不会脱口而出的说：“扯淡！SSH 无懈可击！”，其实，很多人都不会，大家只能说：“SSH 真是好强大哟~~~”
我希望一个工具或者框架能够做到：
至于它强大不强大，干我屁事。
所以，Nutz 也不是大框架，它当然不是，它很小。我很同意你 “不走大框架的路” 和 “提高工作效率” 的观点。
但是关于 “a,一个开发框架，注重实用”
什么样的开发框架呢？
什么叫“实用”呢？
我想你给出的答案是: “一组基于 SSH 的编码约定”
而springside 的答案似乎是: “一组代码例子”
这里的问题在于，你只能完善 SSH，而不能让它有本质上的提升。 Spring 团队可能不会为你做太多修改。
Spring 团队总是有很多伟大的思路
因此，他们很可能干脆不理你。
那么，这会不会限制你呢？
这会不会导致：如果你有更好的主意，可以提高程序员的生产力，有些时候不得不“曲线救国”。
不过我想，努力做出些东西，让程序员的效率变高，应该是你和我的一个共识
实际上它也是大多数程序员的共识。
而我，希望 Nutz 能成为你所说的 “a,一个开发框架，注重实用”
-------------------下面是正文的分隔线-----------------------------------
那么我也聊一下 Nutz 这个框架的设计思想，或者叫做“精神”，或者随便怎么叫它。
我希望 Nutz 是你一个乖巧的奴仆
并且它不是你唯一的奴仆
Nutz 框架对使用者的态度
不是：
“要这样编程序！”
而是：
“我能为你做些什么？”
它存在的意义是想努力帮大家处理一些编程工作中很烦琐的问题。
它对自己的最低要求就是：“不招人讨厌”
它努力的在理解现在的程序员主人真正喜欢什么，又讨厌什么
比如 ORM：
为什么大家用 ORM 呢？因为大多数人都讨厌拼 SQL，很麻烦。但是有时候又不得不用一下 SQL。所以 ORM 对大多数程序员主人的最大的意义(虽然不是唯一的)就是：
省却了拼装 SQL 的烦恼
因此 Nutz.Dao 就替你拼 SQL。 实际上，它是 Hibernate 和 iBatis 的一个折中。
它可以支持你随便怎么写自己的 SQL，也可以根据一个对象，替你拼出 SQL
但是
它仅此而已。
至于分页，条件查询什么的，则是顺理成章的事。
比如 Ioc
Ioc 的意义就是
解耦
我发现有很多程序员其实不习惯 Ioc 方式。
有些经验的人，拥有自己的解耦方式。
当然更多的人喜欢 Ioc 的方式，他们使用 Spring 。
Spring 的 XML 配置语法过于繁琐，而新的基于Java注解的 Ioc 框架（比如 Guice），实际上就是把耦合写在另外的一堆 Java 文件里，并且部署后似乎很难修改。
所以 Nutz.Ioc 默认选用了 JSON，（又是一个折中：书写不麻烦，但是部署以后可以随时修改）
当然，它也支持你把耦合写成任何样子，如 XML，甚至数据库，扩展它一个接口就可以了。
关于这一点， 这里有详细的描述: http://code.google.com/p/nutz/wiki/ioc_ioc_loader
比如 Mvc
至于Mvc，其实什么要放到 M 里边，什么要做成是 V，哪一个又需要写成 C，程序员主人们的理解都有或多或少的偏差。但是无论如何，他们最起码需要做的就是：
HTTP 与 Java 之间映射
Nutz.Mvc 力图做到刚刚够用，只负责粘合 M-V-C， 关于权限，日志，验证，UI 组件的支持统统没有。
同时也不限制你的扩展，比如模板引擎，比如要想支持 freemarker， 添加起支持来很自然。
它努力让配置，约定的形式最自然
比如 Nutz.Dao 中的各种注解， 比如 Nutz.Ioc 的 JSON 配置文件语法。
基本上，现在还没有人抱怨它们很难懂。-- 当然现在 Nutz 使用的人很少也是一个主要原因。
我们还在不断聆听来自各方的抱怨，我们对于批评，尤其是具体的批评，是很饥渴的。
说点形而上的东西
对于现有工具和框架进行改良我是支持的，但是“改良”是一种手段，不是我们追求的目的，不是吗？
Nutz 追求的是让它的程序员主人们最大限度的少写代码：
- 可以让程序员主人少写一行代码
- 可以让程序员主人少读一段文档
- 可以让程序员主人少理解一个概念
- 可以让程序员主人少知道一个约定
这些在我们看来，都是有很有意义的
所以 Nutz 的任何设计，都会考虑到是不是能利用程序员主人现有的知识。
它只假设你熟悉 JAVA，SQL 和 Tomcat。
因为我们的工作要能变得轻松一些，
当市场让老板让我们修改一些代码时，我们不用加班，加班很毁身体。
而且我们也知道如何修改，
因为我们的工具很简单，它让我很容易摆弄，我总能让它服服帖帖的干活，
虽然我们只会 JAVA，SQL 和 Tomcat 的配置
当然 Nutz 不能帮你做到这一点，它不是“银弹”，甚至它是不是“银色的”的都是个问题。
但是起码我希望它能 “在你构思你的项目时，不会是你的另外的一个问题”。
你不会说，我要维护 XXX 的配置文件，我要维护 XXX 的支持类，好累啊。
我不希望它成为程序员主人们的另一个负担，
程序员主人们对待这个框架不需要小心翼翼的，不需要学习很多约定和规则。
我希望使用它不会为你增加工作量，相反，在很多时候，我希望它会帮你降低一点点工作量。
能做到这点我就很满足了。
如果通过改良 SSH 能做到这一点，我当然很高兴，因为能省了不少事。
但是真的能吗？
能做的彻底吗？
SSH 是头几年的设计，在它们发布之初，的确蕴含着很多创新的思想。
但是现在呢？
我想，你已经不会脱口而出的说：“扯淡！SSH 无懈可击！”，其实，很多人都不会，大家只能说：“SSH 真是好强大哟~~~”
我希望一个工具或者框架能够做到：
- 替我做的，做到最好
- 不替我做的，别挡我的路
至于它强大不强大，干我屁事。
所以，Nutz 也不是大框架，它当然不是，它很小。我很同意你 “不走大框架的路” 和 “提高工作效率” 的观点。
但是关于 “a,一个开发框架，注重实用”
什么样的开发框架呢？
什么叫“实用”呢？
我想你给出的答案是: “一组基于 SSH 的编码约定”
而springside 的答案似乎是: “一组代码例子”
这里的问题在于，你只能完善 SSH，而不能让它有本质上的提升。 Spring 团队可能不会为你做太多修改。
Spring 团队总是有很多伟大的思路
因此，他们很可能干脆不理你。
那么，这会不会限制你呢？
这会不会导致：如果你有更好的主意，可以提高程序员的生产力，有些时候不得不“曲线救国”。
不过我想，努力做出些东西，让程序员的效率变高，应该是你和我的一个共识
实际上它也是大多数程序员的共识。
而我，希望 Nutz 能成为你所说的 “a,一个开发框架，注重实用”