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

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

评论

104 楼 PBFox 2008-12-18  

这种问题在很多企业中都是存在的，我觉得问题跟用什么语言开发没有多大关系，最重要的是要有一套行之有效的管理机制，当然还有定期的交流机制。

CMMI很多人都是不学一顾的，我觉得在没有一套自己熟练的管理机制时，CMMI里面的好多流程还是值得借鉴的。

另外就是项目的老板安排好项目的组织架构了。

103 楼 gigix 2008-10-28  

刑天战士 写道

你就因为!@#$%这些符号觉得难懂了？告诉我finished?方法哪里难懂。迭代器为什么不好？functional programming就连.net现在也支持了。老兄，我不反对黑一种语言，但是黑要到点子上

你管他呢，让他继续以为花生是长在树上的好了，又不要你出一毛钱。
有些人讨论是为了互通有无答疑解惑，有些人我就不知道他为啥要出来讨论：他知道的才是好的，他不知道的就是坏的，纯粹就是为了给自己的固步自封找点信心。这种人你就告诉他，没错，花生就是长在树上的，然后看着他得意洋洋的背影当个笑话就结了。

102 楼 刑天战士 2008-10-28  

fireflyc 写道

瞎折腾。
老实说，哪位觉得漫天飞舞的
!@#$%^&*符号比较容易读呢？
哪位觉得迭代器的语法是那么好呢？

动态语言可不是这么难看的，动态语言的“动”也不是指语言语法的灵活。
那个松本弘的先生写过一篇文章，说什么写代码像写文章。简直是开玩笑，ruby这种语法近似于火星文字谈什么写文章啊，除非那位喜欢用甲骨文（不妨用甲骨文回复我的帖子。）

ruby语法丑陋，用法怪异，毫无新意。我不明白为什么还规范，它估计规范不了。因为它天生如此。忘了它吧，远离它吧，这样我们的寿命能延长很多。（至少对视力有好处，你不用半夜里看那种类似甲骨文的乱码。）

你就因为!@#$%这些符号觉得难懂了？告诉我finished?方法哪里难懂。迭代器为什么不好？functional programming就连.net现在也支持了。老兄，我不反对黑一种语言，但是黑要到点子上

101 楼 xuby 2008-10-27  

最好的办法是开发个规范自动检查器，自动扫描代码中不规范的地方。
有针对c++语言的类似东东。

100 楼 fireflyc 2008-10-01  

瞎折腾。
老实说，哪位觉得漫天飞舞的
!@#$%^&*符号比较容易读呢？
哪位觉得迭代器的语法是那么好呢？

动态语言可不是这么难看的，动态语言的“动”也不是指语言语法的灵活。
那个松本弘的先生写过一篇文章，说什么写代码像写文章。简直是开玩笑，ruby这种语法近似于火星文字谈什么写文章啊，除非那位喜欢用甲骨文（不妨用甲骨文回复我的帖子。）

ruby语法丑陋，用法怪异，毫无新意。我不明白为什么还规范，它估计规范不了。因为它天生如此。忘了它吧，远离它吧，这样我们的寿命能延长很多。（至少对视力有好处，你不用半夜里看那种类似甲骨文的乱码。）

99 楼 danoyang 2008-09-25  

这些个问题在历史上已经被问了一万遍了吧

解决代码规范的问题

我是觉得 《代码大全》 都讲过了，上面要理论有理论，要数据有数据

详审，走查。。。。。。选一个试验吧！

98 楼 0701 2008-09-16  

