|
锁定老帖子 主题：说说Code Review
精华帖 (4) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (3)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-06-20
代码风格和基本素质有一定的关系，和所谓的星座有关系吗？
你有没有用心的在做事，这是很关键的，其它的都是借口！ |
| 返回顶楼 | |
|
发表时间：2011-06-20
zwchen 写道 我有一个习惯，在写完代码后大约几周，因为需要改进，再去review原来的代码，发现那些代码比较丑陋，于是重构啊重构...
我曾经用Flex开发过业务框架，然后基于该框架开发业务系统。因为开始对flex的不太了解(没有看到过任何公开的项目)，所以花了一个月时间大重构，然后项目其它人也跟着重构。 一个新项目，代码不写上上万行，很难发现之前的代码重用性、健壮性等有问题。 基于我的这些经历，我觉得如果一个人对自己的代码smell要求高，那么他会千方百计去改进，即使自己加班。 当然，这很不普遍，所以没有通用性，我们也不应该在项目管理中有这样的假设。但是，作为一个PM，一定要让他的团队(辅导和激励)，喜欢上自己的代码。如果一个人觉得自己和别人的代码都很恶心，是不可能改进代码质量的，即使改进，也是应付。而这，往往是Code Improve的前提。 ms有点道理，可是在交付测试之前做这些，千万不要开始几轮测试之后做重构，会影响代码稳定性。 |
| 返回顶楼 | |
|
发表时间：2011-06-22
zwchen 写道 我有一个习惯，在写完代码后大约几周，因为需要改进，再去review原来的代码，发现那些代码比较丑陋，于是重构啊重构...
我曾经用Flex开发过业务框架，然后基于该框架开发业务系统。因为开始对flex的不太了解(没有看到过任何公开的项目)，所以花了一个月时间大重构，然后项目其它人也跟着重构。 一个新项目，代码不写上上万行，很难发现之前的代码重用性、健壮性等有问题。 基于我的这些经历，我觉得如果一个人对自己的代码smell要求高，那么他会千方百计去改进，即使自己加班。 当然，这很不普遍，所以没有通用性，我们也不应该在项目管理中有这样的假设。但是，作为一个PM，一定要让他的团队(辅导和激励)，喜欢上自己的代码。如果一个人觉得自己和别人的代码都很恶心，是不可能改进代码质量的，即使改进，也是应付。而这，往往是Code Improve的前提。 从你的文章就能看出来。是个做实事的人。 虽然有些时候观点有点非主流，但实际上来说，更加直接和精确。 很多主流的观念都是浮于形式，而对于项目和团队本身或许就是一些浮于虚表的负累。这样的现状其实是可以理解的，一个在基层混乱3-5年的人，就想着不断的攀升自己的薪资和职位，总要有一些相应的东西来标榜自己的光鲜。于是一大堆的国际上的主流思想进入进来，被这些人拿来做美化自己的美容剂，在自己还没想明白这些管理到底在针对什么问题的时候，就盲目的进行推行，还一边要显示自己的权威性，导致很多的规范和规约这样的东西，不仅仅很大程度上不能对开发产生积极的作用，还让很多开发消耗更多的资源。然后一旦项目出现问题，这些人还可以拿着规范说事，在执行规范的过程中什么什么地方不行，或者完全的执行力规范，最后出来问题，都是底下人的问题。哇哈哈哈哈。不知道多少技术人员因为这些不学无术的家伙“被态度不端正”了多少回。 其实很多技术人员的黑锅，都是被这些所谓的不学无术的领导人员扣在头上的，真实可悲可叹啊，多少技术人员在后期被迫无奈的转型远离自己喜欢的代码只为摆脱黑锅陷阱。真实悲哀。 你的文章，关于项目和技术的感触，很多地方有所共鸣。估计没少被喷吧。哈哈。 知识是可以学出来的，智慧只能是想出来的。 |
| 返回顶楼 | |
|
发表时间：2011-06-22
我的理解codereview是一个方法，不是一个目标也不是一个流程；PM应该根据项目实际情况安排如何进行coderview。
在我们公司里面，codereview已经形成一种流程，每个项目必须要进行codereview。他也会有很多的效果。但是在一些紧急的项目里面，还是没有办法保证codereview的质量的；所以PM要能够取舍。在关键的时间做关键的事情。 |
| 返回顶楼 | |
|
发表时间：2011-06-22
浪费在code review时间，不如多花点钱找几个牛逼点的程序员。
|
| 返回顶楼 | |
|
发表时间：2011-06-23
看了几遍，明白了，你是一位PM，其他太深奥了
|
| 返回顶楼 | |
|
发表时间：2011-06-23
水瓶座的人天性不喜欢约束，代码一般较乱，而处女座的人生性洁癖，代码通常比较整洁。
仁兄,看到这句话的时候我在喝水,差点喷了显示器..... 您有时间再研究一下血型和代码的关系吧.卖糕的，还有属相和代码的关系,也大可研究一下...... |
| 返回顶楼 | |
|
发表时间：2011-06-23
如果没人review 你的CODE 然后拿到客户那里 不说太多就一个BUG 回来批评你写的是什么屁东西的时候， 我该说什么呢？
|
| 返回顶楼 | |
|
发表时间：2011-06-25
如果找几个资深的人员做Code Review是对提高项目组成员的整体水平很有用,
如果一个组的人员,互相交叉code review还可以达到成员间磨合,使以后配合默契 |
| 返回顶楼 | |
|
发表时间：2011-06-26
说说我们Code Review的范围，估计很多人会觉得过分：
1、代码规范，所有的空格和缩进，一但不符合规划，比如if后面没有空格直接括号之类的，全部打回 2、变量命名，包括不符合规范的命名，以及符合了规范但是选取的词语不够好的，打回 3、逻辑整理，比如可以把较短的逻辑放前面的没放，正面能说明的if条件硬是取个反来写的，打回 4、注释，如果和他参与一个项目的人，依旧无法理解其中某一段代码所表达的业务，这一段代码又没有详细的注释，打回 5、还是注释，认为未来有新人进来看这代码，可能在没有注释的情况下看不懂的，打回 6、优化，只要Reviewer认为可以在不付出很大的代价的情况下优化的点，提出并请求编写者参考（参考的结果一般是采纳，除非对其他点有影响） Code Review可以严格，但必须让所有人都明白，Code Review没通过绝对不是什么不光彩的事，不然严格的Review很可能打击人 |
| 返回顶楼 | |
