打脸

3月16日，我在受到“异端攀岩者”启发后在简书上写下了4月份要实现“自动化测试覆盖率提高3%”的目标。今天已经4月27日了，我感到自己已经高高扬起了右手，准备自己打脸了。

过去的一个月里，我是每周都记得这个目标的。可怕的是，当我有了一个可以量化的目标后，我痛苦地发现“逆水行舟，不进则退”。到今天为止，自动化测试覆盖率不仅没有提高，反而降低了！

让我来分析一下问题出在哪：

1.共同目标的问题

为了实现这个目标，有6个人参与其中。虽然步子比我预想的要小，但每个人都是朝着这个目标走了一步的。为什么进展小呢？主要的原因是每个人手头都有对他而言更重要的事情，而这个事情又不那么紧急。例如，为了将明确跑不进去的代码排除在外，我需要一个运维的同事帮忙做配置。但第一天我发了email，第二天下午我没有收到他的回复后再次找到他，得知他前一天完全忽视了我的email。第三天他IM的状态一直away，也许在忙别的事吧！第四天他说配置好了。我也欣喜地期待第5天凌晨的自动化测试结果。第五天早上我满心期待，却发现exclude了两大块代码后结果没有任何改善。我有些犹豫着发了email告诉他我的怀疑。一天后他告诉我他也觉得似乎配置没有生效。然后，就周末了。华丽丽的一周多就这么溜走了。。。等我意识到问题得时候，时间已经不多了。。。

这一点和我们平时几个人一起合作一个story，完成一个版本是多么类似啊！ 当需要分工协助的时候，无论对某个人而言这个目标有多重要，时间多么有限，只要这个目标不是所有人共同的最重要的目标，事情的进度总是比估计的要慢。

也许一开始我就该告诉大家我们共同的目标和时间限制。而不是我心里一个默默的目标，都靠我去推动一个个的子任务，别人却压根就不知道有这么个明确的目标。

教训1:应该达成共同的目标，明确过程中每个人对目标的贡献和阻碍。

2.复杂度的问题

虽然我看到了很多废弃代码，也天真地认为它们可以很快地被大量删除，从而对减小测试覆盖率的分母有立竿见影的贡献，但实际情况并不是。

当一个开发负责人帮忙删除代码的时候，他删掉的只是其中两小块。也许我这个外行去估计有多少代码可以被删除，一开始就是错的。正如我们这些不写代码的人常常脱口而出：“这个需求不是很简单吗？”dev有时估计也只能笑笑："You can, you up"

教训2:应该让内行估计事情的可行性和复杂度，而不是外行（无论外行多么热情）。

3. 诡异的结果

现在我还不十分确定造成覆盖率降低的主要原因。但复杂的问题总是特别吸引人。我还会持续追踪下去，找到原因并想办法解决的。只是，遗憾的是，那应该是在5月了。

一次公开的自我挑衅以自我打脸落幕。这个教训，干脆而漂亮！