“新瓶装旧酒”

王俊煜

“我觉得，你们还是应该下决心扔掉现在的包袱，重新开始。”视频会议对面的人说。大概是怕无意中冒犯到我们，毕竟这句话听起来像是说给失足青年的，他又补充了一句，“可能是我站着说话不腰疼吧。”

我们在讨论阅览室的iOS App，对面是苹果开发者部门工程师。这是一次一对一的技术咨询，属于苹果为需要扶持的App开发者提供的服务。我在苹果的官方渠道填写表单申请的。

我们当然需要扶持啊。我们正在开发App的两位工程师，一个月前还不会写iOS。一位是我们的合伙人范怀宇，我们一般管他叫范老师。我和范老师从2011年一起在豌豆荚工作，他是中国最早接触安卓开发的那批工程师，著有一本叫《Android开发精要》的书，其豆瓣评分一直是我们调侃的对象。我是看范老师的blog认识了他。因为安卓的开放性，当年我们对安卓都是真爱，可以说正因此我们才有机会在一起工作。时过境迁，范老师要开始学习写iOS App了。

明明擅长安卓，但正式开始开发阅览室App的时候，我们决定先做iOS版本。是没有困难也要制造困难的意思吗？也不是。定性和定量分析都可以充分支持一个判断。尽管安卓绝对用户量更大，那些喜欢认真阅读、对内容品质和体验有更高追求的人，还是更容易在iPhone用户里找到，他们也应该是最早开始使用阅览室的一群用户。

从前写安卓，是对技术的痴迷和热血;现在写iOS，则是对阅读对使命的热爱。

可以说，从前写安卓，是对技术的痴迷和热血;现在写iOS，则是对阅读对使命的热爱。一把年纪从头开始学习一个新的平台，让人感动。

范老师很自信，觉得没有什么编程语言是他学不会的，而且学习新东西本来也是乐趣。事实证明……他是对的。范老师和我们另外一个安卓工程师杨佳东开始自学iOS开发，没多久，我们就在他的手机上看到一个新的App了。

新手毕竟是新手。尽管不同平台在“道”上是相通的，作为资深工程师很容易上手，但iOS开发有一些特别入门的“术”。比如，范老师就一直没有学会如何把App打包放到别人的手机上，我们一开始只能拿他的手机来看，远程的同学只能靠想象—似乎他到现在也还没有学会，只是他把这个工作交给了佳东。

这也是为什么我预约了苹果的技术咨询。

苹果的工程师在开会之前并不知道我们是谁。让我惊讶的是，我一说“阅览室”，对方就知道了。原來他也看到了我们的“预售”，表示挺佩服的。他还说，以前住锦秋家园的时候可以搜索到我们办公室的Wi-Fi—豌豆荚2011年的时候在锦秋家园租了一套住宅办公。亲切的寒暄结束后，范老师开始介绍App现在的架构设计，介绍到所用的某个框架时，对方至少惊呼了三遍：

“你们用的这个也太老了吧！”

我们其实是在轻芒的基础上开发阅览室，而轻芒的前身又是豌豆荚在2014年前后开始开发的，也就是说，阅览室App虽然是个“新”App，但里面的某些代码已经是8年前写的了。被吐槽“古老”的框架，是8年前我们的工程师选择的一个由Uber开发的框架。要知道，8年前Uber还是引领潮流的当红公司。但以我们这个行业的时间维度，8年前简直就是上古时代—现在早就没有人在继续维护这些框架了。

那为什么要在一个老App的基础上开发呢？因为之前我们在产品规划阶段做的另一个决策，就是决定将轻芒在过去几年开发过的功能，如果可以，尽量“迁徙”到阅览室中。我管这个叫“大迁徙”。在吃完俄罗斯菜以后，我们决定阅览室“先做做看吧”。我负责产品规划，首先就是要决定这个App要包括什么功能。

“创业”就是要做新的事情，这好像是一个亘古不变的真理。我们这个行业尤其喜新厌旧。市场喜欢“全新”的东西，营销部门总是把这个词放在标题中，iPhone每年都有新款，Chrome浏览器每四周会发布一个新版本。我偶尔写写前端页面，大概几个月一次，差不多每次都得重新学习最新的开发框架。做事情的人也喜欢“全新”的东西。没有一个工程师愿意接手一个别人的项目。何况，我们之前的产品在商业上也不算成功，不保留之前任何的工作，全部推倒重来，也是合理的。

