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

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

评论

24 楼 nihongye 2008-08-28  

gigix 写道

冉翔 写道

http://tech.sina.com.cn/i/2007-11-16/12151856470.shtml

http://www.dbanotes.net/review/paypal_mafia.html

-----------------转载部分----------------------------------
每个成功的企业都有独特的基因，文章中用了不小篇幅描述 Paypal 的招聘原则：只招聘和自己相像的人。Paypal 的基因似乎就是"反主流"，“Google 雇佣博士，而 Paypal 招聘那些读到博士又弃之的人"。这一群臭味相投的人在一起，倒也无愧于 "mafia" 这个标题。黑帮哪有不火拼的? Paypal 和 X.com 合并后的内斗就好比 ”火拼王伦": Musk 要把系统迁移到 Windows 平台上(这想法真不是一般的糟)，结果引起 Paypal 黑帮众怒，群起攻之，Musk 卷了铺盖。
--------------------------------------------------------------------


俺滴答案

 
怎么确保人们写出好代码？
1. 只招会写好代码的人。
2. 其他

不管是师傅手把手还是招臭味相投的人，说穿了就是做事的人愿意投入其中。

23 楼 gigix 2008-08-28  

冉翔 写道

http://tech.sina.com.cn/i/2007-11-16/12151856470.shtml

http://www.dbanotes.net/review/paypal_mafia.html

-----------------转载部分----------------------------------
每个成功的企业都有独特的基因，文章中用了不小篇幅描述 Paypal 的招聘原则：只招聘和自己相像的人。Paypal 的基因似乎就是"反主流"，“Google 雇佣博士，而 Paypal 招聘那些读到博士又弃之的人"。这一群臭味相投的人在一起，倒也无愧于 "mafia" 这个标题。黑帮哪有不火拼的? Paypal 和 X.com 合并后的内斗就好比 ”火拼王伦": Musk 要把系统迁移到 Windows 平台上(这想法真不是一般的糟)，结果引起 Paypal 黑帮众怒，群起攻之，Musk 卷了铺盖。
--------------------------------------------------------------------


俺滴答案

 
怎么确保人们写出好代码？
1. 只招会写好代码的人。
2. 其他

22 楼 冉翔 2008-08-28  

http://tech.sina.com.cn/i/2007-11-16/12151856470.shtml

http://www.dbanotes.net/review/paypal_mafia.html

-----------------转载部分----------------------------------
每个成功的企业都有独特的基因，文章中用了不小篇幅描述 Paypal 的招聘原则：只招聘和自己相像的人。Paypal 的基因似乎就是"反主流"，“Google 雇佣博士，而 Paypal 招聘那些读到博士又弃之的人"。这一群臭味相投的人在一起，倒也无愧于 "mafia" 这个标题。黑帮哪有不火拼的? Paypal 和 X.com 合并后的内斗就好比 ”火拼王伦": Musk 要把系统迁移到 Windows 平台上(这想法真不是一般的糟)，结果引起 Paypal 黑帮众怒，群起攻之，Musk 卷了铺盖。
--------------------------------------------------------------------


俺滴答案

21 楼 hideto 2008-08-28  

再次重申一下，不是缺乏规范，我们有相当多的wiki page在描述各种开发规范
我们缺乏的是监督机制，或者notify机制
我们缺乏的是执行力，这个不是靠大家自觉就能搞的，况且林子大了什么鸟都有

ltian 写道

gigix 写道

ltian 写道

gigix 写道

jack 写道

gigix 写道

hideto 写道

其实想说的就是一种监督机制，类似于一个Supervisor，规定这种指责并赋予权限
规范这种东西可以慢慢归纳总结，但是缺乏Supervisor这种角色的机制，这样有规范也不行，执行力达不到

你想一件事情，以前到铁匠铺瓷器铺学徒的那些小孩，他的规范是什么？他的机制是什么？
现成的经验摆在面前要去学的。

模仿？模仿前人的作品？

