页面

分类

梦断代码--一个程序员的自白(九 完)

2014/4/25, by wingfire ; 分类: 其他; 0 comments

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,X和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!

添加评论:

 
 the email would not displayed
 

您可以使用 Markdown 语法。

您必须启用浏览器的 JavaScript 功能才能发表评论。