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

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

评论

44 楼 liusong1111 2008-08-28  

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

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

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

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

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

woody大仙也跑出来了～～～

43 楼 gigix 2008-08-28  

woody_420420 写道

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

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

42 楼 woody_420420 2008-08-28  

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

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

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

41 楼 liusong1111 2008-08-28  

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

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

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

40 楼 rubynroll 2008-08-28  

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

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

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

39 楼 liusong1111 2008-08-28  

跟rails技术本身关系不太大,我们每个人在使用这个新技术的时候,都会在犯错或个人创新的基础上,不断改进.
这些东西会随着时间慢慢清晰起来,每个人的积累也不一样,如何让这些个人的经验随着产品的发展,迅速的传播给每个人,最有效的共享?
这些经验,不止是编码规范,也会包括其它方方面面的活动,比如如何沟通,如何设计,如何实现某个特定功能,如何处理某个通用问题,如何升级,如何测试,... 都是一个个或大或小的套路.

甄别出哪些需要共享,哪些需要通知给其它人,俺们wwei同学已经总结的很好了.

人的能力在某个时刻下就是那样,保持有效的制度和文化才会不断的自我改进.
至少,能让人尽情发泄比沉默要好.

38 楼 7thbyte 2008-08-28  

时间、人员与代码质量的一场竞赛

世界不美好，所以在这种竞赛里必须有人付出更多的代价

区别在于是谁，什么时间而已

37 楼 刑天战士 2008-08-28  

cquaker 写道

hideto 写道

这个跟我们team用的jira一样，jira里可以定制一个ticket的生存周期，我们的做法就是在ticket给QA之前加一个“Code Review”的流程，只有经过“Code Review”之后才会进入QA测试阶段

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

冉翔同学的点子倒是不错，我记得以前有家公司在招聘新人时整个team的member都会面试一下应聘者，如果有一个team member觉得不行就否决掉，这样能保证新的应聘者能够让team每个成员满意，以后工作起来就不会有意见，貌似这家公司就是TW吧？

cquaker 写道

不妨把code review流程加入到开发进程中

看看crucible有用吗？
http://www.atlassian.com/software/crucible/

如果能和小日本那样就好了。

那样不一定好，对于软件开发来说，这样只会限制创造性。gigix说的那个隔离，很难执行。大部分创业公司需要人手，像lz公司当年那样的，肯定找进来很多不会rails的，慢慢培养，这事没办法的办法。

36 楼 cquaker 2008-08-28  

<div class='quote_title'>hideto 写道</div>
<div class='quote_div'>这个跟我们team用的jira一样，jira里可以定制一个ticket的生存周期，我们的做法就是在ticket给QA之前加一个“Code Review”的流程，只有经过“Code Review”之后才会进入QA测试阶段<br/><br/>但是，Code Review又如何能保证Review者确实按规范认真去Review代码？<br/>所以还是<span style='color: #ff6600;'><strong style='background-color: #ffffff;'>缺乏执行力和监督机制</strong></span><br/><br/>冉翔同学的点子倒是不错，我记得以前有家公司在招聘新人时整个team的member都会面试一下应聘者，如果有一个team member觉得不行就否决掉，这样能保证新的应聘者能够让team每个成员满意，以后工作起来就不会有意见，貌似这家公司就是TW吧？<br/>
<div class='quote_title'>cquaker 写道</div>
<div class='quote_div'>不妨把code review流程加入到开发进程中<br/><br/>看看crucible有用吗？<br/>http://www.atlassian.com/software/crucible/</div>
<br/></div>
<p> </p>
<p>如果能和小日本那样就好了。</p>
<p> </p>

35 楼 lsyong 2008-08-28  

每隔一段时间，让每个人拿出自己认为写得比较好的代码，给大家讲一下。
认为自己没有好代码的，揍他。
拿出来的代码自己都没搞懂或者大家都看不懂，揍他。
一半觉得好一半觉得不好，分析分析原因。
都觉得好，推广起来。

34 楼 dazuiba 2008-08-28  

引用

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