师傅带徒弟。手把手的教，眼对眼的看。言传身教，不立文字。
其直接结论就是，烂师傅教不出好徒弟。
必须充分认识到人类两千年来得到的这一经验的正确性，从而杜绝对所谓规范和流程的不切实际的幻想。

请教一下，您如何评价福特开创汽车生产流水线这一现代工业生产体系呢？

有兴趣的话你就去看看大野耐一的书，看看福特请日本人做了些什么，看看现代工业生产体系到底是怎么在运转

说实在的，我没时间去看。没有规范不知道计算机界向什么方向发展，也许微软，SUN、IBM的规范之争都是毫无意义的。

20 楼 liuqiang 2008-08-28  

有2个疑问：
1  LZ说的编码规范 和 微软，SUN、IBM的规范是同一回事吗？
2 “我的实践证明，有比较好的平台和框架能够简化开发”，和编码规范有关系吗？

PS:某人又开始玩话题漂移游戏了

19 楼 gigix 2008-08-28  

ltian 写道

gigix 写道

有兴趣的话你就去看看大野耐一的书，看看福特请日本人做了些什么，看看现代工业生产体系到底是怎么在运转

说实在的，我没时间去看。没有规范不知道计算机界向什么方向发展，也许微软，SUN、IBM的规范之争都是毫无意义的。

既然你没时间看，我也没时间跟你解释

18 楼 gigix 2008-08-28  

ltian 写道

gigix 写道

jack 写道

gigix 写道

hideto 写道

其实想说的就是一种监督机制，类似于一个Supervisor，规定这种指责并赋予权限
规范这种东西可以慢慢归纳总结，但是缺乏Supervisor这种角色的机制，这样有规范也不行，执行力达不到

你想一件事情，以前到铁匠铺瓷器铺学徒的那些小孩，他的规范是什么？他的机制是什么？
现成的经验摆在面前要去学的。

模仿？模仿前人的作品？

师傅带徒弟。手把手的教，眼对眼的看。言传身教，不立文字。
其直接结论就是，烂师傅教不出好徒弟。
必须充分认识到人类两千年来得到的这一经验的正确性，从而杜绝对所谓规范和流程的不切实际的幻想。

请教一下，您如何评价福特开创汽车生产流水线这一现代工业生产体系呢？

有兴趣的话你就去看看大野耐一的书，看看福特请日本人做了些什么，看看现代工业生产体系到底是怎么在运转

17 楼 hideto 2008-08-28  

未免太天真了点，光靠程序员自觉是不行的，你以为程序员都跟你写的程序似的一成不变？

ltian 写道

hideto 写道

ltian 写道

如果，没有核心的框架，没有服务的概念，各个层次对象之职责划分不清晰，哪些服务该在哪个层次暴露没有规范，哪个层次的服务可以调用哪那个层次的服务没有规范，那么很难形成统一的编码风格。语言灵活之后问题更加突出。语言灵活不是产生问题的根本原因。就是都用Java开发也会弄出五花八门的程序风格来。

至于CSS，JS，以及其他资源文件目录不统一这是在概要设计时就应设计的东西。不是很难的问题。

系统很大，模块所提供的服务方式各不相同，服务之间调用困难，数据库事物很难协调，沟通困难，看起来像是管理问题，实质还是是技术问题。这是做大系统都要遇到的问题，建议楼主看看SCA、SDO规范，这两个规范主要的就是解决这些问题。

根本的问题在于构架设计，而不是语言问题。当然这些问题也不是靠减少平均代码行数来解决。在基本的体系构架没有建立之前，因为没有足够的规范和标准，就通过代码走查来发现问题和试图解决问题就会导致开发者和走查者之间的各种冲突矛盾，于事无补。

其实想说的就是一种监督机制，类似于一个Supervisor，规定这种指责并赋予权限
规范这种东西可以慢慢归纳总结，但是缺乏Supervisor这种角色的机制，这样有规范也不行，执行力达不到

