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

我们公司是一个大概20多人的小软件公司。之前一直是做基于j2ee的BS结构的项目。在整个项目开发过程中，要求大概如下这些文档： 构架设计，需求大纲，需求说明书，概要设计，详细设计，测试用例，部署文档，用户手册等。

我想问的是，如果是在RoR框架下，整个开发过程会不会和传统的J2ee框架有比较大的变化？是不是还需要上面那些文档？

那些个文档还没写出一半，功能就已经完成了，你说有没有变化？

我担心，如果没有完整的文档，会不会对后期维护造成很大的麻烦？比如更换了技术人员之后，维护人员可能会不清楚具体的需求或者实现方式。

source code is documentation

ruby语法如此灵活，会不会对接手维护的人员造成比较大的困难？

我相信会在一定程度上造成影响。
不过你们可以采取Ruby常用的规范和模式来写程序，这样大家的习惯比较一致，维护性就好一些。

我这是凭感觉随便说的，仅供参考。

你问的是两个方面的问题，一个是语言平台的选择，一个是开发流程的选择。

source code is document是agile开发所提倡的。j2ee也可以做到，当然ror更直观些。比如
1. model design：那就是app/models目录里的文件，如果你用migration，那么db/migrate目录更能说明问题，还包括每个model的attributes。写个全的model design文档也就这些内容
2. overall design：app目录里分的很清楚的m/v/c三个目录不就是个overall design嘛。
3. design design：当然就在每一个source文件里。
4. build doc: rake文件可以当作build doc。ruby语言的可读性很强，读下来就知道他在做什么了。
5. user manual：这个可能没法省，但实际上会去看user manual的用户不多，特别是如果你的应用做的没有歧义，没有误操作的可能，那么user manual都在界面上了。
6. testcases & requirement spec：testcases你知道我肯定要说ror里嵌入的unit test和funtional test。没错，那些都可以作为test cases的文档，一条case是一个函数，很清楚。我还要说另外一个插件rspec on rails，可以用来写一套读起来更像requirement spec的testcases。这是一个基于Behavior Driven Development思想的ror实现，很有魅力。我copy一段代码在下面，你看看能不能用来做文档：

require File.dirname(__FILE__) + '/../spec_helper'

context "The PersonController" do
  inherit Test::Unit::TestCase
  fixtures :people
  controller_name :person

  specify "should be a PersonController" do
    controller.should_be_instance_of PersonController
  end

  specify "should create an unsaved person record on GET to create" do
    get 'create'
    response.should_be_success
    response.should_not_be_redirect
    assigns('person').should_be_new_record
  end

  specify "should persist a new person and redirect to index on POST to create" do
    post 'create', {:person => {:name => 'Aslak'}}
    Person.find_by_name('Aslak').should_not_be_nil
    response.should_be_redirect
    response.redirect_url.should_equal 'http://test.host/person'
  end
end

context "Rendering /person" do
  inherit Test::Unit::TestCase
  fixtures :people
  controller_name :person

  setup do
    get 'index'
  end

  specify "should render 'list'" do
    response.should_render :list
  end

  specify "should not render 'index'" do
    lambda {
      response.should_render :index
    }.should_raise
  end

  specify "should find all people on GET to index" do
    get 'index'
    response.should_be_success
    assigns('people').should_equal [people(:lachie)]
  end

  specify "should display the list of people" do
    response.body.should_have_tag :tag => 'p'
  end

  specify "should display the list of people using better api" do
    should_have_tag('p', :content => 'Finds me in app/views/person/list.rhtml')
  end

  specify "should not have any <div> tags" do
    lambda {
      response.body.should_have_tag :tag => 'div'
    }.should_raise
  end

end

写测试

我觉得多少会有的。这个问题我看到几个方面,回答分别是 No, Yes, Maybe
No.
1) Ruby写的程序整体的代码量下来了，需要维护的程序更少
2) 虽然说Ruby语言本身需要理解的地方更多一些，但需要理解的patterns少了
这是Ruby程序好维护的一方面

Yes.
另外一方面，由于语言本身的动态性，Ruby没有强大的IDE。这对接手维护的人来说确实是很头疼的一件事。Java程序你可以生成UML来读，可以很方便地navigate，这些便利在Ruby中享受不到。这是Ruby程序不好维护的一方面。

Maybe.
一个程序好不好维护，还是要看这个程序写得怎么样。用Java比较容易写得好维护，毕竟这么多年的积累有很多的best practice，甚至还从best practice发展出来工具、框架。而Ruby这方面的积累还比较少，没有很多清楚的guideline来帮助你，也没有什么工具可以利用，一切都要靠自己。这种情况下，个人的水平高下比写Java程序更容易凸现出来，对程序好不好维护的影响也就更大。

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对象，没有现成的页面模板和装饰器，一切都要靠自己。