<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>truesmile 写道</div>
<div class='quote_div'>呵呵，确实没有尝试过敏捷开发，所以比较好奇。那是不是交换的两个人直接交接就行了，其他两个人继续编码，这样就不会出现停下来的情况？ <br/>以手头上的项目为例子，假设我和一位同事作为A组编写工作流的代码，然后另两位同事作为B组负责财务凭证生成模块。如果让我们写了2天，然后交换结对，估计第一次交换的两个人交接一个上午是没问题的，另外两个人可以继续编码，避免出现停下来的情况？</div>
<br/>所谓的”交接“其实比你想象的还要轻松 <br/>比较熟悉的那个人（A）开始做一件事，一边做一边说 <br/>写一个测试，说我们想要实现这个，run一下测试，失败 <br/>现在比较不熟悉的那个人（B）就开始动手了 <br/>虽然不熟悉，但只是一个很简单的测试，所以稍微讨论一下就可以实现出来 <br/>A再写一个测试，描述另一个分支情况 <br/>B再让这个测试通过 <br/>如此反复，用不了半天B也熟悉这个事情了，并且进度没什么耽搁 <br/><br/>P.S. <br/>（1）任务要小。一个任务干了两天还没干完，以我个人的偏好来说是太大了。 <br/>（2）所以，交换要频繁，我倾向于每天交换。这样当项目进展一段时间以后你就得到一支所有人熟悉项目中所有部分的团队，于是就不存在所谓”交接“的问题了。</div>
<p> </p>
<p> 我不知道国内有没有ruby团队这样干过，当然这个看上去是很好，敏捷嘛，咨询师的方法总是那么的美好。</p>
<p>在一般的团队中，自己把自己负责的那块做好，把代码写的可读性强一点就已经不错了，你这种方法适合起码有2-3年经验以上的人使用</p>

97 楼 paranoid945 2008-09-13  

toostupid 写道

gigix 写道

toostupid 写道

建议:
放弃代码一致性的要求。但文档要好，每个细节都必须有文档。
当需要改又读不懂的时候直接重写。

这个才真叫扯淡
连代码都不能写得能让人读懂
我就奇了怪了，同一个人写出来文档难道就能让人看懂？

那就不知道了，我写的代码一向通俗易懂，所以没研究过这个问题。
一般我写文档是用数学语言定义的，都是set,list,map,<=,这些数学符号，函数也真的是函数，
in,out都定义得比较完整，我不觉得这样的文档难读。

别人 != 你.clone()

开个玩笑，哈哈

96 楼 liano 2008-09-12  

总结发言，看下面的函数：

def 保持代码一致性（公司,领导,开发团队）

   招聘臭味相投的人 if 公司有这个能力

   pair_coding if 人员有pair的素质 and 领导可以接受

   拆分团队，每个团队有lead，各个lead主要负责团队之间的沟通 if 团队成员过多

   每天的team code review if dev <= 5~6

   配备2个coach级别的dev if 大家对ruby rails 不熟悉

   if pair coding 无法实行
       把code review 到工作加入到代码提交的流程中，使用check style;
       也可以由lead组织，定期做dev的讨论会议，一起讨论 code quality
   end
  
end

公司,领导,开发团队 这三项输入都ok 的时候，才会达到最佳的效果。
（这个函数比较烂，写不出缩进）

95 楼 amonlei 2008-09-12  

hideto 写道

我一直建议PM要设立一个项目架构师的角色，来统一大家的代码规范，但是PM不听

架构师是做代码规范监控用？

94 楼 toostupid 2008-09-10  

gigix 写道

toostupid 写道

建议:
放弃代码一致性的要求。但文档要好，每个细节都必须有文档。
当需要改又读不懂的时候直接重写。

这个才真叫扯淡
连代码都不能写得能让人读懂
我就奇了怪了，同一个人写出来文档难道就能让人看懂？

那就不知道了，我写的代码一向通俗易懂，所以没研究过这个问题。
一般我写文档是用数学语言定义的，都是set,list,map,<=,这些数学符号，函数也真的是函数，
in,out都定义得比较完整，我不觉得这样的文档难读。

93 楼 gigix 2008-09-09  

truesmile 写道

呵呵，确实没有尝试过敏捷开发，所以比较好奇。那是不是交换的两个人直接交接就行了，其他两个人继续编码，这样就不会出现停下来的情况？
以手头上的项目为例子，假设我和一位同事作为A组编写工作流的代码，然后另两位同事作为B组负责财务凭证生成模块。如果让我们写了2天，然后交换结对，估计第一次交换的两个人交接一个上午是没问题的，另外两个人可以继续编码，避免出现停下来的情况？

