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

使用Rails开发大型复杂B2B应用一年了，这个项目目前开发人员达到近20人
现在感觉最痛苦的事情就是大家没有遵循统一的代码规范
我一直建议PM要设立一个项目架构师的角色，来统一大家的代码规范，但是PM不听
因为Ruby这种动态语言太灵活，大家各自写个各自的代码，相互之间很难看懂别人的代码
Controller、Model、View、Js、CSS等等文件目录的设立也是各模块小组之间各自为政
现在系统越来越复杂，各模块之间的协调和交互也越来越多
但是由于没有人来盯统一的代码规范和设计，大家的交流变得非常痛苦
换句话说，看见别人的代码和自己的代码风格迥异感觉很不爽

评论

84 楼 truesmile 2008-09-03  

gigix 写道

truesmile 写道

这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。
如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。

要想办法
不过原则上来说，每个程序员只了解自己那个模块才真是一件成本（和风险）很高的事情

当然不是“只了解自己那个模块”了，而是对其它模块不是很熟悉。还不能熟悉到进行结对交换后，就立即编写代码的程度。而是要前后看看：“哦，跟我交换的那个人做了什么什么，那么我接下来应该这样这样”，半天过去了，老板就要发飙了...

83 楼 seemoon 2008-09-01  

Code review在项目开始前做要比项目进行到中期做好，Code review由少数几个人做比一群人都来做好，因此，在项目开始就要多进行几次code review，形成项目章程，这个工作由少数几个牛人做比较合理，pm不管这些事情，tech leader要对代码负责，对pm负责，如果pm既是pm又是tech leader，那么这是岗位重叠问题，不是做与不做如何做能解决的，找到你的主管去解决，而且，越快越好。

82 楼 halfmile 2008-09-01  

hideto 写道

但是，Code Review又如何能保证Review者确实按规范认真去Review代码？
所以还是缺乏执行力和监督机制

对Reviewer有无奖惩机制？若无，谁愿意花心思去看别人代码？若有，Reviewer让有问题的代码commited的话就得罚。

另，20多人的团队，需要有个构架师控制系统结构和模块的接口，这不是PM的责任，你强求他也未必有效。从你的介绍中来看，你们的团队貌似是平面管理。每个人都忙于读代码，写代码。若无人能从全局去看这个东西，不久下面的开发就会怨声载道。时间长了拖垮项目质量。

81 楼 7thbyte 2008-09-01  

刑天战士 写道

我们公司就是这样，多次和老板提了，起码要有个文档一样的东西阿，就是不听，说敏捷开发不需要文档……

“敏捷”概念被庸俗化的典型。。

80 楼 刑天战士 2008-09-01  

gigix 写道

truesmile 写道

这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。
如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。

要想办法
不过原则上来说，每个程序员只了解自己那个模块才真是一件成本（和风险）很高的事情

我们公司就是这样，多次和老板提了，起码要有个文档一样的东西阿，就是不听，说敏捷开发不需要文档……

79 楼 jack 2008-08-31  

gigix 写道

truesmile 写道

这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。
如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。

要想办法
不过原则上来说，每个程序员只了解自己那个模块才真是一件成本（和风险）很高的事情

没错，不能把宝只压在一个人身上。

要做到这点，首先从想法上就不能排斥修改和继承其他人的项目或者代码。并随时做好离开自己手头的工作，接手其他人工作的准备。

78 楼 gigix 2008-08-31  

truesmile 写道

这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。
如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。

要想办法
不过原则上来说，每个程序员只了解自己那个模块才真是一件成本（和风险）很高的事情

77 楼 truesmile 2008-08-31  

gigix 写道

woody_420420 写道

我们可以在团队内部制订一个框架性的规范（不是面面俱到的模板），如果可能，尽量频繁交叉结对（共产主义？），如果发现代表性的问题，可以定期以邮件，会议的方式告知团队所有的成员。。。时间久了，我想团队内部自然而然可以形成特有的编码风格与规范。

这个，才是正道
结对
每天（或者两天，或者半天）轮换结对
所有人拥有所有代码
我们有一个实践：每天早上花10～20分钟，把昨天所有的修改svn diff出来，大家一起review一遍
这是在结对之外的team review
频率高，高到近乎实时的监督，才能有效
代码写出来之后两周才review的话，是不会有印象的

