你入职一家新单位，被告知需要维护一个老产品，经理找质管给你开通了SVN权限，告诉你迁出哪个分支，然后告诉你说，就在这个分支上改，添加一个新接口，以便支持H5 Video。

你去问干了快一年的资格更老的同事，他叮嘱你千万别动里面的代码，千万别管里面什么样，就在外面包一层，先交付新功能，其它的有时间再说，里面的逻辑十年没人动过了，没有一个人能说清楚怎么回事，你要是改，一不留神就遍地狼烟。

你怎么办？

@Mangiacapra

动完之后，会不会只剩下删库跑路这个结果了。

@李傅博

不动才10个bug，动完1000个bug。

@qqwenqqqi 

·理想的维护状态

用适配器的思维进行一点一点的重构，尽可能的熟悉业务逻辑，找出业务逻辑的缺陷，接着写文档，干擦屁股的活儿（这是在时间有限，只维护这一项产品的时候）最后这个项目就可以随意的揉捏了。

·普遍的状态

当然上面说的情况是理想状态，但是一般老板和pm有时间预算的，在这种情况下，普遍只有先从经理说的分支哪儿入手，尝试写H5 VIdeo code. 最后出来的结果有可能有BUG。只有BUG出现了从点到面去维护了，因为先让产品上线就是金钱。

·Boss希望的状态

1.如果是希望快速的开发出来走第普遍状态解决

2.如果是希望走产品质量优先走理想状态重构解决

·闲谈

从接手这个项目开始，你会发现代码不可控是多么的纠结和无奈，你在该基础上开发就很容易有BUG。所以接手这个项目的第一思维就是获取代码的控制权！从这个角度解释就会发现：代码的易读性多么的重要，要写通用的代码，写规范的代码，项目文档对交接是多么的重要。你为公司擦屁股，虽然是吃力不讨好的活儿，但这是对自己的负责，对公司的负责，对下一任程序员的负责。你不擦屁股，总有人擦屁股，优质的程序员普遍具有擦一切屁股的能力，还热衷于擦屁股。

@安晓辉，CSDN知名博主

一旦老代码没人能够把握，这些作为资产的代码实际上已经丢了，不再有价值增长，原本领先的优势随着同行们百舸争流的追赶渐渐失去。这是对企业是一种损失。读程序员其实也是一种损失。

自己不写文档却老抱怨别人的代码没文档，而碰见了有文档的代码却又往往弃文档如敝履。业界的代码和文档，少见匹配的。我们只能接受这个现实：代码即文档。

对维护老产品的程序员来讲，弄明白产品设计逻辑和代码实现逻辑是非常重要的，就只要如下两个办法：找到熟悉产品的前辈，让他给你讲讲。如果你找了产品经理，他只能告诉产品设计上如何如何。如果你找了程序员，他通常会说就是这样那样，然后说一句高深莫测又拉仇恨的话：看看代码就明白了。自己啃代码，啃代码，啃代码。

所以，也可能有在外围包装的办法，比如你封装一个本地的HTTP Server，用旧API拿到数据作为HTTP流转发一下就能支持H5 Video标签了。也可能很多情况都存在折衷的替代办法。

然而，能弄懂代码是如何实现产品和业务的，还是有非常重要的好处——对程序员来讲很重要的好处：文档是会过时的，代码是不会说谎的，读懂代码，你就真真正正明白了业务是如何实现的。对于没人敢动而又核心的老代码，你搞明白了，就占领了战略要地，唯有掌握核心业务和代码，才能彰显自己的价值。

除此之外，读代码也是非常重要的学习途径，尤其是经历过线上考验的代码，必然尤其过人之处。在阅读的过程中，我们可以学到很多东西，既可以学到业务，也可以学到设计。只要有心，处处都是成长的机会。最不济，也锻炼了阅读代码的能力，庖丁解牛之技成了，也可以在将来以无刃入有间，发挥用武之地。