Rails程序开发的最大问题是代码规范

hideto在开会.
我们UI部门分了四个小组,两个业务开发组,一个基础设施和运维组,一个QA组,平均每个组5个人.
hideto提出的问题,我理解还是怎样高效的整体知识分享和反馈,这个职责原本应该在基础组里,可是基础组成员也有开发任务,精力和执行力度不够,不能全局实时负责.
具体的问题,等hideto会开完了,请他讲讲.

看来是业务模块划分不够好是一个原因
理想状态下A和B模块完全分离

如果是公用plugin或lib的设计，则需要各team leader参与review


如果开发任务太紧急，4～5人小团队的话人手肯定不够
说到底还是项目管理的事，不见得是Rails特有的弊端

nod,在邮件标题上分级?

 

OMG

 

ORZ

 

 囧囧囧

其实关键是在人，很多时候，工具只能帮助人，但不能替人解决问题。

PS:这里面好多freewheel的……

问一句，你们现在的代码平均每个方法多少行？
我这样问是因为gigix说他们的是5行，相信这样的代码经过一番雕琢的，即使不统一，应是比较赏心悦目吧。是否统一反而成了不重要的问题。

长点的帖子都跑题吗？
不如大家根据自己的实践，整理出一套行之有效的代码规范，比什么都来得实际。

ror利用了 convention over config这个规则，但是这个规则隐性条文较多，于是不同的人参与到同一项目当中，由于理解力的不同、精力的不同、兴趣的不同，因而使团队开发的成果呈现了一定程度的“异味”；另外一个问题是，ror代码的组织在模块化上面比较固化，这也是由于convention over config所造成的，而模块化是影响开发模式的一个重要因素，因此如何划分模块，以指挥众多开发人员协同开发，也同样成为ror能成为大型企业应用的一个需要解决的问题。所以除了时间、接受度这一挑战外，ror还要解决的就是指导开发的模式和方法论问题，或者说，开发经验？

java中可以用checkstyle

相比java， ruby语法更灵活，同样的功能有很多种写法，可以看出来ruby的作者是一个比较崇尚自由的人，且个人英雄主义比较强...

开个玩笑～
checkstyle只支持java，但我相信，在ruby的世界里应该也存在这样一种东西或框架。

可能有很多人比较鄙视工具检查，但是我想说的是，
规范和工具检查，就好比道德与法律...

这么多牛人都发言了啊，不过还是想说说我的看法，为保证代码规范一致，可酌情采用以下方式：
1）代码规范及复查列表
在项目初始阶段由TL、PM及核心开发者共同制定一份基本的代码规范及复查列表，并向全组公示，大家一起承诺按照该规范协作开发
2）强制性的code review与approve制度
无论是谁，在提交代码前须向全体开发组发邮件，请求review提交的代码。所有人都有查看并提出修改意见的权利，并且直接回复请求review的邮件就成，然后原提交者邮件列表中根据建议发表自己看法，并修改重构不合理的代码（尤其是不符合规范列表的部分）。直到拥有最终审核权利的TL或PM评审通过后才可将代码合并提交到版本控制中，否则不准许进行下部分开发。这一步最关键，新手可以通过这个过程迅速成长，树立责任心，老手也间接将自己的经验通过代码建议传递分享。而且少数几个资深开发者最终把关，可保证代码质量及统一规范。当然，一定要在团队中树立一种开放、平等的氛围，不要让大家抵触这种做法。另外越是老手，越是把关的人越要花更多时间复查同事的代码，中肯地提出意见，并指导其修改。
3）总结Rails重构经验
PM在周例会上适当安排对最佳实践的教学及讲解，比如让优秀开发者通过项目实例让大家明白什么样的代码应该重构，怎样才是优美的做法。
4）单元测试覆盖
这是重构的基础，也是一种很好的开发习惯，同时阅读测试更有益于大家理解代码，算是一种注释和文档。虽不一定片面强求高覆盖率测试，但重要逻辑一定要有测试，并且可以把测试归入代码复查中一同评审。