我不知道在大家的想象里，一个App的功能是如何决定的。在我过去的工作所建立的框架中，这既是一个创造性工作，又被严格的方法论约束，大概就像解一道几何题。这次，我在纸上画了一些设计稿草图，又往下构思了几条功能，感觉似曾相识，这不都是我们在轻芒已经解决过的问题吗？虽然App首页长得很不一样，但要解决的用户的具体问题，以及能想到的解决方案都没有什么区别。打个比方，就像是拿起卷子，发现这不是我以前做过的题吗？

连这个感受都是似曾相识的，我在专栏的第一期讲述过当我意识到“阅览室”这个想法和轻芒没有太大区别时的沮丧。我当时自圆其说的方式都可以沿用—一个稳定的系统，输入和外部条件没有变化，输出自然也不需要有变化。在这个案例中，输入可以认为是对用户的理解，这几年来有进化，但没有推翻;外部条件，可以说是市场环境和技术进步，我认为和一开始做轻芒时也没有本质变化。系统，也就是我的脑子，我也认为它作为一个决策系统，是足够稳定的。那么，我们就直接拿以前的答案来，不是也很好吗？

况且，这些问题我们已经解了六年了，这里面应该有很多宝贵的积累才是。

既然逻辑推导的结果是以前的功能就很好，那就用已有的功能吧。毕竟我们也不是典型的“创业”团队，违反“常识”的地方多了。所以，阅览室App第一期的规划，可以说大量工作都是“新瓶装旧酒”。

但也是有“全新”的工作的。比如我们做了新的视觉设计，我也为阅览室的新定位专门设计了2到3个亮点功能，还有围绕几个主题，比如强化“阅读习惯养成”和“社区氛围”等等做的小功能。补充一些理论背景，在整个行业充分竞争的背景下，一个App的大部分功能都不会是差异化的。比如，几乎所有支持上传头像的App都提供剪裁功能，但做这个功能并不能创造独特的、“非我不可”的价值。一般新产品在初期应该更着重自己差异化的、“非我不可”的部分，再慢慢补齐一些“没有不行”的功能。

所以，决定尽量“迁徙”我们之前的产品功能，其实是让新的App一开始就拥有比较完善的“没有不行”的功能，使其是一个相对成熟App的状态。需要做出亮点的，还是要做亮点。“新瓶装旧酒”，新瓶也要花很多功夫。至于推倒重来—人们总是觉得重来一次自己一定会比之前做得更好，但也往往无法正确预估自己的能力。我们上次大规模重写的时候，原计划花2个月，实际上花了15个月，质量是否有提升不得而知。

保留之前的功能而不是推倒重来，看起来是一个理智的决定，但也是一个充满风险的决定。我们要付出额外的财务成本才可以获得之前代码的使用许可，毕竟这是两个不同的公司。我们也难以预料将旧的功能改造成我们满意的状态需要花费多少时间，我们只是相信，总该比从头再来快一些吧。只能说，在已知的信息下，“迁徙”看起来是一个好的决定。至于最后来看是不是一个好的决定，以后才有答案。

范老师另外一个自信，就是觉得没有他看不懂的代码。但即使好脾气如他，我也不时听到他在我对面的工位上抓着头发说脏话。那一定是在读之前留下来的代码。之前做轻芒杂志的时候，受限于人手，不少功能和交互在质量上其实都做了妥协。现在，范老师和我制定了新的质量标准，如果一个旧的功能不费什么力气就可以符合质量标准，我们就会迁徙过来并启用，然后再逐步重构。否则，我们会先关闭这个功能。慢一点就慢一点，功能一開始少一点就少一点。

传承的另一种说法就是包袱。为了降低风险，我们反而决定将风险最高的迁徙工作放在最前面。这部分工作的难度和工作量都难以估计，数量、质量和时间无法兼顾。按范老师的说法，起码我们得先知道冰山底下有多深。我算了一下，过去在轻芒发布过的功能点大约有770个，加上规划中的总共有1600个，有一些功能由于产品定位的变化，在一开始就明确了不会保留;其余的功能点，到2月底为止我们做了彻底的整理，保留了其中的286个。冰山底下，看清楚了。

我借机做了许多处女座该做的事情，美其名曰“打好基础”。我在整理自己的计时单时惊讶地发现，我单单在整理已有功能并寻找一个较为漂亮的方法来组织整理上，就花了66小时。周梦婷听说后语重心长地和我说，她也是处女座，但她觉得一个人在多大程度上能和不完美共存，会决定他的智慧的高度。

听起来她的意思是我还有很大的进步空间。但，我们决定“新瓶装旧酒”而不是推倒重来，某种程度上也是选择和不完美共存吧。