嗯，这可能是一个惊悚的标题
毕竟在接触到新公司项目之前，也想不到会有人把MainActivity写到6000行，写代码的真的不是一位灵魂作家吗
截图为证，6000行不含糊
开始时对同事提出了相关疑问，反而被教导，当前项目已经基本稳定，对于内部代码宁增勿减。
然而，一个基本稳定的项目，却小问题不断，修改默认的录像质量从1080到720，还需要去 ctrl + f 去查找修改代码内部七八处地方? (差评，都不能全局替换，当然能告诉我这个参数在哪个方法哪一行的同事我也是佩服的)
在我看来，对代码宁增勿减，说白了就是自己没有吃透看懂，或者是一时偷懒，图个方便，还有根本不愿意去解决修改代码后产生的后续问题。却不知道自己一时偷懒，会对后期维护造成多大的影响。正是这种宁增勿减的想法，才造成项目在不断推进的过程中愈发臃肿，还直接或间接的引发一系列程序bug而无从下手。
从问题代码总结问题
1.粘贴代码
这是最常见也是最不能容忍的问题，简单封装一下，抽成方法，不仅使用起来更加方便，简化了代码，查看起来也会更加清晰，出现问题也能更好定位和解决，仅仅是举手之劳，何乐而不必为呢。
2.消息传递混乱
不知道为什么最开始写代码的同学为何如此钟爱Handler,虽然源码中也有使用Handler集中处理大量事件的情景。但是对于一个所有功能写在MainActivity中的程序，呵呵。另外一个比较坑的问题是，这个6000行的代码里，handler还是结合广播使用的，是的，你没猜错，一个activity发广播通知自己注册的接收器再发message通知自己的Handler再转发一条新消息通知handler在另外一个case中处理最后执行方法
恭喜你看完了,也许你有和我一样的心情，神经病啊。
还是想说能有接口回调处理的问题，就用接口回调，RX都这么火了，观察者模式的好处还不够明显吗。Handler虽然也很好用，但目的不也是为了流程更简单吗，越用越复杂的Handler还是尽量避免吧。
3.关键参数不抽取
这个不用多讲吧，已经是基本要求了。没谁愿意改个参数去翻无数个地方，和粘贴代码一样不能忍。
4.if else 死忠党
这可能不是什么大问题，但是无数个if else 的迷之缩进... 呵呵,我想报警。switch case 大法好，另外AS早就可以一键转换if else为switch case 了。
5.滥用标志位
有些时候确实需要多个标志位来对一个事件定性。但是拜托在定义标志位的时候取一个简单易懂的名字？清醒脱俗什么不需要啊，越简单越直白越好，并且定义标志位开始就应该考虑好标志位变动的相关情况，多个标志位也尽量按条件集中处理。要确任标志位在一个逻辑流程中的状态，而不是这里一下那里一下，重复设置标志位的同一状态，平白增加阅读难度。
6.不写注释
为什么不写注释？为什么不写注释？为什么不写注释？写注释多好的习惯啊，记录参数，标注方法，类首说明....明明这么多东西可写！！！
7.一个类搞定一切！！！！
最后还是来说一下这个最可怕的问题吧，6000行的MainActivity确实骇人听闻，不论是从MVC到MVP，DataBinding和MVVM，还有Dragger2，都在不断的为我们的程序解耦，将功能模块划分更清晰明确，让维护更简单轻松，学了这么多年设计模式编程思想，我相信这应该都是历史遗留问题了吧
另外，Handler持有Activity的弱引用写法，项目中同样也没有注意，也发现这个问题许多同学都不太了解，若是有读者也不清楚的，还是赶紧百度一下吧。其实不论AS还是Eclipse都会有明显的黄色警告提示会引发内存泄露，我也是从这里发现并尝试解决才一直记在心里。 在IDE中写代码，一定要尝试解决所有警告，绿色看的才会心情舒畅呀
那么，什么样的代码才是我们想要的呢？
没错，就是优雅易维护的代码。完美的总结。哈哈
准备将这次的重构计划完整的记录下来，先立个序，满满的吐槽，又一次提醒自己优雅的代码是如何重要。
后面会随着自己重构项目的进度继续发文。
网友评论
如果这份代码很新(最近一两年)，那就是安卓组负责人的锅，不管是基础框架还是代码 review 都没做好。
另外，开发都是跟着需求走的，如果项目已经稳定不再改动，人手还是应该分到新的需求上面。
重构没有想象中那么简单，建议划分好一些点，针对每个点写好单元测试，一个点一个点的重构，每个点重构之后确保跑通单元测试和整体测试再进行下一步，并且在版本控制中做打 tag 之类的操作。