到底应该是谁review谁？
Review，中文里应该是审查，检查的意思吧。
如果有一个菜鸟和一个高手，那么由高手review菜鸟的工作应该是理所当然的吧。因为只有这样才能检查出有没有问题，review的结果才能然人信服。
但是，这里面也存在着问题。那就是，review的结果完全被高手的个人因素所决定。如果同时有多个高手的话，每个人review的标准肯定也不一样，那么review的结果和质量也会因人而异。
这其实也关系到review的目的这个问题。是reivew好坏呢，还是对错呢？针对好坏这一点上，应该说没有什么统一的标准，永远有更好的。但是在一个项目里，必须要有所定义，否则设计永远无法结束。
定义好坏其实也就是定义标准啦。根据预算，期间等等因素确定开发的流程，包括文档的写法，编码的规范等等内容。这些都有很多例子可以参考。而这些标准一旦确定下来以后，就没有什么可以讨价还价的余地了。一句话，必须要照章执行。
而review什么呢？就是review项目中产生的成果（文档、代码等）是否符合定义的标准。也就是只有2种结果，符合还是不符合。
那么，如果是依然由高手review菜鸟的话，个人因素还是无法排除。为什么呢？ 因为再详细的标准定义也只能是一个方针，类似于宪法一样。在开发之前自然也不可能事前确定一个功能的设计文档里面包括什么内容。连有没有这个功能还不得而知呢。
用宪法来判断一个人是否犯罪，恐怕是不现实的，所有才会有各种分门别类的法律出台。那么开发流程中对应于法律条文的内容是什么呢？ 大家听说过checklist这个名字吗？ 我只在对日开发中见过，其它的项目不清楚，估计也有类似的内容吧。
简单的说，checklist就是某具体一个成果（文档、代码），需要满足的具体规范（这是我自己随便定义的，不是规范的解释哈）。而checklist应该在该成果开始执行之前就已经确定下来。否则执行的人怎么知道自己做的对不对啊，对吧？
这么看来，checklist其实有点像是测试式样书。只不过对象是静态的文字和代码，而不是动态的功能。
举个文档的例子。
文档标准（宪法）里面规定，文档必须有它所参考的文档名称。
而某个文档的checklist（刑法）里面，可能会有这样的定义：
“参考文档是基本设计书，画面设计规范和数据库设计书”。
那么，写这个文档的人就应该知道，自己应该从上述文档中查找相关的内容。为了证明自己的确是这么做的，他也需要在正文中注明参考的文档与参考的内容。比如这个逻辑的设计是来自基本设计书A功能、这个画面是参考了画面设计规范中的规范3、这个SQL是参考数据库设计书的A表和B表……等等。
Review的人呢，就要检查它引用的文档是checklist里规定的文档，以及它所参考的内容是否准确无误。而至于这个逻辑的设计是否正确、这个画面的设计是否方便操作、这个SQL语句是否有效率问题则不在review的范围以内。因为review是针对对错，而不是好坏。
这里面有两个难题。
第一，写一个文档之前怎么知道checklist的具体内容呢？ 比如我怎么知道这个功能要用到这个表，要参考到那个文档呢？ 解决
第二，那么怎么判断好坏呢？
如果有一个菜鸟和一个高手，那么由高手review菜鸟的工作应该是理所当然的吧。因为只有这样才能检查出有没有问题，review的结果才能然人信服。
但是，这里面也存在着问题。那就是，review的结果完全被高手的个人因素所决定。如果同时有多个高手的话，每个人review的标准肯定也不一样，那么review的结果和质量也会因人而异。
这其实也关系到review的目的这个问题。是reivew好坏呢，还是对错呢？针对好坏这一点上，应该说没有什么统一的标准，永远有更好的。但是在一个项目里，必须要有所定义，否则设计永远无法结束。
定义好坏其实也就是定义标准啦。根据预算，期间等等因素确定开发的流程，包括文档的写法，编码的规范等等内容。这些都有很多例子可以参考。而这些标准一旦确定下来以后，就没有什么可以讨价还价的余地了。一句话，必须要照章执行。
而review什么呢？就是review项目中产生的成果（文档、代码等）是否符合定义的标准。也就是只有2种结果，符合还是不符合。
那么，如果是依然由高手review菜鸟的话，个人因素还是无法排除。为什么呢？ 因为再详细的标准定义也只能是一个方针，类似于宪法一样。在开发之前自然也不可能事前确定一个功能的设计文档里面包括什么内容。连有没有这个功能还不得而知呢。
用宪法来判断一个人是否犯罪，恐怕是不现实的，所有才会有各种分门别类的法律出台。那么开发流程中对应于法律条文的内容是什么呢？ 大家听说过checklist这个名字吗？ 我只在对日开发中见过，其它的项目不清楚，估计也有类似的内容吧。
简单的说，checklist就是某具体一个成果（文档、代码），需要满足的具体规范（这是我自己随便定义的，不是规范的解释哈）。而checklist应该在该成果开始执行之前就已经确定下来。否则执行的人怎么知道自己做的对不对啊，对吧？
这么看来，checklist其实有点像是测试式样书。只不过对象是静态的文字和代码，而不是动态的功能。
举个文档的例子。
文档标准（宪法）里面规定，文档必须有它所参考的文档名称。
而某个文档的checklist（刑法）里面，可能会有这样的定义：
“参考文档是基本设计书，画面设计规范和数据库设计书”。
那么，写这个文档的人就应该知道，自己应该从上述文档中查找相关的内容。为了证明自己的确是这么做的，他也需要在正文中注明参考的文档与参考的内容。比如这个逻辑的设计是来自基本设计书A功能、这个画面是参考了画面设计规范中的规范3、这个SQL是参考数据库设计书的A表和B表……等等。
Review的人呢，就要检查它引用的文档是checklist里规定的文档，以及它所参考的内容是否准确无误。而至于这个逻辑的设计是否正确、这个画面的设计是否方便操作、这个SQL语句是否有效率问题则不在review的范围以内。因为review是针对对错，而不是好坏。
这里面有两个难题。
第一，写一个文档之前怎么知道checklist的具体内容呢？ 比如我怎么知道这个功能要用到这个表，要参考到那个文档呢？ 解决
第二，那么怎么判断好坏呢？
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/378235/viewspace-696173/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
第138回 推荐商品
下一篇：
到底应该是谁review谁？
请登录后发表评论
登录
全部评论