这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。
如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。

76 楼 gigix 2008-08-30  

paranoid945 写道

java中可以用checkstyle

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

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

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

http://saikuro.rubyforge.org/
http://ruby.sadi.st/Flog.html
工具检查是非常好的东西
因为它是免费的
只要在持续集成里配好，你什么都不用管，检查就自动进行了
随时告诉你什么地方可以改进
既然有免费的建议为什么不听？
当然了，你首先得确保这个团队有能力听取建议

75 楼 gigix 2008-08-30  

fyting 写道

到根本还是人的问题，不管什么语言或者工具，都不可避免，所以我觉得说啥java是“工业语言”纯粹扯谈，给你个千多行的方法，再"工业"你也看不懂。

你还真别说，这种情况下Java就是好弄得多
原因是，Java有成熟的重构工具
我曾经在客户那里，对着一个千多行的方法，两天时间，嘁哩喀喳，变成十多个类，一个command模式和一个工厂，基本上是一个形式化结构化的过程，不费什么脑子
如果是Ruby的话，就要费劲了，而且需要更高的测试覆盖率才能达到同样的安全感
所以，基本上，“更容易写出优秀的程序”也就等价于“更容易写出烂程序”
那么摆在面前的问题是，你拥有的是一个什么样的团队
是希望写出好程序，还是仅仅满足于不写出太烂的程序

74 楼 fyting 2008-08-30  

到根本还是人的问题，不管什么语言或者工具，都不可避免，所以我觉得说啥java是“工业语言”纯粹扯谈，给你个千多行的方法，再"工业"你也看不懂。
倒不妨制定好规范，规定哪些能做哪些不能做，这需要从团队的实践中总结而来，要大部分人能够欣然接受，不产生抵触。然后，才能真正实行下去。如果能有code review和结对最好，哦哦，大多数情况下只能想想。还有，不合格的人一定不能招，否则可能人越多越失败……这牵涉的更多了，软件过程中的问题，不光凭技术就能够解决……

73 楼 hustKiwi 2008-08-30  

刑天战士 写道

第2条根本无法执行，谁也没那个时间……

恩...这个时间比项目真正因为代码质量而遇到阻碍再回过头来重构代码兼培训员工应该少很多吧。就像有人还觉得单元测试是浪费时间呢...其实很多时候我们缺的就是对员工(尤其是新手)随时、随地、随人的教育，而像这种团队每个成员都有复查、建议甚至喊停的做法，我想对团队整体的提高及规范的普及是有好处的。难点是得到团队的认同并通力执行。所以最好从上而下的强制推行。
我当时实习所在的公司就是这样坚持做的，PM首当其冲复查把关。每天开发组内光code review的邮件就收到几十甚至上百封。开始时也很不习惯，一来怕自己的代码太烂，别同事批来批去的面儿上过不去。二来也觉得时间紧，得过且过多好阿。后来渐渐习惯了，有时也主动查阅下相关模块别人写的代码，有疑问就提出来放在邮件列表里讨论。作为普通开发者，每天也不用花很多时间在上面，固定阅读几个与自己开发相关的或核心模块的代码就可以了，有时看看组内技术牛人回复的建议信件，好好反思下，也是有则改之无则加勉的提高手段。
当然，每个团队情况不一样，有些公司连源码对开发者都保密，连查看组内其他成员代码的权限都不给，就更别提什么code review和建议了。

72 楼 刑天战士 2008-08-30  

第2条根本无法执行，谁也没那个时间……

71 楼 hustKiwi 2008-08-30  

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

70 楼 frozentree 2008-08-29  

管好自己的事，干自己的活，挣你应该挣得那份钱。是程序员，完成你自己的task就得了，是team leader管好自己的小组就得了。 你一个程序员非要抢架构师的活，你有那末大精力吗？这种帖子绝对是灌水贴，大家都扪心自问下，有用吗？

69 楼 sun_hejie 2008-08-29  

    

68 楼 paranoid945 2008-08-29  

java中可以用checkstyle

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

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

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

67 楼 seemoon 2008-08-29  

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

66 楼 caryl 2008-08-29  

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

65 楼 nihongye 2008-08-29  

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