我说的意思不是说单靠监督机制或者设置一个角色就能解决这些问题。你所说的这些问题，其本质还是技术问题。直白地说，如果你用RUBY语言实现SCA和SDO规范，作出一个二次开发框架或者平台（当然一个这样的平台或许不够），然后再在这个框架及平台上进行开发应用系统，那么形成开发规范就是很自然的事情了，只要培训之后，开发者会很自觉的遵守。这样，即简化了开发，又使团队按照同样的规范进行开发，那么你的问题就解决了，监督机制也有章可循了。否则，仅仅设立一个监督的角色，要么是开发者同Supervisor吵架，要么是Supervisor，独裁一切，开发者郁闷。

假如你的老板对你增加Supervisor这个角色的建议表示赞同，并对你说：很好，你来做吧，把这个事情给我搞好。
你将如何能够做好呢？

16 楼 gigix 2008-08-28  

jack 写道

gigix 写道

hideto 写道

其实想说的就是一种监督机制，类似于一个Supervisor，规定这种指责并赋予权限
规范这种东西可以慢慢归纳总结，但是缺乏Supervisor这种角色的机制，这样有规范也不行，执行力达不到

你想一件事情，以前到铁匠铺瓷器铺学徒的那些小孩，他的规范是什么？他的机制是什么？
现成的经验摆在面前要去学的。

模仿？模仿前人的作品？

师傅带徒弟。手把手的教，眼对眼的看。言传身教，不立文字。
其直接结论就是，烂师傅教不出好徒弟。
必须充分认识到人类两千年来得到的这一经验的正确性，从而杜绝对所谓规范和流程的不切实际的幻想。

15 楼 jack 2008-08-28  

gigix 写道

hideto 写道

其实想说的就是一种监督机制，类似于一个Supervisor，规定这种指责并赋予权限
规范这种东西可以慢慢归纳总结，但是缺乏Supervisor这种角色的机制，这样有规范也不行，执行力达不到

你想一件事情，以前到铁匠铺瓷器铺学徒的那些小孩，他的规范是什么？他的机制是什么？
现成的经验摆在面前要去学的。

模仿？模仿前人的作品？

14 楼 gigix 2008-08-28  

hideto 写道

其实想说的就是一种监督机制，类似于一个Supervisor，规定这种指责并赋予权限
规范这种东西可以慢慢归纳总结，但是缺乏Supervisor这种角色的机制，这样有规范也不行，执行力达不到

你想一件事情，以前到铁匠铺瓷器铺学徒的那些小孩，他的规范是什么？他的机制是什么？
现成的经验摆在面前要去学的。

13 楼 hideto 2008-08-28  

ltian 写道

如果，没有核心的框架，没有服务的概念，各个层次对象之职责划分不清晰，哪些服务该在哪个层次暴露没有规范，哪个层次的服务可以调用哪那个层次的服务没有规范，那么很难形成统一的编码风格。语言灵活之后问题更加突出。语言灵活不是产生问题的根本原因。就是都用Java开发也会弄出五花八门的程序风格来。

至于CSS，JS，以及其他资源文件目录不统一这是在概要设计时就应设计的东西。不是很难的问题。

系统很大，模块所提供的服务方式各不相同，服务之间调用困难，数据库事物很难协调，沟通困难，看起来像是管理问题，实质还是是技术问题。这是做大系统都要遇到的问题，建议楼主看看SCA、SDO规范，这两个规范主要的就是解决这些问题。

根本的问题在于构架设计，而不是语言问题。当然这些问题也不是靠减少平均代码行数来解决。在基本的体系构架没有建立之前，因为没有足够的规范和标准，就通过代码走查来发现问题和试图解决问题就会导致开发者和走查者之间的各种冲突矛盾，于事无补。

其实想说的就是一种监督机制，类似于一个Supervisor，规定这种指责并赋予权限
规范这种东西可以慢慢归纳总结，但是缺乏Supervisor这种角色的机制，这样有规范也不行，执行力达不到

12 楼 jack 2008-08-28  

语言风格的问题，建议模仿你们正在用的框架的语言风格，完全一致是不可能的，不过大家都尽量往那个方向靠近，这样就可以了。

11 楼 hideto 2008-08-28  

