程序员：如何接手垃圾代码？

曾经有一段「垃圾代码」放在个人面前，我没有拒绝，等我真正开始接手的时候我才后悔莫及，程序员最痛苦的事莫过于此！固然，这些都是改编自周星星同窗的经典台词，不过相信读者看完今天的讨论内容，应该也会有同感，接手垃圾代码实在是一件太痛苦、太折磨人的事情！

本期移动精英开发群讨论的话题就是「如何接手垃圾代码？」主持人是国内某跨境电商平台 iOS 开发的负责人曹理鹏，文章系国内 ITOM 管理平台 OneAPM 整理：

曹理鹏：你们好，我叫曹理鹏，如今在一家跨境电商的公司作 iOS 开发，此前的确接手过「垃圾代码」，首先简单分享一下这个项目存在的问题（针对 iOS 开发）：

1.使用老式框架 ASI，而且没有作任何封装和抽取；
2.字典转模型都是硬编的；
3.类名多数以拼音的形式；
4.里面我再里面一共看到了5我的的身影（只有一个看起来牛逼的），因此就有五我的的思想和代码逻辑；
5.出现不少重复的小框架（好比下拉刷新，提示框等）；
6.几乎没有什么注释，有也是一些拼不一样的名字的解释；
7.最多代码是一个类里面有6000多行代码；
8.文件的逻辑结构与物理结构几乎不对应；
9.没有使用 Cocoa Pods，全部框架都是拖进去的。

最近的时间都是在「填坑」，填了一个又一个，致使本身都快没信心了，因此就有一个很强烈的想法，谈谈如何接手垃圾代码的问题......

李小三：大家见过 把 doc 文档放工程里的吗？大家见过一个 controller 里有1000行的 UI 吗？一个挺复杂的界面有不少视图。我接手的代码，一点注释都没有，本身连猜带蒙把注释加上了，简直......（后续吐槽省略）

马方华：这种状况我之前搞过，不影响功能的状况下，我会写个编译宏。正常的下跑老代码。另外的慢慢把新代码加进去。

沈钦伟：我是在保证项目能正常运行状况下，慢慢改里面的，等我新改的所有能用了，就把老功能迁移到个人新代码上。不过，有些东西，这个老项目 Bug 是越改越多，动的时候须要当心翼翼。

丽娟：我之前也接手过外包代码，我先把相关bug改好，再一点一点抽取代码，有次一个页面一样的接口分别写了四五遍。

蒋连成：个人作法是，首先不要过分优化，作到相关逻辑，把相关逻辑提取出来优化。暂时无关的逻辑先放着。从小到大一点点来，先把能够复用的 view 什么的，一点点提取出来封装。比较忌讳的是一上来就想着所有优化，过分优化每每会「吃力不讨好」。能用是最重要的，其次才是好用！

马方华：写代码的时候，我通常看下微信classdump后的头文件。看他们怎么写。类是怎么封装的。而后再本身写，本身写的可能不是特别好。

神州租车：重构仍是要理清楚业务比较好，要否则改了也是一堆 bug。再者，我以为一切仍是以本来业务为核心内容，再去对应代码比较好点吧。

曹理鹏：咱们通常都是一两天就会进行一个小的回忆，统计修改好的和近期要处理的问题。不过，每次改完以后有种刚刚看到太阳又要天黑的感受！

午夜修铃：重构，我理解是一个程序员的基因，是写在骨子里的。每一个项目所在的环境不同，因此代码的质量也不一样。通常的外包，对代码质量要求很低，注重的是时间。因此写的都比较差。这个是毋庸置疑的。不能用这个来评价一个程序的水平。再者，刚说的一个功能写了屡次，主要问题不在重构，而在沟通。

程序员是一群「偷懒」的人，累多了，才会去想办法偷懒，我们此次讨论，重点不是接手与否，而是你碰到了后，如何处理？

阮涛：先跟着断点走一遍，理解以前的逻辑才好动手改啊。

腾讯微信：遇到这种代码我通常是不会接手的，就算接手了也是新的功能用本身新的框架。

马方华：少写广播。感受这样改代码也方便好多。

沈钦伟：其实好多项目是功能优先，时间越短越好。决策层看的不是你代码写的多么漂亮，是功能有没有实现，尤为是外包项目！况且好多项目都是没到2.0就死了。

王云振：对于界面复杂的 Controller，是否是能够考虑把界面一块一块的封装成一个View。

曹理鹏：也就是 MVC 的思想去改！

蒋连成：通常状况下，是将每次功能相关的逻辑优化，该提出来的提出来，该复用的复用。一个模块一个模块来。不熟悉的逻辑，尽可能不要动，能够先改改结构。