这个问题背后，是一个不争的事实：我们的经验积累还很有限。

我非常相信楼上几位都有非常丰富的rails项目经验，但我更相信绝大多数像我这样：用了几年java,但只有一年的ruby经验，有几个项目经验，但团队规模都在3人左右的级别。

rails如何拥抱“大规模项目”(30人月以上)

在享受着rails,ruby给予我们以强大的快速开发能力，与编程之美的同时，如何不滥用这些power?

或许我们以后可以分享一下自己的best practise,就像下面这个网站做的事情一样。
http://www.therailsway.com/

33 楼 hideto 2008-08-28  

哈哈，没有这么大的权力

jack 写道

既然你不缺乏工具，不缺乏技术，不缺乏能力，还是在人员上下功夫，把不合群的先隔离。

32 楼 jack 2008-08-28  

既然你不缺乏工具，不缺乏技术，不缺乏能力，还是在人员上下功夫，把不合群的先隔离。

31 楼 jack 2008-08-28  

hideto 写道

冉翔同学的点子倒是不错，我记得以前有家公司在招聘新人时整个team的member都会面试一下应聘者，如果一个team member觉得不行就否决掉，这样能保证新的应聘者能够让team每个成员满意，以后工作起来就不会有意见，貌似这家公司就是TW吧？

我以前所在的公司也是如此，这样招聘尽量会使得团队成员有效协同的工作。而且能够保证相同水准的人在一个团队工作.

30 楼 hideto 2008-08-28  

这个跟我们team用的jira一样，jira里可以定制一个ticket的生存周期，我们的做法就是在ticket给QA之前加一个“Code Review”的流程，只有经过“Code Review”之后才会进入QA测试阶段

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

冉翔同学的点子倒是不错，我记得以前有家公司在招聘新人时整个team的member都会面试一下应聘者，如果有一个team member觉得不行就否决掉，这样能保证新的应聘者能够让team每个成员满意，以后工作起来就不会有意见，貌似这家公司就是TW吧？

cquaker 写道

不妨把code review流程加入到开发进程中

看看crucible有用吗？
http://www.atlassian.com/software/crucible/

29 楼 jack 2008-08-28  

gigix 写道

nihongye 写道

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

愿意，并且能够

这个也是个办法，抛弃那些不合群的，或者不符合团队精神的人员，留下能够遵守规矩并有能力者，不过除非团队初期建设如此，并能够一并执行。否则在一个混乱的团队里面，首先要做的事情就是人员清洗了...

28 楼 gigix 2008-08-28  

liuqiang 写道

所有我觉得还是从你的第二点“其他”上想办法吧

其实，我最近在想这个问题，只是还没有得到最终的结果，暂时不拿出来讨论
和其他的质量保障手段一样，这个问题肯定不是靠文档规范能解决的，这需要一套实践指导：配备什么样的coach，一个coach带几个新手，这几个人怎么在一起工作，新手学习哪些知识和技能，经过多长的时间，其结果是新手能有保障地交付什么样的工作
这些都是需要细化的

27 楼 cquaker 2008-08-28  

不妨把code review流程加入到开发进程中

看看crucible有用吗？
http://www.atlassian.com/software/crucible/

26 楼 liuqiang 2008-08-28  

<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>nihongye 写道</div>
<div class='quote_div'>不管是师傅手把手还是招臭味相投的人，说穿了就是做事的人<span style='color: #0000ff;'>愿意</span>投入其中。</div>
<br/>愿意，并且能够</div>
<p> </p>
<p> 这个……，貌似在说：怎么能使代码规范？找能使代码规范的人。感觉有点笼统。</p>
<p> </p>
<p>LZ说了，林子大了什么鸟都有，这是事实，所以愿意是个问题。</p>
<p> </p>
<p>能够使代码规范，但大家风格不统一，你不能说谁的代码不规范呀。</p>
<p> </p>
<p>所有我觉得还是从你的第二点“其他”上想办法吧</p>

25 楼 gigix 2008-08-28  

nihongye 写道

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

愿意，并且能够