|
锁定老帖子 主题：Rails程序开发的最大问题是代码规范
精华帖 (8) :: 良好帖 (16) :: 新手帖 (2) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-08-30
第2条根本无法执行，谁也没那个时间……
|
| 返回顶楼 | |
|
发表时间：2008-08-30
刑天战士 写道 第2条根本无法执行，谁也没那个时间……
恩...这个时间比项目真正因为代码质量而遇到阻碍再回过头来重构代码兼培训员工应该少很多吧。就像有人还觉得单元测试是浪费时间呢...其实很多时候我们缺的就是对员工(尤其是新手)随时、随地、随人的教育，而像这种团队每个成员都有复查、建议甚至喊停的做法，我想对团队整体的提高及规范的普及是有好处的。难点是得到团队的认同并通力执行。所以最好从上而下的强制推行。 我当时实习所在的公司就是这样坚持做的，PM首当其冲复查把关。每天开发组内光code review的邮件就收到几十甚至上百封。开始时也很不习惯，一来怕自己的代码太烂，别同事批来批去的面儿上过不去。二来也觉得时间紧，得过且过多好阿。后来渐渐习惯了，有时也主动查阅下相关模块别人写的代码，有疑问就提出来放在邮件列表里讨论。作为普通开发者，每天也不用花很多时间在上面，固定阅读几个与自己开发相关的或核心模块的代码就可以了，有时看看组内技术牛人回复的建议信件，好好反思下，也是有则改之无则加勉的提高手段。 当然，每个团队情况不一样，有些公司连源码对开发者都保密，连查看组内其他成员代码的权限都不给，就更别提什么code review和建议了。 |
| 返回顶楼 | |
|
发表时间：2008-08-30
到根本还是人的问题，不管什么语言或者工具，都不可避免，所以我觉得说啥java是“工业语言”纯粹扯谈，给你个千多行的方法，再"工业"你也看不懂。
倒不妨制定好规范，规定哪些能做哪些不能做，这需要从团队的实践中总结而来，要大部分人能够欣然接受，不产生抵触。然后，才能真正实行下去。如果能有code review和结对最好，哦哦，大多数情况下只能想想。还有，不合格的人一定不能招，否则可能人越多越失败……这牵涉的更多了，软件过程中的问题，不光凭技术就能够解决…… |
| 返回顶楼 | |
|
发表时间：2008-08-30
fyting 写道 到根本还是人的问题，不管什么语言或者工具，都不可避免，所以我觉得说啥java是“工业语言”纯粹扯谈，给你个千多行的方法，再"工业"你也看不懂。
你还真别说，这种情况下Java就是好弄得多 原因是，Java有成熟的重构工具 我曾经在客户那里，对着一个千多行的方法，两天时间，嘁哩喀喳，变成十多个类，一个command模式和一个工厂，基本上是一个形式化结构化的过程，不费什么脑子 如果是Ruby的话，就要费劲了，而且需要更高的测试覆盖率才能达到同样的安全感 所以，基本上，“更容易写出优秀的程序”也就等价于“更容易写出烂程序” 那么摆在面前的问题是，你拥有的是一个什么样的团队 是希望写出好程序，还是仅仅满足于不写出太烂的程序 |
| 返回顶楼 | |
|
发表时间：2008-08-30
paranoid945 写道 java中可以用checkstyle
相比java， ruby语法更灵活，同样的功能有很多种写法，可以看出来ruby的作者是一个比较崇尚自由的人，且个人英雄主义比较强... 开个玩笑～ checkstyle只支持java，但我相信，在ruby的世界里应该也存在这样一种东西或框架。 可能有很多人比较鄙视工具检查，但是我想说的是， 规范和工具检查，就好比道德与法律... http://saikuro.rubyforge.org/ http://ruby.sadi.st/Flog.html 工具检查是非常好的东西 因为它是免费的 只要在持续集成里配好，你什么都不用管，检查就自动进行了 随时告诉你什么地方可以改进 既然有免费的建议为什么不听？ 当然了，你首先得确保这个团队有能力听取建议 |
| 返回顶楼 | |
|
发表时间：2008-08-31
gigix 写道 woody_420420 写道 我们可以在团队内部制订一个框架性的规范（不是面面俱到的模板），如果可能，尽量频繁交叉结对（共产主义？），如果发现代表性的问题，可以定期以邮件，会议的方式告知团队所有的成员。。。时间久了，我想团队内部自然而然可以形成特有的编码风格与规范。
这个，才是正道 结对 每天（或者两天，或者半天）轮换结对 所有人拥有所有代码 我们有一个实践：每天早上花10～20分钟，把昨天所有的修改svn diff出来，大家一起review一遍 这是在结对之外的team review 频率高，高到近乎实时的监督，才能有效 代码写出来之后两周才review的话，是不会有印象的 这样的话，岂不是要所有人对所有代码都很熟悉？ A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。 如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。 |
| 返回顶楼 | |
|
发表时间：2008-08-31
truesmile 写道 这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。 如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。 要想办法 不过原则上来说，每个程序员只了解自己那个模块才真是一件成本（和风险）很高的事情 |
| 返回顶楼 | |
|
发表时间：2008-08-31
gigix 写道 truesmile 写道 这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。 如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。 要想办法 不过原则上来说，每个程序员只了解自己那个模块才真是一件成本（和风险）很高的事情 没错，不能把宝只压在一个人身上。 要做到这点，首先从想法上就不能排斥修改和继承其他人的项目或者代码。并随时做好离开自己手头的工作，接手其他人工作的准备。 |
| 返回顶楼 | |
|
发表时间：2008-09-01
gigix 写道 truesmile 写道 这样的话，岂不是要所有人对所有代码都很熟悉？
A和B做功能1，C和D做功能2。然后过两天，A和C做功能1，B和D做功能2。 如果项目小的话还好说。在大项目中，没办法让每个程序员不是他写的模块的代码都很了解吧。这样跳来跳去的会增加学习成本。 要想办法 不过原则上来说，每个程序员只了解自己那个模块才真是一件成本（和风险）很高的事情 我们公司就是这样，多次和老板提了，起码要有个文档一样的东西阿，就是不听，说敏捷开发不需要文档…… 
|
| 返回顶楼 | |
|
发表时间：2008-09-01
刑天战士 写道 我们公司就是这样，多次和老板提了，起码要有个文档一样的东西阿，就是不听，说敏捷开发不需要文档…… “敏捷”概念被庸俗化的典型。。 |
| 返回顶楼 | |
