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

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

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

同意，Ruby语言“做一件事情有N种做法”，开发团队人数多了，就需要一些编码规范来约束。

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

 

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

 

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

 

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

 

不成熟的建议

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

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

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

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

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

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

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

 

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