镇楼，图片来自网络
之前写了一个6000行重构计划，链接在这里
一个6000行MainActivity项目的重构计划
嗯计划还在进行中，这两天工作之余建好了项目，也对重构的目标进行了一些梳理。
思考过程中又有些想法不吐不快，特意开篇话唠记录一下。
谈感想
这个重构计划的产生，非是工作要求，而是自己对当前项目的代码实在难以忍受（其实维护修改频率并不算高，只是心累的程度远远超出修改代码的难度），于是决定抽空来把项目进行重构，其实也相当于重写一遍。因此现在也是在空闲时间来做这个事情。记录过程是担心犯懒中途放弃，离职什么的不就是一身轻松了？估摸着这也是前几任同事的想法。
但不论后续是如何选择，当前也已经给自己定下了个小目标。好在项目其实说不上太复杂，6000行计划里似乎没太讲明白，其实就是一个行车记录仪的录像APP，主要功能是录像，拍照，然后兼顾一些设置，碰撞检测，紧急录像等等相关的功能（嗯，这些基本都写在一个Activity中）。在我的计划中也是准备在一两周之内搞定。后续在测试稳定了，再来和同事商量着替换一下现有项目代码。
其实在次之前自己也并没有重构完整项目的经验（毕竟应届狗），顶多是把自己写过的一些功能模块化。还是抱着重写一遍顺带提高自身的心态来做这件事情。
谈技术
也来谈谈对重构的一些理解，算是对的上技术文的标题。（作为一名Android狗，谈的也是基于当前App重构的一些看法，如有不对，也希望能指正补充）
为什么要重构
看过6000行计划里满满的吐槽，大概懂了一些，当当前项目的维护成本越来越高，甚至阻碍了正常的推进时，我觉得是有必要暂时缓一缓。进行一次正确的方向调整，是为了能够在以后走的更远。
但是重构不是说起来那么简单的一件事情，我自身感觉项目不算太复杂，给自己定的目标也是一至两周，还是空余时间，所以决定来做这件事，也是私下的。若是直接在公司说，我觉得项目这个样子不行，要重写，大概会被觉的项目基本稳定无需改动的同事直接抵制吧。
公司也有公司的考量，如何让自己的想法被支持也是一件很重要的事情（反正我就先单干着）。
重构需要准备些什么
我觉得最基本的两个问题是
- 对想要重构的项目是否有了充分的了解
- 重构之后的项目，你想要是怎么样的
对于我来说，对当前项目也已经维护过一段时间了，项目的代码，结构，功能和逻辑都相当清楚（鬼，6000行经常找不到代码），对于想要做的事情也比较明确（我就是想要以后能多偷一点懒）。
另外感觉重新写会比在别人的老代码上修改更加高效，同时可以借用功能实现和部分逻辑来加快开发，而不用担心会越改越乱。
重构可以做哪些事情
调整结构
字面意思直接理解就是重新构造。对App开发来说，简单就是调整项目结构。选择更高效更实用的模式和框架。
从整体层面来说来说，包括选择采用哪种模式来构造项目，选择MVC还是MVP，是否需要使用DataBinding，Dragger2，采用哪种框架进行网络请求，使用Logger替代系统log等等，不一而论。而对于代码细节处的调整，我把它归于下面优化代码的部分。
优化代码
细处可以从代码风格来讲，例如封装（也许是写的代码还不算太多，但是真心觉得抽象 封装是很实用很根本的技巧)。
假设有多个相似度较高的界面，是考虑封装一个BaseViewActivity，使多个页面具有相同的功能、ParentView或者其它，亦或者是选择保留一个统一功能的Activity，在其中用Fragment进行页面的局部更新和功能增强？
想要给页面添加一个侧滑退出的功能，可以首先写一个自带侧滑删除的基类（下次来分享之前写的这个基类），提供继承而直接实现功能，并且像侧滑退出这样较统一的页面效果，只需要简单提供一个功能的开关就够用了，都不需要提供差异化的参数设置接口。
例如这个6000行项目中，由于基于MTK平台，摄录操作使用的也是MTK提供的Sdk，经常在代码中频繁的获取相机Camera，相机管理类CameraManager，到了逻辑执行的地方又频繁的执行操作和设参相关的代码，然后标志位乱飞？为什么不能基于SDK再进行一次封装，写个单例，把相机相关功能集中管理呢。
对于需求，可行的方式总有很多，我认为程序员总是应该选择最省力最高效的方式去实现，学会偷懒，思考如何偷懒。而不是实现一个，然后复制粘贴，自以为节省时间的行为，其实是愚蠢。
好了，话唠到这里了。
6000行计划这两天整理一下，周末来发个前期工作的记录。
网友评论