老刑的建议很好，谢谢
其实打工就是这样，很矛盾，明明自己没什么权力，但又这也看不惯那也看不惯
有些时候还是别把自己太当回事儿

刑天战士 写道

作为一个和老板战斗了1年多的人，我给你点经验：

1.Don't only make suggestion, come with a solution:
   每次想提建议的时候，提出一个解决方案。要合理的，不会对系统造成巨大影响的。

2. 每次提建议的时候，请用正规的方式：Email and so on.别用口头的形式，因为人家会认为你不重视。把为什么提出这个建议，系统中的问题（要有代码段一类的），改进后的效果（同样要有实际的东西）写清楚。语气要诚恳，让人家知道你是为了公司着想。

3.争取在出现问题的时候提建议，效果会更好。
4.无论老板多么傻X，别生气，说话别提高声调，尽量稳住情绪。（这点我做的很不好。）如果无法快速交流请练习口语。

10 楼 刑天战士 2008-08-28  

liuqiang 写道

刑天战士 写道

作为一个和老板战斗了1年多的人，我给你点经验：

1.Don't only make suggestion, come with a solution:

你在说我吗，哈哈，所以我说，与其民主，不如遇到一个开明的君主，您瞧瞧，这又开始折腾CMMI了，我觉得我又要读下jack写的“如何在不规范的公司里生存”这篇文章了……

jack说的没错，应该先是自己成为一把手（Team Leader一类的），然后按照我上面说的一步一步来。其实，大多数公司都存在管理问题（国内公司），要想生存，必须适应环境。适应了环境，才能改变环境。

9 楼 liuqiang 2008-08-28  

<div class='quote_title'>刑天战士 写道</div>
<div class='quote_div'>作为一个和老板战斗了1年多的人，我给你点经验： <br/><br/>1.Don't only make suggestion, come with a solution:</div>
<p> </p>
<p> 你在说我吗，哈哈，所以我说，与其民主，不如遇到一个开明的君主，您瞧瞧，这又开始折腾CMMI了，我觉得我又要读下jack写的“如何在不规范的公司里生存”这篇文章了……</p>

8 楼 刑天战士 2008-08-28  

作为一个和老板战斗了1年多的人，我给你点经验：

1.Don't only make suggestion, come with a solution:
   每次想提建议的时候，提出一个解决方案。要合理的，不会对系统造成巨大影响的。

2. 每次提建议的时候，请用正规的方式：Email and so on.别用口头的形式，因为人家会认为你不重视。把为什么提出这个建议，系统中的问题（要有代码段一类的），改进后的效果（同样要有实际的东西）写清楚。语气要诚恳，让人家知道你是为了公司着想。

3.争取在出现问题的时候提建议，效果会更好。
4.无论老板多么傻X，别生气，说话别提高声调，尽量稳住情绪。（这点我做的很不好。）如果无法快速交流请练习口语。

7 楼 hideto 2008-08-28  

对，就是缺乏技术负责人这样的角色
我越来越发现，一个项目成员的构成应该是树形结构，最上面的人统领全局，下面的人依照执行即可
要是有多个树冠，这项目就没法控制了

liuqiang 写道

jjx 写道

感觉这个东西同语言本身还不是很大，团队中像目录，代码写法等随便那个语言都要有一个规范的

恩，统一建好目录，统一checkout，建目录的权限不要开放给所有人


建立代码走查表，走查一段时间，情况应该会有所好转


杜绝用比较怪癖的语法，其实你用java也可以把方法写的特别怪，技术负责人把握下尺度


不成熟的建议

6 楼 neodoxy 2008-08-28  

划分的时候把每个方法作的足够小，然后对方法名做出强制规范，能在一定程度上解决这个问题

5 楼 hideto 2008-08-28  

nihongye 写道

用结队编程，做一段时间的积累，实打实的交流比仓促的决定下来的规范更容易被接受和有说服力。

我们也用结对，但结对也只是局部的，根本没法全局控制系统
时间越长，系统越发散，没有一个一致的方向