|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-06-30
史书上没讲。
我猜想的结果是最终没有人能活下来。 |
| 返回顶楼 | |
|
发表时间：2008-07-01
毫无疑问是 test.
质检组的人不会管你砖砌的是不是很"面向对象",也不会管你用了一个"资源"(比如一个铁锹)之后有没有"释放". 而且他基本上是黑盒测试,只管拿条大枪往墙上戳. |
| 返回顶楼 | |
|
发表时间：2008-07-04
photon 写道 其实要不要review，采取何种方式review，是和楼主的项目特点、团队具体情况密切相关的，看看有谁有成功的review经验，并且项目、团队也和楼主类似。 我觉得这位朋友思考的方向挺对，其实就像软件没有银弹一样，也没有一种review方案能满足所有的情况 所以，我们公司technical committee最后达成了一个统一的意见：我们定义出几种可选的方案，由特定项目的项目经理或资深人员在项目开始时选择一个适合自己项目的方案。 为什么这样做呢？ 1。 没有一种方案可以适合所有的项目。 2。 开发人员是一个充满个性和激情的团体，review工作是一个充满主观能动性的工作，如果不是他们认可的方案或做事方式，注定了工作的效果不会太好。 3。 人和人的观念是软件项目的一切，规矩只是辅助工具。 |
| 返回顶楼 | |
|
发表时间：2008-07-04
让质检组的人来code review,与他们的测试有何区别?
还叫什么code review? xuby 写道 毫无疑问是 test.
质检组的人不会管你砖砌的是不是很"面向对象",也不会管你用了一个"资源"(比如一个铁锹)之后有没有"释放". 而且他基本上是黑盒测试,只管拿条大枪往墙上戳. |
| 返回顶楼 | |
|
发表时间：2008-07-08
rabbitbug 写道 让质检组的人来code review,与他们的测试有何区别?
还叫什么code review? xuby 写道 毫无疑问是 test.
质检组的人不会管你砖砌的是不是很"面向对象",也不会管你用了一个"资源"(比如一个铁锹)之后有没有"释放". 而且他基本上是黑盒测试,只管拿条大枪往墙上戳. test说白了只是一种工具，一种保证软件质量的工具，code review是个专业性和主观性都比较强的活动，用工具也只能发现那些条条框框的东西，如check style |
| 返回顶楼 | |
|
发表时间：2008-07-10
我们是采取小组形式的code review,这样占用的资源相对比较少。
|
| 返回顶楼 | |
|
发表时间：2008-07-10
review好啊，不review自己有时候头一发热，就不知道自己在干什么了。书读百遍，其义自现，我读不了百遍，百人读一遍就好了。
|
| 返回顶楼 | |
|
发表时间：2008-07-11
JavaJason 写道 下面是我和公司一同事讨论得出的一个方案，供大家参考（我们考虑的重点是可行性、实际效果和执行效率） 1． 开发刚开始的阶段，由TL和PM召集大家坐在一起进行几次review（至少3-5次） 其实这一条还有一个含义，减少返工 |
| 返回顶楼 | |
|
发表时间：2008-07-16
呵呵，Review的人能不能认真做Review是个问题。
|
| 返回顶楼 | |
|
发表时间：2008-07-16
最好有个check list， 用来保证coding style， class design等的一致性。(开发中自我约束)
然后peer review,由熟悉业务或者senior的人来完成。（开发完成测试前） 还有team review,把比较重要的更新集体检查（学习）（一个礼拜左右） 然后review应该有记录， 有改进。每次有不同的关注， 而且层次日渐提高 可以在building做一些自动化， 比如说用code source anaysis 工具 |
| 返回顶楼 | |
