rails项目体验(1)

                          rails项目体验

    在过去的16个月中我的同事们和我一直忙碌于一个比较大的rails项目中。  在经历了无数个加班和n个通宵之后终于看到我们的项目部署在6台IBM服务器上，在过去的一周中项目日渐稳定，这种心情只有经历过的人才能体会到。客户满意，BOSS也即将走出痛苦的泥潭，接下来的是最后的完善和部署到另外14台服务器上。忙碌，压力稍有缓解，准备接下来花一段时间把整个项目中遇到的各种情况，走过的弯路都记录下来，算是一年多来的工作总结，准备发到我的blog中，扩充一下我为数不多的blog数量。
   这个项目是我职业生涯中第一个规模比较大的项目  我个人认为项目的过程是存在很大问题的，这中问题直接导致了项目开发周期如此长，rails的优势也没有显现出来。　如果重新来过，我觉得此项目是有可能在4-6个月内完成的。

 


一 目录

1  项目简介
2  需求
3 技术选型
4 架构和设计
5 详细设计
6 运维
7 rails在项目中的运用心得
  (1) thin view,fat model?
  (2 ) plugin or gems
  (3) paperclip vs filecolumn?
  (4) test?
  (5) state_machine
  (6) 全文检索
  (7) js or frameworks
  (8) 缓存的重要性
  (9) 索引
  (10) 定时任务
(11)view重用


8 数据迁移


(我目前想的目录大概是这么一个结构, 看起来是不是很软件工程。  其实我要表述的都是和rails相关的，上面的大部分都和rails有紧密联系，我想分享的也是关于rails的问题，对于每个部分我想都以项目中遇到的案例说明问题。)






项目简介

我也曾了解过国内其他公司的rails项目。大多都是互联网应用，很多大一点的项目都不会冒这么大风险使用rails来做的。 我们的团队中也有很多rails大牛，在社区中名气很高的。他们无一不认为国内很少有人使用rails来做这种项目的。  我们需要做的是把原来的一套asp系统和jsp以及部分php的改造为rails实现。别的不说，单单数据迁移的工作就够麻烦了。　　客户那边以前系统有 4000+个数据库表(结构不同大概有350+)，好在我们有ruby。　

目前为止项目大概数据如下;

团队规模：２０人+
持续时间：１１　月
model数：300+ (持续增正中，还有些辅助功能没有开发)
controller:250 +



需求

数不清的软件工程和方法学的书籍讲授如果做需求分析，有些是在太老套了。　项目开始的需求就是按照这种老套的方式开展的。需求是人定的，人嬗变，需求自然也便。　项目初期我们大概花了一到两个月所有人都在做这件事情，结果证明这段时间是没有任何用处的，完全浪费,所有的文档也再一次svn故障中消失殆尽。　我们做这件事情是这样的流程，上午所有人，包括开发与qa到客户的各个业务科室了解业务，下午开会互相通报学习，总结成文档于图表。每周开一次全体会议总结需求学习。这样做结果是互相学习不充分，后来开发做需求人员之了解自己那部分，别人的自然是不了解的。另外还有人员流逝也是很严重问题。　需求这面除了浪费我们的那一段时间倒是没有引起更为严重的后果，不至于开发到一半发现程序于需求不符合。　

项目进展到０９年５月份是需求工作的一个转机，客户为了我们方便交流特地为我们预留了几间办公室，这样我们团队就整体搬到了客户处，客户那边有将近１０个程序员，他们虽然对rails不熟悉，可各个都是业务和web开发方面的高手，于是20几个人在同一间屋子里边开发边了解需求。　　那效率简直了。

所以我想如果有条件一定要让直接开发人员和客户保持最紧密联系。　拥抱变化和持续集成这两条原则在我们项目中简直登峰造极了。　　客户要求什么我们就做什么，我们做的结果客户马上能看到，有问题马上修改。

这个过程中有人可能会提出问题，如果客户要求无穷尽怎么办。　其实我们在整个项目中有一优势，那就是面对我们的直接客户都是it从业人员，他们了解需求实现的难度。　　最怕的是客户懂也不懂，他们的要求往往难实现并且修改起来难度大。　　其实我想甲方和乙方在尽快完成项目的出发点是相同的。大家的目的都是尽快完成项目。　　如果真遇到刁难的用户，需求不断变化，那就该市场人员出场了，　大不了做需求变更吧。　rails的优势就是不怕变化，　其实想想 rails的企业项目中用的无非就是scaffold的场景。列表，查看，修改足已，即使再变化还能有多大余地。回想起来我们整个项目中的场景大部分都是 scaffold的那几个默认action能够实现。　




