关于技术框架对软件开发过程影响的讨论

Java生成UML来读，但凡大一点的框架软件，UML图又大又复杂，根本看不出来头绪，这是不切实际的做法。

TextMate，Radrails，VIM对于编程的导航都很不错。但这不是最重要的。最重要的是rails项目的结构非常固定，每个文件也不大，该写什么不该写什么，框架都框死了。维护的人其实很容易的，他只要熟悉rails，根本不看代码就知道哪部分代码应该在哪里，哪部分功能在什么地方实现。这是rails相对于Java来说的一个很大的优势。使用Java，倘若你接手的项目使用的框架你没有接触过，那根本无从下手，即使大家使用同样的框架，但是自己进行了高层的不同方式的封装，你想看出来头绪，仍然要费很大的力气，但对于rails来说，不存在这些问题。

如果大家不信，我随便举两个例子。首先对比一下Java的开源博客软件roller，这是用struts/hibernate开发的，如果你能在一周之内彻底搞清楚roller的全部结构，那我得承认你的Java编程水平在我之上；再看看rails的开源博客软件typo，我半天就可以把typo全部代码实现细节全部都搞得清清楚楚。再来对比Java的开源论坛软件JavaBB，这个简单一些，但是结构也有一定复杂度，然后再对比rails开源论坛软件rforum，哪个容易阅读，哪个更加容易维护，这是昭然若揭的事实。

所以，rails开发的项目要远比Java开发项目好维护，特别你招聘新员工来进行维护，两者差距拉得更大。

其实你说的正好相反，只要你不要太炫耀ruby的技巧，代码都是很好阅读的。rails编程为什么没有那么多模式和最佳实践，是因为rails已经把模式和最佳实践做在框架里面了，已经全副武装了，你直接拿来就用了。反而是Java，就算有了Spring/Hibernate/Webwork照样是在裸奔，没有代码生成机制，没有单元测试框架，没有测试数据设施，没有RESTFul URL机制，没有DB Migration，没有AJAX集成，没有实现好的分页机制，没有做好的Mock对象，没有现成的页面模板和装饰器，一切都要靠自己。

我觉得这还是因为着眼不同。如果是Rails应用，真的是没有什么好说的，你讲的都对。但是泛泛讲Ruby程序，就不是那么回事了。比方说RubyOnRails本身的源码，你觉得比Struts之类的好读吗？

Oh that is good. A non-programmer friend of mine once said “it looks like poetry” when I showed him a Ruby DSL. There is hope for mankind, yet

robbin已经讲的很清楚了。补充一个
Natural language DSL in Ruby
http://drnicwilliams.com/2006/09/04/trick-natural-language-dsl/