所谓的”交接“其实比你想象的还要轻松
比较熟悉的那个人（A）开始做一件事，一边做一边说
写一个测试，说我们想要实现这个，run一下测试，失败
现在比较不熟悉的那个人（B）就开始动手了
虽然不熟悉，但只是一个很简单的测试，所以稍微讨论一下就可以实现出来
A再写一个测试，描述另一个分支情况
B再让这个测试通过
如此反复，用不了半天B也熟悉这个事情了，并且进度没什么耽搁

P.S.
（1）任务要小。一个任务干了两天还没干完，以我个人的偏好来说是太大了。
（2）所以，交换要频繁，我倾向于每天交换。这样当项目进展一段时间以后你就得到一支所有人熟悉项目中所有部分的团队，于是就不存在所谓”交接“的问题了。

92 楼 truesmile 2008-09-09  

gigix 写道

truesmile 写道

那就是结对的小组都停下来，blabla的由另一个人对刚交换的这个人解说咯

gigix 写道

truesmile 写道

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

结对的另一个人呢？

有些事情呢你没有亲身体验过就只有想当然的猜
比如说谁告诉你“解说”就一定要“停下来”呢？

呵呵，确实没有尝试过敏捷开发，所以比较好奇。那是不是交换的两个人直接交接就行了，其他两个人继续编码，这样就不会出现停下来的情况？
以手头上的项目为例子，假设我和一位同事作为A组编写工作流的代码，然后另两位同事作为B组负责财务凭证生成模块。如果让我们写了2天，然后交换结对，估计第一次交换的两个人交接一个上午是没问题的，另外两个人可以继续编码，避免出现停下来的情况？

91 楼 gigix 2008-09-09  

toostupid 写道

建议:
放弃代码一致性的要求。但文档要好，每个细节都必须有文档。
当需要改又读不懂的时候直接重写。

这个才真叫扯淡
连代码都不能写得能让人读懂
我就奇了怪了，同一个人写出来文档难道就能让人看懂？

90 楼 toostupid 2008-09-09  

建议:
放弃代码一致性的要求。但文档要好，每个细节都必须有文档。
当需要改又读不懂的时候直接重写。

ruby的代码还没有那么晕, haskell的代码那才叫晕。虽然很喜欢haskell这种语言，但一直都觉得自己没有那个天份在里面绕来绕去。

我把ruby的代码都用java的习惯来写，很好读....java太根深蒂固了。

89 楼 gigix 2008-09-07  

truesmile 写道

那就是结对的小组都停下来，blabla的由另一个人对刚交换的这个人解说咯

gigix 写道

truesmile 写道

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

结对的另一个人呢？

有些事情呢你没有亲身体验过就只有想当然的猜
比如说谁告诉你“解说”就一定要“停下来”呢？

88 楼 truesmile 2008-09-07  

那就是结对的小组都停下来，blabla的由另一个人对刚交换的这个人解说咯

gigix 写道

truesmile 写道

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

结对的另一个人呢？

87 楼 davidgrubby 2008-09-07  

认真的看了楼上同学们的议论，觉得大家都说得很好，现在公司也在推Agile，在代码规范这方面增加了Code review的环节，觉得确实很有效，而且同学们在执行的过程都会增加一些成就感以及责任感，这样下去，我相信代码质量以及功能都会得到很大的提升。

另外有一点问题就是在结对开发的时候，是不是真的一个人写一个人看？这样会不会使效率降低呢？

86 楼 紧急下潜 2008-09-05  

我觉得SCA才是解决大规模化开发问题的王道，软件是由组件组成的，组件通过接口对外提供服务
你组件采用什么技术实现，外部调用者不必关心。
软件团队由小团队组成，小团队要保证的就是组件实现完全正确，外部调用者根本不管你怎么实现的，你用c++、java、spring都行，随你，你代码怎么写是你这个小团队的事，由小团队控制

85 楼 gigix 2008-09-03  

truesmile 写道

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

结对的另一个人呢？