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

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

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

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

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

结对的另一个人呢？

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

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

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

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

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

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

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

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

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