最近跟一个朋友聊到关于App架构的问题, 其中就聊到一个App, 开发了很长时间, 一开始没有去想框架的事儿, 迭代过程中, 由于时间紧, 任务重, 人员更替等原因, 也没能保证代码质量, 很多设计原则被抛之脑后...规范性问题, 导致各个模块内的代码形式互相不一致, 风格迥异.
2, 可读性差
超长函数, 超大类
代码的格式不规范或不一致.
冗余代码, 无用代码, 重复代码....其实这是一个对症下药的问题, 针对为什么要重构提出的几个代码问题,
重构也可以分成以下几步:
1, 架构选择, 结构调整
根据App的业务场景(展示型, 交互型, 后台工具型…)选择合适的架构.
1 并不是说一定要选用一个架构...重写会产生各种意想不到的问题, 诸如设计过度, 对于当前代码把握不够(例如现在看起来很不友好的代码可能就是为了解决一个架构无法解决的问题等)....附—关于架构重构的规则
写完此文, 偶然机会在InfoQ上看到Uber的技术主管Raffi Krikorian在 O’Reilly Software Architecture conference上谈及的关于架构重构的