@姚若舟在实际的工作中发现，刚开始写单元测试同事的代码中有不少行为都没有被单元测试覆盖，他因此在微博上提出，想了解大家的意见。@程墨Morgan在与雅虎前同事聊天时得知，雅虎的CEO在力推Scrum开发流程和扁平的管理结构，从而将这家老牌的企业变回创业公司的模式。针对两条微博，大家展开了深入讨论。

\

姚若舟在微博上提到实际工作中的一件事：#单元测试# 上周和同事讨论时，我发现他的代码有不少行为都没有被单元测试覆盖。他的解释是那些代码属于一些极端情况的出错处理，用单元测试去覆盖不值得（需要额外的隔离）。我问他为什么不删除这些代码，他的回答是删了代码评审过不了。我不认同，不过考虑他刚开始写单元测试，就忍了。大家怎么看？

\

大家针对这个问题给出了各自的意见：

\

\

吴穹adam：不一定所有行为都必须在单测覆盖的 这个要看分层测试的规划是什么。

\

Robin圈：1. 首先，要清楚，在该极端情况下，应不应该出异常。有时候出异常才是期望结果。之后，我们才能决定评审的标准。2. 是否测试是根据价值来分割的，而非事件发生的频率。比如站点初始化，极少发生，却很有测试必要。极端情况，类比分析。

\

Ethan苏于登：想问下总体关键，价值在哪里？如果那段代码无价值，就跟若舟想法一样，或许可以删掉。如果代码审核流程不能合适体现价值，应该考虑修改？如果那段代码确实有价值，因为边缘状况确实有可能出现，那加单元测试覆盖其实是很有价值的。

\

林曙湧：黑盒测试有一种技术基于风险的测试（RBT），其思想也许可以借用到白盒测试。其基本思想是测试不可能控制全部风险，所以必须面对风险作出抉择，合理安排你的测试投入。其基本公式是 风险=问题发生时的破坏性×问题发生的可能性。所以不能只考虑风险的单个因子。

\

steedhorse：如果能用20%的付出获得80%的测试覆盖率，我觉得这是好事，而不是坏事。相对于不写单元测试，这也已经是不折不扣的“质的飞跃”了。然后，哪20%是可以牺牲的呢？我觉得错误处理就属于可以牺牲的。很多时候错误处理的目标仅仅是fail fast，即让程序当场死掉，而不是带着错误继续运行，然后在其它地方莫名其妙地死掉。fail fast更多只是一种对待错误的策略，并不强求程序有确定的行为。所以我觉得在单元测试中这属于可以牺牲的部分。

\

\

姚若舟针对实际的情况，对以上微博做出回复：

\

\

姚若舟：回复@吴穹adam: 就我提到的案例，代码行为我觉得比较适合在单元测试中覆盖，而且也比较高效。不知道分层测试的规划主要是指哪些方面？

\

姚若舟：回复@Robin圈: 就我的案例来说，我觉得所谓添加测试价值不高更像是一种托词和惰性吧。其实，那些代码被使用的机会不是很极端，但是加测试需要做一些隔离，甚至是一些代码抽象，所以就不愿意了。我很赞同TDD的观点，就是没有失败的测试，就不应该写出任何多余的代码来。

\

姚若舟：回复@Ethan苏于登: 我很认同。不过，这些改变或许要慢慢来吧。

\

姚若舟：回复@林曙湧:我在写单元测试的时候，不会考虑加或不加某个测试的风险和危害有多大的。想到有必要的测试就加了，反正单元测试都很简单直接而且运行很快。如果不加，一般都是被测试代码不需要的行为。如果单元测试充分的话，会使集成测试的数量大大减少。那时，根据风险评估来考虑如何添加测试，也许不再重要了。

\

姚若舟：回复@steedhorse: 刚开始这样做，我可以理解。不过复杂的遗留代码系统中，大概没有什么错误处理的是可以fail fast。以后，还是应该尽量用测试来覆盖这些代码吧，不过牺牲他们了。

\

\

大家对这个话题进一步讨论：

\

\

吴穹adam：测试金字塔我认同的，单元测试应该多写，但还是要以风险为依据针对正确的单元来写出可维护的单元测试。

\

杭州李云：作为专业的软件开发工程师，那些边边角角一定要覆盖到，否则将大大降低单元测试的效果。这容易形成错误的推理：“单元测试因为边角不覆盖，所以测试效果不好；测试效果不好，所以单元测试效果不好；测试效果不好，所以单元测试不要那么认真。”

\

@不许说话: 另外，按理说，单元测试是敏捷方法必备实践。而ACRD推行的scrum是敏捷方法的一种，自然必须首先符合敏捷的实践，然后才谈得上scrum。现在，scrum也几年了，敏捷实践呢？如果不能先一般性的敏捷实践，再scrum，我看着邪路就回不了头了。

\

\

程墨Morgan在微博上提到关于雅虎管理结构改革的话题：和雅虎前同事聊天，得知新CEO在力推Scrum开发流程和扁平的管理结构，其实就是把一堆中层管理者推到需要处理技术问题的地位。很自然，在官僚体系中已经丧失技术能力的管理者日子不好过，估计很多人只能离开。CEO这招够狠，把雅虎变回创业公司的模式，这才是改头换面。引起大家热议。

