开发人员做代码变动需要得到批准

开发人员做代码变动需要得到批准

从理论上来讲，开发和测试是平等的，这个大家也都能接受，只有平等才能进行有效监督嘛。可是，“泥巴怎么捏”的权利在开发人员手里，他在大家都不知情的情况下对代码做改动，你能怎么样?还能找他打-一架?

在项目后期，不管开发人员出于好意还是出于对技术或者完美性的追求所做的代码变动，实际上都是项目的一个风险。很有可能他的改动中包含错误，也有可能他的改动会对其他模块带来不利影响，他不可能考虑得那么全面，所以，我们需要控制这种改动。从配置管理的角度来说，对变更的控制是项目的一个关键。项目必须在控制之中，而不能被某一个开发人员的“心血来潮”拖入泥潭。

微软这方面做得很好。到了项目后期，每一个代码的变动都需要经过评审小组的批准，没有得到批准而对代码做变动会被公开批评。在一个专业的小组中，被公开批评是一个很大的负面评价。这个评审小组的成员包括开发组长、测试组长、需求组长等人，他们每天开会来决定当前有哪些变动可以被批准。所以，你会看到，开发人员会小心地陈述理由以争取变动获得批准，他们的“随意修改”的权利已经被剥夺了。有的时候，当的确是因为编程.上的错误导致了一个软件错误时，开发人员想修正自己的错误，在争取批准的时候就会比较着急，生怕得不到批准。

这个制度巩固了开发和测试的平等关系，避免了产品质量的动荡，值得学习。

认真考虑用户的真实使用场景

我在项目组内的工作之一就是测试Toast，我是这个功能的Owner（负责人）。当你使用MSN的时候，你的朋友发消息给你，你会在屏幕的右下方看到一个小窗口，这就是Toast。我们的产品虽然不是MSN，但是是类似产品。

Toast虽小，可是我不敢含糊。从Toast的种类、触发条件、·显示内容、UI效果等出发，我编写了多个测试用例。几轮测试下来，自我感觉还不错。

可是在测试后期Beta用户报告的一个问题却让我有些惭愧,这个问题是这样的，的确，每次有联系人登录或者收到次对话的第条消息的时候，用户都希望看到Toast，这样用户能得到明确的提示。但是，从另外-个方面来讲，用户也不希望当前的.L作被中断，例如，如果用户在写邮件，他既希望看到Toast，也希望能够继续写邮件，用户的当前焦点不能变。这就要求Toast显示出来后，既要显示到桌面的最前，又不能抢夺用户的焦点。这个问题的价值很大。它让我看到自己的测试思维有一个盲区:用户的工作环境。这个工.作环境不但包括用户的计算机硬件、操作系统、办公软件、浏览器，还包括工作场景(scenario），就是用户的某一时间段的工作状态。

在测试环境.上，测试总有一个要求:单独的、干净的测试环境。这是没有错的，只有在单独的干净的测试环境中得到结果才有意义。但是，这并不表示我们不需要考虑用户的实际工作环境。从另外-个角度来看，我们还要考虑用户可能在什么场景下使用我们的产品，要设计出这方面的测试用例，以发现可能存在的问题。我们照样可以在测试环境中模拟出用户的办公场景，这与环境的独立性和干净没有冲突。

这样的考虑是不是有点多余?如果你现在的产品并不是商业软件，只卖给一个或者几个特定的用户（为讨论方便，我们称它为项目软件吧〉，或许你会有这样的想法。其实一点都不多余，项目软件的领域中也存在着竞争，项目软件的用户也会越来越挑剔，如果你能够为用户多考虑一点，就能为你的产品博得好的声誉，在竞争者当中脱颖而出。在竞争公司技术水平大体相当的情况下，这种胜出是由类似的多个细节组成的。

Non-goal（非自标)

在软件这个行当里，自然少不了各种各样的文档，例如需求规格说明书、概要设计、详细设计、测试计划、测试报告，等等。在这些文档里，一般都会有–个小节来叙述产品或者本文档的“目标”，例如需求规格说明书的这个小节里简明扼要地列出产品的主要功能和客户群。

我在微软.工作了一段时间以后，接触到–些文档，发现了一个有意思的细节，这些文档一般都有–个non-goal的章节，用以说明软件产品所不会实现的功能或者不在本文档讨论范围之内的事情。例如，你正在编写一个字处理软件的需求规格说明书，你觉得手写识别这个功能好是好，但限于技术能力，是你这个小公司无法实现的，你就可以把手写识别功能写到non-goa1中。再例如，你在编写一个产品的测试计划，你觉得这个产品的性能测试很复杂，需要另写–个测试计划，你就可以在non-goal中说明，性能测试不在本文档覆盖范围之内。

