曾经有一段「垃圾代码」放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此!当然,这些都是改编自周星星同学的经典台词,不过相信读者看完今天的讨论内容,应该也会有同感,接手垃圾代码实在是一件太痛苦、太折磨人的事情!
本期移动精英开发群讨论的话题就是「如何接手垃圾代码?」主持人是国内某跨境电商平台 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 胡:好的设计模式感觉对新人来说压力太大。
曹理鹏:每个人都说说遇到的问题吧,或者个人的经验!
李小三:代码尽量要统一。
午夜修铃:我遇到比较差的,或者是很别扭的(不一定是差,只是很别扭)
1、修改目录,修改成我认为看着舒服的,一般这一步过去,就大概知道有多少是重复的了。同时找东西会方便些;
2、修改类的初始化方法,初始化方法改成自己看着舒服的,或者是传参明确的。这样后面用的时候,我会比较顺手;
3、按照功能整理类中的方法。主要是优化逻辑,性能上不考虑;
4、调优性能;
5、开始去除抽取方法和类,有第一步和第三步,基本上这里去掉没用的类就已经比较方方便了。
基本都是遵循从大到小,从整体到局部的方式。
王岳明:我说的比较实际的啊,勿喷!垃圾代码肯定会有,特别对于大型项目,最重要的是稳定。接手垃圾代码当然比较恶心,但需要从时间成本和人力成本上去考虑,只有资源充足的情况下才去做重构优化,否则最好还是以平常心对待。有代码洁癖的同学,新增代码最好按代码规范来写,老代码能改则改,实在维护不下去了则必须重构。
Eric 胡:我的第一个观点就是,绝对不要出现硬编码,所有的配置也不放在代码里。前期要确定好框架,不要想着以后再重构。如果功能稳定,我会在他的设计思路上进行维护,新功能我会在自己的 library 里去实现。
Waizau:以前是,有时间的才会重构再继续开发,不然实在会一边写自己的代码一边骂的。
李小三:接手,先别动,慢慢修改,以完成任务为主。不是一朝一夕的事情
马方华:垃圾代码的框架一般很难改。一改就是两三个 Bug。然后就被领导问话去了。然后谈代码质量。
阳华:我们是先铺点,把产品功能点先上去,等市场验证后,再把原代码重做。
Waizau:其实不应该按照代码行数来确定一个类是不是什么的,一个一万行代码的类,你拆开十个类来写?除了一些可以重用的方法必须抽出之外,假如真遇到都不能重用的,还有必要拆开来写吗?
曹理鹏:关于烂代码的那些事(上)
窝窝:曾经接过一个架构很坑爹的项目,要迭代,只能心平气和的多打log跟踪熟悉。
Reic 胡:我遇到一个项目。用 MVP 模式开发,后来编程 VP 模式了,后来又编程 MVC 模式了,实在是……至于如何接手?我感觉只能是不断的 Debug ,打 Log ,看熟看懂。就好像看一个人一样,一天两天不熟悉,时间久了,感觉那个人的思维方式也慢慢掌握了。
然后,就是画uml图、思维导图还有流程图 ,我是实在看不懂的就删除吧!我感觉垃圾代码都没什么设计模式可言,画图就很清晰了。
管振伟:再垃圾的项目代码,也不能开始就推倒重来。重构需要对需求的充分理解,还要足够的测试用例保证。否则你可能要很久才能有一个用来发布的版本,还有一堆 Bug。而且一般项目交付都有时间的约束。然后充分理解需求,理解原始代码的意图很关键。有条件最好能多和原始作者沟通。
马方华:先改大头。否则代码越来越烂。一改就是大 Bug。而且不容易定位。
曹理鹏:如果为了项目的长远,或者我们要在里面呆久下去,光光改一些 Bug 或者需求并不够!
罗飞:大家讨论真热烈,我分享一下我的观点吧,拿到别人代码,所先要看懂别人的代码,自己要掌握一些分析代码的方法,不要排除看别人代码。这是我分析 PHP 程序的方法,相信移动端也能总结一些方法的。
本文系国内 ITOM 行业领军企业OneAPM 工程师整理。我们致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务,通过一个探针就能够完成日志分析、安全防护、APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多技术文章,请访问 OneAPM 官方技术博客
本文转自 OneAPM 官方博客