\

\

agile123：#Scrum-FAQ#Scrum适合哪些企业？对犯有大企业病，需要二次创业的企业Scrum是一剂猛药。坚持透明，取消项目经理和外部官僚干涉，让研发主导权更多向一线研发骨干（而非不能增值的官僚）倾斜，正如此例 //新CEO在力推Scrum开发流程和扁平的管理结构，其实就是把一堆中层管理者推到需要处理技术问题的地位。

\

TingyiWu：我五年前面试一位从雅虎美国回国的应聘者时，就听说雅虎在搞scrum。五年过去了，旧瓶装旧酒?文化的变革不是靠搞掉一帮人做一场革命就能解决的。光是术的变化，只是看起来热闹。

\

水木玉弓：互联网时代可以辗平一切臃肿和低效，包括政府和企业的官僚组织，只是个时间问题，此事提醒所有人时刻保持自己的竞争力。

\

胡德民PeterHu：多数管理者干久了，脑袋里只有\"控制\"两个字。只有回到前线，才知道啥叫做\"解决问题\"。当一个企业\"控制流程\"的复杂度逐渐超过\"解决问题\"的灵活度，就差不多要走下坡了。//@王忠杰rainy: 这是好招。学校里，也该把教授们逼回课堂讲台，把导师们逼回写程序做实验，总之得跟学生们一道摸爬滚打。

\

皮皮的一天：这点上思路不错，但动作有点快了 太多reorg导致最底层的技术人员怨声载道啊 最搞笑的是在北京被layoff掉的都是打拼在一线的屌丝苦逼们，其中有很多很有实力或潜质的童鞋。

\

晁晓娟：管理者一定要和团队一起下水，否则在岸上就失去自己价值，在创业公司干部太多是非常可怕的！

\

火星人陈勇：很多人在公司做久了，都希望走官僚体系的道路，不必再费心投入到产品、市场、技术这些事情上去。实际上，离开了这些，人会越来越醉心于官僚体系，最后变成对公司实际上没有用处的人。看看乔布斯在苹果的回归就知道，如果乔布斯当年也是一个官僚体制中人，苹果多么危难都不会邀请他再回来。

\

大卫张33：回复@程墨Morgan: 看来你挺有信心的，我不反对走这一步，应对当前的困境这可能是好办法。公司就像生命，长得不能太快，太快了是癌症；也不能停下来，停下来面对的就是衰老死亡。具体如何，拭目以待！

\

徐毅-Kaveri：雅虎应该是挺早就在做scrum的，可能以前做的范围有限吧。大公司都有政治，scrum的问题在于它需要也会把一些人的座椅给拆了，可是在已经有很深厚政治根基的大企业里，交锋数百回合后，拆掉的到底是码农的椅子还是某些更大牌更贵重的椅子，就是见成败的关键点了。

\

蓝色流星SH：不管用什么办法目的都为完成产品，做到早发现早治理，经可能缩短产品周期。不同公司环境不同，实施方式不同，scrum框架值得借鉴，困难是难免的，主要看管理层的推行力度，执行者更需要目标明确。

\

agile123：这个好！大势所趋。管理扁平化思想传入中国好像已经十多年了，国内IT企业去浮躁还需时日 //@拉尔夫沈: 扁平化是淘宝技术部推行了两年多的管理思路，如今大淘宝技术团队大多扁平化，尽量取消10人以内脱产的技术主管，扭转工程师三五年就脱产搞管理的浮躁心态，这是让公司和个人都发展更长远的双赢策略。

\

崔昊Niky：技术公司，管理层要学学技术；媒体报社，管理层要写写稿子；公关公司，管理层要搞搞客户。是这个意思吧？我觉得这是挺对的事儿，怕就怕，人家觉得你这么做，是不务正业。ps：希望yahoo更好！

\

搜狗郭昂：让一个公司保持活力的方法是永远都有做不完的事情并且每个人都在做着实际有效的事情。而不关注技术和产品的中层会拖慢整个公司的效率。

\

互联网猎头judy-deng：这个的确是狠招！不过作为软件技术的人才，首先得把技术做深了，达到资深架构师的能力，再慢慢转到管理，这对未来的技术管理的职业生涯会好些，走得稳些。

\

RayChase：雅虎的改革也进行好些年了，雅虎对互联网的影响至今仍然非常大。一个扁平化、一个技术管理者，希望这次可以靠谱。无论怎么说，雅虎在我们这代人中还是有特殊的身份，好歹我们是听着杨致远的牛逼故事长大的。

\

\

你对单元测试以及雅虎的管理结构改革有何意见，欢迎参与到讨论之中。

\

推荐微博：@姚若舟

\

推荐理由：拥有十多年的软件开发经验和多年的项目管理经验，目前任职于欧特克（Autodesk）中国研发中心担任项目经理，提供内部团队敏捷实践的指导和培训。

\

欢迎读者关注@InfoQ官方微博，推荐热门话题，可私信@InfoQ，同时请您说明推荐理由。