技术选型
前面的需求和rails关系不大，技术选型就不同了。　　　我们的很多中间件的选择都是和rails相关的，这部分比较有意思的。　我们的项目中使用到工作流的场景很多，存储的选择上也费了一番周折，消息总线，全文检索在选型上都是费了些周折的。　　现面我将一一讲述，虽然上面的选型我们在后来是在认清问题后抛弃不用的。

工作流:
   这部分我认为是企业级比较核心的东西，比较可惜的是我一直没有机会了解。　据我目前了解rails社区里不只一家公司在这方面做自己的东西，我的两个同事都在工作中完成了自己的工作流引擎。我们整个项目经历过三个不同的引擎。　　第一款为开源的openwferu，用了两个多月后放弃，我个人感觉是因为对团队中对它了解不足，之前最了解它的同事离职，另外就是舶来品水土不服，经过n多次的修改以及为作者提供了若干patch后最终放弃。对此产品的优缺点我不是很了解。此时正好赶上某rails大牛的加入，大牛的名字我说了应该很多人知道（此大牛是我偶像）。大牛经过几天对openwferu的了解和一晚上加班后我们有了自己的工作流引擎和设计器。
此引擎现在还安静的躺在我们的代码库中，取代之的是另一位rails企业级牛人自己的产品，此引擎以经被应用到若干项目之中。


消息总线：
　　
　　工作流部分我不是很了解，但消息总线却花了几个周来了解各个产品。  之所以选择消息总线的原因是用在消息异步处理上，为了防止网站前端对端压力过大或者业务过大对工作流引擎压力过大。充当缓冲区功能。经过几番google。最终确定几个候选方案。
１　activemq　　支持协议比较多，社区支持度高。缺点是对rails来说显得有点笨重，ruby能够使用的协议也就是starling了，　　有点牛刀杀鸡。这也是最终方案，看中的主要是社区比较好，资料好找点。rails通过active-messaging于之通信。

2  rabbitmq   　erlang实现的旗舰产品，缺点是实在不想在引入一个大家都不熟悉的东西。
3  starling   ruby实现的小东西。　性能一般，稳定性不好说。


ps:记得当初在我自己机器上测试rabbitmq性能卓越(看来erlang这东西名不虚传，我要好好看看我那本erlang编程了)



存储：
　　客户之前的数据库是mssql，我们给出的方案mysql。　另外客户有一套oa的存储采用的是openldap。团队中有人提出我们也把基础数据如用户信息和单位信息以及权限控制放在openldap中做。　这样做的好处是集中控制和与其他子系统集成好，其他子系统指的是客户的一套IM和邮件系统。如果做集中存储的话就会省去用户同步的麻烦，　　这种方案看起来很perfect。　这块的技术选型个程序实现都是我实现的，经过一个月左右的开发我们最终放弃了这种方案。　原因是与openldap作连接的activeldap毕竟不是rails的核型模块，而我们把最核心数据存在activeldap中后于activerecord做关联后很不方便。很多人开始在数据库里做这些数据的同步，我们事实上又没能避免同步的问题。　　
　当我有一天在一个知名rails博克上看到把openldap作为nosql的存储时，感触很深。其实openldap做为存储介质有很多的优点，尝试nosql的同学们不妨考虑一下openldap。　openldap有以下优点
　　１　速度自然不用说，openldap采购berkerldb做存储。
　　2    结构性很强，表达力很好，　　定义不比sql麻烦。
　　３　支持继承，这点很爽
　　４　备份和恢复都极为方便。　尤其备份，openldap可以轻松把分支备份到其他机器上。　也算是扩展性良好。


全文检索：
　　全文检索我了解不多，　　这块开始也做过很多调研。　　专门分出一个同事来做这方面的东西，我们使用的是sphinx。但是最终也没能在项目中真正的用上，原因是对我们来说过于复杂，需要搜索的内容都存在数据库的不超过四个表的字段中。　最终我们选择了mysql的full_search功能。　完全满足需求，简单方便。　　




架构和设计

这块的内容是我腹稿中最大一部分。　　好不客气的认为是架构和设计导致整个项目延误了整个工期。但是存存在总有存在的道理。　我们的架构经历过数次的调整。　每一次调整都是在上一次教训上总结的，所以整个项目下来，每次都有新的体会。大概有四次的主要变化，这部分中我将详细介绍我们项目的整体部分和每次变化的原因。
　　　　　


未完待续....

评论

5 楼 xjdx 2012-08-28  

期待下文..

4 楼 fuwang 2010-04-28  

期待。。 

3 楼 wang4j 2010-04-15  

很期待。。

2 楼 lolomarx 2010-04-12  

非常期待！！！

1 楼 hongmu 2010-04-12  

期待下文。