当时我只是觉得有趣，因为很少见到这样的陈述。馒慢地，我觉出它的好来了。任何一个软件产品，必定有它的功能边界，它只能实现一定的功能，不可能什么都可以做，non-goal可以打消一些不切实际的期望。另外，一个文档也只会侧重在某:一方面，清楚地描述出不在本文档讨论范围之内的事情，也可以分清文档之间的边界，节省阅读时间。

可能是因为计算机的威力太大了，有的时候它简直就是无所不能，这也给一些客户造成了一个假相，似乎只要他们张嘴，新需求就一定能实现。在国内软件业竞争激烈的背景下，客户可以不管软件开发的实际阶段（可能已经到了最后一个里程碑或者最后几天），不管需求是否符合实际（可能根本用不上），不管软件公司是否能够承受（可能软件公司已经不可能再做软件基本结松的修改了)，对软件提出不可抗拒的修改意见，有的修改意见甚至就好像楼房已经建到10层，来了…个修改地基的需求一样。我知道，即使在湍求规格说明书中增加non-goal，对这种情形也并没有什么作用，但或许对客户有一个心理作用吧，软件产品也只是普通的产品而已，不是橡皮泥，能捏成任何形状。

同事之间的审阅

如何提高代码质量，是·一-个经常被提及的话题。测试是软件质量的一道防线，是不可缺少的，而且是软件开发“三分天下”中的支柱之一。但是，如果能提高软件代码质量，减少bug总量，也就减少了软件的风险。

软件开发因为其工作的特殊性，很难进行管理。我的职位虽然不是开发，但我经常能收到列发人员提交代码的通知邮件，在这类邮件里，我注意到，都有一栏:窜阅者（Reviewer)。也就是说，如果你是-个开发人员，在你向代码服务器提交代码之前，需要找另一位开发人员来做审阅，在取得他（她）的同意的惰况下，才可以提交代码。如果发现了错误或者不完善的地方，斑当立即进行修改，再做审阅。

我觉得这样做的好处有:

(1）增强了开发工作的透明度。
(2〉在具体的开发细节上都体现了多个人的智慧。
(3）这是切实可行的监督方法之一。如果等产品都开发完了，再来审阅几万、十几万行的代码，简直就是不可完成的任务。

我认识一位建筑业的驻地监理工程师，我向他请教了他们是如何做监理的。建筑业的风险也很大，代码有的时候还能推倒重来，建筑是不可能了。他给我举了一个例子，他说，有一次监理一个立交桥，他们的工作仔细到对每一车的混凝土都做检查，并且都要留样。所以，建筑工人工作到什么时候，他们就要工作到什么时候。我想，这种严格的精神也需要在软件业得到承传。

同样，这种同事审阅的制度也可以迁移到测试上。如果一位测试工程师修改了测试工具、测试计划或者测试用例，也需要找另一位测试工程师来做审阅，然后才能提交，我相信这会提高测试工作的质量。

最大的收获-专业精神

可能有人要问我，在微软T.作的这-·段时间里，你最大的收获是什么呢?这是一个很好的问题，我要认真想一想。

我觉得我很幸运，到徼软后就赶上了一个好项目。这个项目在微软来说很小，却是“麻雀虽小，五脏俱全”，其包含了多种软件技术。我从M1就进入到了项日组，一直到最后产品的发布，全程经历了一个完整的也是成熟的软件开发流程，这种项目经验会认:我受益很大。

然而，我仍然觉得，我在微软工作的最人的收获是见到了一种专业精神，并受到了些许熏陶。

微软的工作氛围是很好的，无论是在中国还是美国总部，有很多优秀的员.7:，无声地做出了榜样。从邮件书写，谈话方式和语气，表达自己的观点，到对bug的态度，对变化的应对，对新东西的理解等等，从中都能发现专业之道。大家都是在努力地把事情做好，没有什么杂事搀和在里面。例如，前几天你对一个问题的看法错了，你会发-一个邮什承认自己错了;开会迟到了或者错过了会议，你会主动发邮件告诉大家原因并表示歉意;如果你需要重新启动服务器，之前你要查清现在的确没有人使用它，在发了邮件通知大家后，你才会去重启它，以免对他人的工作造成干扰;偶然遇到个不是你负责的模块的bug，你会把它告诉相关人员，而不是让它溜掉;在你解释了两遍之后，对方仍然表示没有明白，你不会露出不屑的表情，而是再解释·遍，等等。专业都是在细节中体现，专业精神体现在让事情做得更好的点点滴滴上。

说句大一点的话，见笑了，我希望我们国家能够有越来越多的专业.工程师，这样软件业才有希望。

在微软这样的大企业里，员T.都是很独立的，员.工之间在工.作上的联系，就好像是两个小企业的联系，很正式。只要是为了完成一项任务，没有什么别的考虑，目标就是一个:把事情做好。作为一名员.工.，他（她)的所作所为，一方面是在做工作，同时也是在展现个个体，每个人都想表现的专业和优秀。当他有了这种想法，就会对自己加以控制，向着专业的目标奔去，就好像自己给自己加了发动机，这种情况的产生大概就是近朱者赤吧。

我很难描述这种氛围是什么，大概是-种柔和而催人进取的氛围。我觉得，在这样的氛围中.T.作是一种幸运。更希望有更多的中国公司能提供这样良好的氛围。

最后：

1、点赞。防止以后找不到，想看的时候，在自己主页就能找到了，很方便;
2、关注我。让我们成为长期关系，下一个视频会分享更多的硬核干货;
3、本文章学习资源，均可以免费分享。

微信公众号：程序员阿沐。这样的好内容，里面还有近百篇。谢谢你的支持！

目前测试平台项目研发已经完成并且在Github开源，有兴趣的朋友可以去Github下载
https://github.com/ooqitech/ATP

不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！

一个用心码了这么多文字的人，往往渴望得到大家的认可。如果你觉得这篇文章对你有帮助，双击屏幕，给我点个赞呀！

开发人员做代码变动需要得到批准相关推荐

代码加密 android,Android 开发怎样做代码加密或混淆
原标题:Android 开发怎样做代码加密或混淆对于Android开发技术人员来说,隐藏代码或是混淆代码至关重要.试想自己辛辛苦苦赶工出来的产品,被其他开发者反编译后轻松拿走.放在哪里都是一件让人崩 ...
面向开发人员的代码安全指南
面向开发人员的代码安全指南该指南是腾讯开源的面向开发人员梳理的代码安全指南,旨在梳理API层面的风险点并提供详实可行的安全编码方案.基于DevSecOps理念,我们希望用开发者更易懂的方式阐述安全编 ...
Java自己文章只能自己修改_文章目录Java代码俯身指南，主要为Java开发人员提供代码复审参考，快捷有效提出修改意见。目的发现代码错误：一个人写的代码可能会有一些思想和设计盲点，多个人尽...
文章目录 Java代码俯身指南,主要为Java开发人员提供代码复审参考,快捷有效提出修改意见. 目的发现代码错误:一个人写的代码可能会有一些思想和设计盲点,多个人尽早的发现BUG. 统一代码风格:统一 ...
ChatGPT其实并不想让开发人员做这5件事情
前言 ChatGPT已经火爆了快半年了吧,紧接着国内也开始推出了各种仿制品,我甚至一度怀疑,如果人家没有推出ChatGPT,这些仿制品会不会出现.而很多人也嗨皮得不行,利用各种方法开始科学上网,用Ch ...
为什么开发人员需要代码签名证书来保护源代码？
作为一个应用程序开发人员,在投入如此多时间和精力后,你永远都不会再想为你的最终产品的完整性而担心.为了确保应用程序或内容在没有安全漏洞或经过任何修改的情况下安全抵达终端用户,代码签名证书已经吸引了大量 ...
Android开发人员的代码速查字典
2019独角兽企业重金招聘Python工程师标准>>> 为方便查找,已进行大致归类,其目录如下所示: Activity相关→ActivityUtils.java→Demo isAct ...
后端开发除了编码还要做什么_每个开发人员都应掌握的基本技能（除了编码）
后端开发除了编码还要做什么 Whether you are learning to code, looking for a new job, or just want to improve your ...
满屋花网页代码_成为更好的程序猿！2020年给网页开发人员的32条建议
全文共3315字,预计学习时长10分钟来源:Pexels 2019年已经过去了,对开发人员来说是充满挑战和机遇的一年.开发人员们学习和掌握了很多--像React.Vue.Angular和Svelte ...
python实现微信自动加群_为Python开发人员提供实时代码片段，Kite获1700万美元A轮融资...
[猎云网(微信号:)]1月29日报道(编译:孙家乐) Kite是一款为Python开发人员提供实时代码片段的工具,它在由Trinity Ventures领投的A轮融资中获得了1700万美元.最新版本的 ...

开发人员做代码变动需要得到批准

最后：

开发人员做代码变动需要得到批准相关推荐

最新文章

热门文章