梦断代码--一个程序员的自白（九 完）

本文谢绝转载 http://www.weibo.com/0x2b

Protein的性能瓶颈主要是在runtime，而runtime是基于FBX来写的。FBX已经停止开发，而且改动代价太高，因此，美国那边打算把把FBX从runtime中去掉。这是一个大工程。当时Protein的新经理M也刚来不久，我们都有点担心资源不够。这时，美国的架构师也忙于新的项目，也没时间给出Protein的新设计，中国这边就只好先做起来。在同事W的一再劝说和鼓动下，我决定努力一下，用息壤来替换FBX。下决心的根本原因是当时就觉得息壤说不定有机会替换ADP，那才一直是我最想做的事情。

从11月份开始，我就在息壤中做准备工作。为息壤写document comments，写设计文档，sample文档，写一些Protein--版本4.0--的高层设计。这个新设计有一个让人非常痛苦的约束，就是文件格式和API不能做任何改变。后来在我们的争取之下，API放松一点点，只要不要求修改用户代码就行--实际上，我们后来还是顺便纠正了一点点细小但很恶心的API问题，比如列表的元素个数至少是1这样诡异的设计。我把这种限制下的设计叫做戴着镣铐跳舞。写文档和设计花费了大量的时间，后来还是W全部整理了之后给美国的架构师S看（当时美国那边只剩S一个人了）。不可能设计全部做完了才开始编码，美国那边也需要一个严肃的原型，以便可以测量出可能的性能改进，进而评估项目是不是要做。因为当时转向到云计算的氛围已经很浓了，要不要继续做Protein已经打上了问号。从11月中下旬开始，我和另外两个同事开始为Protein写基本的runtime的支持部分。差不多到元旦，运行时管理的部分就已经写完了。这时TD做了几个美国那边最关心的case的性能测试，最好的情况快了两个数量级。除了一个预期不会有改进的部分（实际上也是改进巨大，只是在当时的case里无法反映），其他的case也基本上快了一个数量级，这让美国那边非常兴奋。虽然当时公司要把大量的资源抽去做Cloud相关的项目，但是因为这个极好的性能报告，Protein
4.0还是立项了。这是我们第一次争取到一个本来很可能取消的项目，也是第一次，在我们这个部门内，由中国这边全权来做全部设计的项目。这对我们当然是个巨大的鼓舞。现在想来，之所以能拿到主动权，是因为我们做的早，美国那边还忙的不可开交的时候，我们已经为第二年的事情开好了头。如果没有息壤，也很难在这么短的时间里做出可以提供这么多性能测试的结果。

接下来的就是写文件包管理的部分，到春节前就基本上完工了。考虑到我们并非整个团队全部投入到4.0上，新的4.0能工作，并全部跑通，只花了整个团队1个半月的工作时间。这是我在公司所有项目中从未有过的速度。高峰时期，我们平均每个人一天可以提交四五次代码。虽然我们仍然会骂Protein API的设计很烂，会批评以前的实现代码为什么那么糟糕，但是我们还是尽力在允许的范围内做大最好。接下来的任务是通过回归测试，这花费了我们相当多的时间和资源。这是以前的设计中各种特例的恶果，还有就是针对实现和现状测试，而不是针对预期和设计来测试带来大量的虚假错误。为了通过那几百个回归测试，我们还是付出了相当多的努力的。到回归测试差不多都通过时，我发现因为前期为了能够表现给美国那边看，和M一味地赶进度，代码的质量很让人不满意。在兼容以前各种奇怪的逻辑和行为的时候，我们已经不得不引入了许多混乱和复杂性，如果我们不能把这些混乱和复杂性控制住的话，就会伤害到软件的质量和阻碍我们进一步的改进。代码改进越困难，我们就越容易丧失对代码质量的警惕性。我批评的第一个目标是单元测试。

在xirang中，我写了比较完整的UT，我想这足以作为如何写UT的范本了。但是，同事们完全没有正确地去写UT，即对每一个API，都要根据给定的输入，检测期望的输出。仍然按照以前的路子，以写功能测试和集成测试的方法写UT，既不在意测试用例的独立性和隔离性，也不在乎是否做了IO和执行时间。还是使用了我一再强调并反对的一杆子到底的测试方法，那会遇到执行路径的组合爆炸问题。测试数据也不是那种精心***的，而是随便抓来的掺杂大量噪声的数据。当时的UT时间已经100多秒，而且还有快速上升的势头。我当时和M提出来，质量有问题，必须停一下，补上质量的欠债，否则后面的工作可能会遇到很多麻烦。但是M强烈反对，他打算投入更多资源去完善回归测试。这在我看来是及其低效和不可行的。当时还有一个开发X，也支持M，这让我很意外，也很难理解--我们过去的质量声誉并非很好，也为此饱受折磨。我们在之前的Protein开发中，单元测试最快的也要40分钟。我不能理解，为什么程序员能忍受？为什么不把这个看作是一种致命的错误？我是每次必抱怨的，从不掩饰。