好比将一些东西单独封装到 category 中，逻辑不动，只是位置移动。

午夜修铃：我理解差一点的代码，不仅是重构，就比如刚刚主持人说的，问题其实不少。要一条一条梳理。若是我遇到，第一步，多是先处理目录结构，把目录调整好。

Eric 胡：目前咱们公司用的是 MVP 模式。

曹理鹏：不知道是否有人，边改边抽到一个新的项目里面，当新的项目成型了就废弃老的，不知道这样算不算？

蒋连成：测试怎么办？测新项目仍是老项目？发版是发新的仍是老的？首先，时间会很长，你须要两头兼顾。

丽娟：最好仍是一份代码，两份代码太累了。

Eric 胡：好的设计模式感受对新人来讲压力太大。

曹理鹏：每一个人都说说遇到的问题吧，或者我的的经验！

李小三：代码尽可能要统一。

午夜修铃：我遇到比较差的，或者是很别扭的（不必定是差，只是很别扭）

一、修改目录，修改为我认为看着舒服的，通常这一步过去，就大概知道有多少是重复的了。同时找东西会方便些；
二、修改类的初始化方法，初始化方法改为本身看着舒服的，或者是传参明确的。这样后面用的时候，我会比较顺手；
三、按照功能整理类中的方法。主要是优化逻辑，性能上不考虑；
四、调优性能；
五、开始去除抽取方法和类，有第一步和第三步，基本上这里去掉没用的类就已经比较方方便了。

基本都是遵循从大到小，从总体到局部的方式。

王岳明：我说的比较实际的啊，勿喷！垃圾代码确定会有，特别对于大型项目，最重要的是稳定。接手垃圾代码固然比较恶心，但须要从时间成本和人力成本上去考虑，只有资源充足的状况下才去作重构优化，不然最好仍是以日常心对待。有代码洁癖的同窗，新增代码最好按代码规范来写，老代码能改则改，实在维护不下去了则必须重构。

Eric 胡：个人第一个观点就是，绝对不要出现硬编码，全部的配置也不放在代码里。前期要肯定好框架，不要想着之后再重构。若是功能稳定，我会在他的设计思路上进行维护，新功能我会在本身的 library 里去实现。

Waizau：之前是，有时间的才会重构再继续开发，否则实在会一边写本身的代码一边骂的。

李小三：接手，先别动，慢慢修改，以完成任务为主。不是一朝一夕的事情

马方华：垃圾代码的框架通常很难改。一改就是两三个 Bug。而后就被领导问话去了。而后谈代码质量。

阳华：咱们是先铺点，把产品功能点先上去，等市场验证后，再把原代码重作。

Waizau：其实不该该按照代码行数来肯定一个类是否是什么的，一个一万行代码的类，你拆开十个类来写？除了一些能够重用的方法必须抽出以外，假如真遇到都不能重用的，还有必要拆开来写吗？

曹理鹏：关于烂代码的那些事（上）

关于烂代码的那些事（中）

窝窝：曾经接过一个架构很坑爹的项目，要迭代，只能心平气和的多打log跟踪熟悉。

Reic 胡：我遇到一个项目。用 MVP 模式开发，后来编程 VP 模式了，后来又编程 MVC 模式了，实在是......至于如何接手？我感受只能是不断的 Debug ，打 Log ，看熟看懂。就好像看一我的同样，一天两天不熟悉，时间久了，感受那我的的思惟方式也慢慢掌握了。

而后，就是画uml图、思惟导图还有流程图 ，我是实在看不懂的就删除吧！我感受垃圾代码都没什么设计模式可言，画图就很清晰了。

管振伟：再垃圾的项目代码，也不能开始就推倒重来。重构须要对需求的充分理解，还要足够的测试用例保证。不然你可能要好久才能有一个用来发布的版本，还有一堆 Bug。并且通常项目交付都有时间的约束。而后充分理解需求，理解原始代码的意图很关键。有条件最好能多和原始做者沟通。

马方华：先改大头。不然代码愈来愈烂。一改就是大 Bug。并且不容易定位。

曹理鹏：若是为了项目的长远，或者咱们要在里面呆久下去，光光改一些 Bug 或者需求并不够！

罗飞：你们讨论真热烈，我分享一下个人观点吧，拿到别人代码，所先要看懂别人的代码，本身要掌握一些分析代码的方法，不要排除看别人代码。这是我分析 PHP 程序的方法，相信移动端也能总结一些方法的。

本文系国内 ITOM 行业领军企业OneAPM 工程师整理。咱们致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务，经过一个探针就可以完成日志分析、安全防御、APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多技术文章，请访问 OneAPM 官方技术博客

本文转自 OneAPM 官方博客