程序员：如何接手垃圾代码？
曾经有一段「垃圾代码」放在我的面前，我没有拒绝，等我真正开始接手的时候我才后悔莫及，程序员最痛苦的事莫过于此！当然，这些都是改编自周星星同学的经典台词，不过相信读者看完今天的讨论内容，应该也会有同感，接手垃圾代码实在是一件太痛苦、太折磨人的事情！
本期移动精英开发群讨论的话题就是「如何接手垃圾代码？」主持人是国内某跨境电商平台 iOS 开发的负责人曹理鹏，文章系国内 ITOM 管理平台OneAPM整理：
曹理鹏：大家好，我叫曹理鹏，现在在一家跨境电商的公司做 iOS 开发，此前的确接手过「垃圾代码」，首先简单分享一下这个项目存在的问题（针对 iOS开发）：
1.使用老式框架 ASI，并且没有做任何封装和抽取；
最近的时间都是在「填坑」，填了一个有一个，导致自己都快没信心了，所以就有一个很强烈的想法，谈谈如何接手垃圾代码的问题......
李小三：你们见过 把 doc 文档放工程里的吗？你们见过一个 controller 里有1000行的 UI 吗？一个挺复杂的界面有很多视图。我接手的代码，一点注释都没有，自己连猜带蒙把注释加上了，简直......（后续吐槽省略）
马方华：这种情况我以前搞过，不影响功能的情况下，我会写个编译宏。正常的下跑老代码。另外的慢慢把新代码加进去。
沈钦伟：我是在保证项目能正常运行情况下，慢慢改里面的，等我新改的全部能用了，就把老功能迁移到我的新代码上。不过，有些东西，这个老项目 Bug 是越改越多，动的时候需要小心翼翼。
丽娟：我以前也接手过外包代码，我先把相关bug改好，再一点一点抽取代码，有次一个页面同样的接口分别写了四五遍。
蒋连成：我的做法是，首先不要过度优化，做到相关逻辑，把相关逻辑提取出来优化。暂时无关的逻辑先放着。从小到大一点点来，先把可以复用的 view 什么的，一点点提取出来封装。比较忌讳的是一上来就想着全部优化，过度优化往往会「吃力不讨好」。能用是最重要的，其次才是好用！
马方华：写代码的时候，我一般看下微信classdump后的头文件。看他们怎么写。类是怎么封装的。然后再自己写，自己写的可能不是特别好。
神州租车：重构还是要理清楚业务比较好，要不然改了也是一堆 bug。再者，我觉得一切还是以原本业务为核心内容，再去对应代码比较好点吧。
曹理鹏：我们一般都是一两天就会进行一个小的回忆，统计修改好的和近期要处理的问题。不过，每次改完之后有种刚刚看到太阳又要天黑的感觉！
午夜修铃：重构，我理解是一个程序员的基因，是写在骨子里的。每个项目所在的环境不一样，所以代码的质量也不同。一般的外包，对代码质量要求很低，注重的是时间。所以写的都比较差。这个是毋庸置疑的。不能用这个来评价一个程序的水平。再者，刚说的一个功能写了多次，主要问题不在重构，而在沟通。
程序员是一群「偷懒」的人，累多了，才会去想办法偷懒，咱们这次讨论，重点不是接手与否，而是你碰到了后，如何处理？
阮涛：先跟着断点走一遍，理解之前的逻辑才好动手改啊。
腾讯微信：遇到这种代码我一般是不会接手的，就算接手了也是新的功能用自己新的框架。
马方华：少写广播。感觉这样改代码也方便好多，
沈钦伟：其实好多项目是功能优先，时间越短越好。决策层看的不是你代码写的多么漂亮，是功能有没有实现，尤其是外包项目！何况好多项目都是没到2.0就死了。
王云振：对于界面复杂的 Controller，是不是可以考虑把界面一块一块的封装成一个View。
曹理鹏：也就是 MVC 的思想去改！
蒋连成：一般情况下，是将每次功能相关的逻辑优化，该提出来的提出来，该复用的复用。一个模块一个模块来。不熟悉的逻辑，尽量不要动，可以先改改结构。
比如将一些东西单独封装到 category 中，逻辑不动，只是位置移动。
午夜修铃：我理解差一点的代码，不只是重构，就好比刚刚主持人说的，问题其实很多。要一条一条梳理。如果我遇到，第一步，可能是先处理目录结构，把目录调整好。
Eric 胡：目前我们公司用的是 MVP 模式。
曹理鹏：不知道是否有人，边改边抽到一个新的项目里面，当新的项目成型了就废弃老的，不知道这样算不算？
蒋连成：测试怎么办？测新项目还是老项目？发版是发新的还是老的？首先，时间会很长，你需要两头兼顾。
丽娟：最好还是一份代码，两份代码太累了。
Eric 胡：好的设计模式感觉对新人来说压力太大。
曹理鹏：每个人都说说遇到的问题吧，或者个人的经验！
李小三：代码尽量要统一。
午夜修铃：我遇到比较差的，或者是很别扭的（不一定是差，只是很别扭）
1、修改目录，修改成我认为看着舒服的，一般这一步过去，就大概知道有多少是重复的了。同时找东西会方便些；
基本都是遵循从大到小，从整体到局部的方式。
王岳明：我说的比较实际的啊，勿喷！垃圾代码肯定会有，特别对于大型项目，最重要的是稳定。接手垃圾代码当然比较恶心，但需要从时间成本和人力成本上去考虑，只有资源充足的情况下才去做重构优化，否则最好还是以平常心对待。有代码洁癖的同学，新增代码最好按代码规范来写，老代码能改则改，实在维护不下去了则必须重构。
Eric 胡：我的第一个观点就是，绝对不要出现硬编码，所有的配置也不放在代码里。前期要确定好框架，不要想着以后再重构。如果功能稳定，我会在他的设计思路上进行维护，新功能我会在自己的 library 里去实现。
Waizau：以前是，有时间的才会重构再继续开发，不然实在会一边写自己的代码一边骂的。
李小三：接手，先别动，慢慢修改，以完成任务为主。不是一朝一夕的事情
马方华：垃圾代码的框架一般很难改。一改就是两三个 Bug。然后就被领导问话去了。然后谈代码质量。
阳华：我们是先铺点，把产品功能点先上去，等市场验证后，再把原代码重做。
Waizau：其实不应该按照代码行数来确定一个类是不是什么的，一个一万行代码的类，你拆开十个类来写？除了一些可以重用的方法必须抽出之外，假如真遇到都不能重用的，还有必要拆开来写吗？
曹理鹏：关于烂代码的那些事（上）
关于烂代码的那些事（中）
窝窝：曾经接过一个架构很坑爹的项目，要迭代，只能心平气和的多打log跟踪熟悉。
Reic 胡：我遇到一个项目。用 MVP 模式开发，后来编程 VP 模式了，后来又编程 MVC 模式了，实在是......至于如何接手？我感觉只能是不断的 Debug ，打 Log ，看熟看懂。就好像看一个人一样，一天两天不熟悉，时间久了，感觉那个人的思维方式也慢慢掌握了。
然后，就是画uml图、思维导图还有流程图 ，我是实在看不懂的就删除吧！我感觉垃圾代码都没什么设计模式可言，画图就很清晰了。
管振伟：再垃圾的项目代码，也不能开始就推倒重来。重构需要对需求的充分理解，还要足够的测试用例保证。否则你可能要很久才能有一个用来发布的版本，还有一堆 Bug。而且一般项目交付都有时间的约束。然后充分理解需求，理解原始代码的意图很关键。有条件最好能多和原始作者沟通。
马方华：先改大头。否则代码越来越烂。一改就是大 Bug。而且不容易定位。
曹理鹏：如果为了项目的长远，或者我们要在里面呆久下去，光光改一些 Bug 或者需求并不够！
罗飞：大家讨论真热烈，我分享一下我的观点吧，拿到别人代码，所先要看懂别人的代码，自己要掌握一些分析代码的方法，不要排除看别人代码。这是我分析 PHP 程序的方法，相信移动端也能总结一些方法的。