4.0的UT执行时间必须被降下来，而且要降到1秒之内，这是可以做到的，也是我们必将做到的。我提出停止其他任务的要求其实是在漫天要价，也得到其余同事的全力支持，但我想得到的不过是制定质量改进的计划和任务，并且，至关重要的一点是，制定任务完成的验收标准。最后，妥协的结果是削减了一点其他任务，增加了质量改进的任务。但是关键的，为质量改进任务设定验收标准，M死活不肯。结果是一些人确实改UT了，但是换汤不换药。我又不得不自在完成自己的任务之余，再去改进那些有问题的部分。这个过程中因为触及了很多X写的部分代码，他可能因此对我很有意见。但是，我从把xirang带进Protein的时候开始，就多次说过，我们是集体代码所有权，xirang不再是我个人的代码，是所有人的，任何人都可以改动代码，无需先告知我。在改进过程中，我重写了X实现的AdpFs,和相关的archive。X的实现还是用ADP的api来操作的，不但慢，还有其他可靠性的问题，我直接用xirang里已经有的ZipFs来实现了。最后，我们终于把UT的执行时间降到了100多毫秒。

除了AdpFs，我还花了两周，把ADP中的DataStore类重新实现了。这时，除了残存在接口上的一些微不足道的类型（主要是String）外，ADP已经被彻底地从Protein中驱逐出去了，连带的，一个叫AdpPlugin的project也被我们彻底删除掉了。ADP花了三年时间，20多万行代码（不含TD的代码），数十个人年;xirang 2万3千行代码，数个人月，交付的功能比ADP还多。

UT的改进结果其实我是很不满意的，以改进UT为契机，反向推动4.0的设计和实现改进的目的也落空了。因为受不了恼人的复杂性和频繁的错误，以至于我们在后一个月又做了两个大范围的代码改进。效果不错，但是离我的期望还差距很远。其实我改进质量的终极目标是为Protein的下一版腾出空间。Protein的局限和危机是客观存在的，如果我们只是完成了预期的目标，那么来年被抛弃的命运是可以预知的。但是，我们又受到了很大的限制，不能放手施为。因此，在我的计划里，就是我们通过远远超前的进度，留下足够的时间，然后在今年多做一个版本。我设想的新版本是不改变文件结构，但是提供全新的模型和API。按照往年发布周期的惯例，我们有充足的时间来完成新版本。当今年正式集成时，我们将发布包含两套独立的API的Protein。我们不用刻意去宣传新版API，只需引导用户去选择即可，让用户的选择来为我们投票。一旦新API发布，我们就可以很容易做一个特别适合云存储的版本来。这样，就算抱上了公司云计算的大腿了。我们就有极大的机会和资本将xirang的技术推介出去。

然而经理M并没有这样的野心。虽然他也预感到Protein将来的地位岌岌可危，却缺乏为长远谋划的行动，而是安排了大量的资源和任务去做产品的预集成。这让我和一些同事颇感失望。ADP被彻底删除只是我个人的胜利，不是Protein的。Protein必须在API和存储格式两个方面取得根本性的变革，并拥抱Cloud才能生存。可是，因为我们的弱势地位，导致我们没法先先向公司抛出设想，然后争取立项和资源，再进行开发。我们成功的唯一途径是压榨自己的产能，先期做出成果，展示给美国那边看，然后才能获得完善的机会。一个可能的机会，正是我们前期高速运转的动力所在。本来，到6月份，我们就完成了所有的工作，只需一两个人处理修Bug，合并和集成的事情就足够。可惜，各种在我看来没什么价值的任务夺去了我们所有的时间。我认为M应该为此负责，并且他也为自己挖了一个坑。

接下来的时间，我们去做各种组件和产品的预集成--除非产品发布，否则这是个无止境的工作。给外界的映像我不得而知，但是我猜多半是认为Protein的今年的开发全部结束了，所余不过是修修零碎的Bug而已。在我和W的努力下，到7月底才开始讨论新API原型的事，然而一切都太晚了。到了8月，我，W和测试K都被调到新成立的A360项目，这其实意味着Protein已经没有机会了。但是更大的打击接踵而至，8月24号，公司裁员，M，W和TD的lead都被裁了。Protein受到致命的冲击，一下子只剩下三个人。我们这些留下的人不但有兔死狐悲的感慨，也有卸磨杀驴的愤怒--那些进度慢的项目反而没受到什么冲击。接下来，Protein合并到另一个叫CM的项目中去了。到十月份，Protein的Lead，Olivia主动去了另一个部门。在十月底的部门重组中，Protein只剩下一个人在做维护和修Bug的工作了。Protein团队至此彻底烟消云散。这让我们觉得，过去大半年的努力不过是一群幼稚的程序员闹出的一出笑话。

尽管Protein已经结束，但是回顾过去一年的时间，我觉得需要特别感谢三个人。第一个是Jessica Cao，没有她的努力，我们中国这边可能不会有机会尝试做新版的Protein。其次是Scott Morrison，美国那边的架构师，他有出色的能力理解我们的设计和意图，也充分地信任和放权给我们。最后是Olivia Wei，没有她的一再鼓舞和劝说，xirang只会是我个人的业余作品。没有她做的大量文档化和解释工作，xirang也不会那么快被接受。Protein团队的其他人对我的支持和肯定，我也会永远铭记在心。无论如何，就我个人而言，做Protein
4.0的过程，是我在这家公司最难忘的一段经历，虽然中间并不轻松，结果也是个悲剧。

R.I.P， Protein！