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

人总是最重要的，在代码规范问题上尤其是。

Supervisor也许能某种程度上解决问题，但是效果有限。

我觉得gigix说的“师傅带徒弟”这个方法比较好，并且我有亲身体会。我曾经带队开发过一个嵌入式操作系统，团队人员参差不齐，很多是刚毕业不久的。这个时候要保证代码质量重要的是要有个好的mentor。注意是mentor不是supervisor。虽然mentor不象supervisor那样能够立即让队员崩紧神经立即对某些不规范的代码作出修正，但是mentor能够使整个团队的素质得到逐步的持续改善，3～6个月过后整个团队就能达到满意的水平，代码风格趋于一致。这个时候操心的不是代码不规范，而是祈求猎头公司不要来打队员的主意:)

“师傅带徒弟”不能保证整体范围的经验分享。
人的成长，需求的明朗，框架的完善，设计的合理，都需要用时间调整。
如何在产品不断成长的过程中，尽快的找出问题，提出疑惑，有效的分享经验，需要制度文化的作用。
正确做出决策，需要一个负责人。

塑造学习型文化/团队应该怎么做？

弄个口水薄吧，看见好的或迷糊的代码，自己的或别人的，就直接贴上去。 主题不允许直接做评论，让这个形式尽量随意。弄上邮件通知。
咱们的group搞的太正式了，对代码支持不好，也没通知，不好用。

不止rails，其他平台同样存在这个问题。

之前做.net，c++开发，公司有一些官方文档，在代码规范方面甚至规定好了：
button控件命名必须btn_***，
checkbox控件命名必须chb_***，
注释的规范，变量的命名规则，大小写，代码模板。。。等等。总之感觉想用一个模式，往开发人员头上一套，霹雳巴拉出来的代码就跟流水线下来的一样。。。
并且我原来的公司也存在相应的监督机制，但是总体下来，感觉整套机制效果不是十分理想（作用是有的，只是达不到预期效果）。

编码本来就不能和制造，生产比，我认为不管怎么样的规范，监督，奖惩。。。都只能隔靴搔痒。根本的问题是在人，现在的地球人不都“以人为本”了么？这个问题只能从“人”这个实质因素解决。代码规范，我觉得这是个长期而艰巨的任务，我们可以在团队内部制订一个框架性的规范（不是面面俱到的模板），如果可能，尽量频繁交叉结对（共产主义？），如果发现代表性的问题，可以定期以邮件，会议的方式告知团队所有的成员。。。时间久了，我想团队内部自然而然可以形成特有的编码风格与规范。

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

to ltian:
粗略看了下SCA和SDO规范，我的理解，是让业务系统细粒度拆分和任意组合变得更容易的手段，然而，从布署和通信上看，更像一个个独立应用，对于某些系统，就显得过（重）了 - 它的能量，还是体现在多个异构系统的细粒度整合能力上，而不是解决一个系统内部的事情。

怎么拆分业务模块，怎么设计服务和数据结构接口，首先是系统构架和设计的问题，当然要考虑技术约束和规范。

一个大系统，如果在业务上很容易拆分出多个彼此相互独立的小模块，那很幸运。
如果系统中各功能大量互相依赖，从业务角度很难拆分，就麻烦的很。
所以，大系统不见得是复杂系统，小系统不见得不复杂。

提高个人的设计能力，以分层、接口、惯例、职责等思路去适度分析设计，也是个问题。

所以，参考SCA和SDO的思路是有价值的，而且应该是我们努力的重要方向，但要完全照它实施，用ruby的SCA、SDO框架，就真要死人了。

woody大仙也跑出来了～～～

人太多了，代码也太多了，没法搞。

分
超过10个developers的团队是令人不快的
因为我没办法一边做事一边听清楚另外10个人在说什么
如果是另外4个或者6个人就完全没问题

群众的眼睛是雪亮的,您消停吧

是单元测试重要还是代码规范重要？模块之间的相互调用我认为是单元测试重要，毕竟单元测试是代码的第一使用者。
如果是html,js,css，那么基本上要通过培训，code review来规范。

我以为昨晚你早早就洗洗睡了。。。昨天躺床上一直想这个问题睡不着，胡思乱想了些如下内容：
1.确实，团队大了，项目规模大了，结队（频繁的结队）不是太现实。但是我觉得凡事只要“度”把握得合适，总会有所收获。比如，项目事太多，可以一个星期找个同学结队改一，两个bug。。。之类的。在这个过程中，我们可以逐步总结，积累。总会有更好的实践的。
2.象"Pair Programming"一样，来个"Team Programming"怎么样？每个星期一，选一个同学从自己的代码中挑一段代码，花20分钟给所有member解释什么的干活，然后，周一到周五就是娱乐时间，大家可以针对这段代码发表任何意见（格式，规范，性能。。。）。到下周一，此同学来总结，得到多少建议，他将接受哪些，不接受哪些。。。如果发现一些普遍问题，我们可以抽取出来形成团队的官方coding文档（变量命名，注释风格。。等等）。当然，我想的这个过程并不是要优化某一段代码，只是通过这个过程，同学们都能在一起交流关于coding规范，团队风格的总总问题。

说到底，我觉得要解决这个问题，拿我原来一同事的话来说：一定要“沟流，交通”！大家各自闷着写自己的代码肯定不行。叫一个牛b人指定一套规范，官方推广也不行。还是得从内而外。

七零八落的一些想法吧~现在还晕，没啥组织，大家将就看看，有啥意见使劲交流。

PS： 看到规范，就想了太多以至失眠。。。我想最主要的原因还是原来一家公司的经历： 项目组一同学惊现的一些诸如：btn_fu*k，iNoName。。。之类的代码，还有不堪入目的项目。。。往事阿~