RoR背后的软件开发方法学思考

是的，使用RoR肯定需要新的软件开发方法论来指导，但是这一点尚且需要更多实践项目的探索才能有更进一步的想法。这不像单纯钻研技术，看看文档，写写code观点就可以出来的。


不过从更加宏观的角度来说，RoR需要你采用一种完全不同的开发软件的思路和方式，也就是ozzzzzz说的方法论吧。例如在我们开发JavaEye2.0网站之前就确定了一些原则，这些思路和传统软件思路完全不同，例如：

1、传统软件要求明确需求之后再开发，而我们只有一个大致的想法就开始把原型做出来

2、传统软件要做出来之后，内部测试，才会正式发布，用户才会接触到，而我们还没有开始之前，就开始放风说一个月后新网站上线，把用户参与的时间点提前到了软件开发之前

3、传统软件采用封闭开发，而我们从有想法，到设计原型，一步一步开发，测试，上线所有步骤全程网络直接和用户实时交流

4、传统软件要没有bug才推出，而我们是抢先推出，让用户来反馈bug。

使用RoR是从技术上确保了我们这种开发软件思路能够顺利执行下来，但是这种做软件的思路是从成功的web2.0网站开发和运营的经验借鉴过来的，具体来说我是受了37signals的《Getting Real》的影响才决定这样去做的。

RoR这两年这么流行，其实也不单纯是技术的原因，更加主要的是RoR顺应了互联网Web2.0软件开发的需要：敏捷，快速反馈，用户参与。当然我们也有一些创新的做法，例如把用户反馈提前到软件还没有开发之前。

其实企业应用软件开发未来几年的主旋律也无非就是：敏捷，快速开发，用户参与，再加上一个异构系统整合而已。因此RoR的流行深层次的原因可能是一种应用软件行业开发方法的变迁。

就这个话题我已经准备在12月1日的中国软件大会上讲一个topic了，到时候希望得到更多探讨和交流。

评论

2 楼 helloworld 2006-12-29  

让用户反馈bug对很多团队是很难做到的。开发城市的客户可能会更理解软件开发工作的特点。大部分用户在每反馈一个bug时，你项目验收的难度就会增加一点。他会对你开发的东西失去信心，以致于怀疑一切。但是我从技术角度赞同你的观点，而非技术人员，你的上司，客户和业务代表就很难做到。
我们做软件时一般采用2次开发法，根据用户的需求迅速推出一个东西让部分用户用1个月左右，然后1个月内跟踪用户的需求，再推出第二个版本，也就是验收版本。当然事先要和用户说清楚，第一个东西是用来交流需求用的，不是最终的产品。

1 楼 iceskysl 2006-11-07  

不能不说《Getting Real》是个好东西，使我们明白，现阶段什么是根本，抓住中心，才能跟上变化。。
敏捷越来越重要，现在只有在 电信行业 还可以按照原来的模式来开发，赶进度的话就只能是加班拼时间，没有一个模式的改变，所以速度和效率都比较低下。。