新入职一家公司，项目是从外包公司接回来的，如大家常见，代码乱，问题多。
正向逻辑走不通，还有很多功能未完善，连玩具都算不上。而上线日期又近在眼前。
据在济南交接的同事分享，外包的iOS曾坦言：代码你们拿回去得慢慢优化。
这句话好有深意。
我还有一个小伙伴，现在代码到了我俩手上，除了尽快完成剩余的开发工作，工程里还藏着多到数不清的bug。
既然受任于公司初创之际，奉命于代码崩溃之间。
按照工作习惯，先画出一张思维导图。
就是这么简单，基本业务走通就可以。
然而时间有限，开发要继续，bug要改，框架得整理（不整理根本没法写）。
业务要跑通，Model层必须挨第一刀。
现在是用HandyJSON解析数据，网络请求是Alamofire+Moya。
有Moya规范，请求相对好些。唯独数据模型，就像是一群没人管的野孩子，没人认识，不知道他们干啥。
语文老师曾经说过，遇到事情我们要学会借古通今。
以铜为鉴,可以正衣冠;以古为鉴,可知兴替;以人为鉴,可明得失。
想了一下古人，还真有这样一个故事：
丁渭挖沟：
公元1015年，北宋京城汴京(今河南省开封市)皇宫失火，将皇宫烧成废墟.
宋真宗命丁渭主持修复皇宫的工程.
丁渭首先把皇宫前的大街开挖成一条大沟，取土烧砖、烧瓦;
再把京城附近的沛水引进大沟内，使运送建筑材料的船只直抵宫前;
竣工后又把废弃的砖瓦和废土填人沟内，然后修复原来的大街.
这一统筹施工安排，可谓“举一役而三得”
顺着故事结构，可以把它转换成以下JSON：
丁渭挖沟：{
起因：公元1015年，北宋京城汴京(今河南省开封市)皇宫失火，将皇宫烧成废墟
背景：宋真宗命丁渭主持修复皇宫的工程.
内容：{
准备：丁渭首先把皇宫前的大街开挖成一条大沟，取土烧砖、烧瓦
施工：再把京城附近的沛水引进大沟内，使运送建筑材料的船只直抵宫前
竣工：竣工后又把废弃的砖瓦和废土填人沟内，然后修复原来的大街
}
总结：这一统筹施工安排，可谓“举一役而三得”
}
目前我的项目也有相似之处，比如：事情很重要，时间很紧迫，只重构Model层。
吃了几包豆腐干、几块旺旺雪饼、两个小西瓜、三根辣条之后，灵感来了。
根据上方JSON，Model的重构工作提炼成了这样：
Model重构：{
起因：刚入职，代码乱，写不下去了
背景：项目要上线，老子想表现
内容：{
准备：做一套无缝过渡的替代方案，用命名空间划分职能，用别名兼容调用Model的代码
施工：把这些调皮的孩子们都抓到一块，起个好名字，搞清楚他们干啥
竣工：没人要的野孩子就地kill，多胞胎要kill到只剩一个
}
总结：事后还可以写一篇装逼文
}
重点就是“内容”里的三步。
之前乱七八糟的Model就不放图了，我也没截。
直接进入重构：
代码功能划分是根据不同业务来写的
然后用extension给这些功能模块填进Model
在外面调用这些Model时，顺着M一直用点语法补全写下去就OK了
为了更方便查看，可以给Model上方添加 /// 格式的注释。
替换的过程中，为了快速高效的完成整理，其他地方的代码一律不动。
最后一个小问题，类名换了，其他地方代码不动？
对滴！因为我用了typealias 给他们都单独创建了别名。
我的小伙伴也在开发，为了防止git提交冲突或者引起别的地方bug，非model的文件我先不动。
数据模型就是这样一个个整理的，将在后面工作中逐步把别名替换掉。
本篇END--
