我是如何开发维护8千多行代码组件的

我是如何开发维护8千多行代码组件的

背景

• 我在明源云，咱们是国内最大的地产Saas平台
• 任何系统都会有遗留项目，越大的公司就会有越多这样的项目
• 组件行数多，原生事件多，技术栈刚从React0.14版本升上来,UI组件库也是大量使用了老旧的组件库
• 业务极度复杂，极度复杂！

为何会大量出现8K多行甚至1W行的代码

• 单个页面的业务逻辑设计太过复杂，没有拆分
• 实现业务逻辑时候没有考虑组件拆分,或者组件拆分不够细致
• 组件不够纯粹,做为一个组件，最好的状态就是一个小孩子，父母(父组件)告诉它怎么作，它就应该怎么作(即具体业务逻辑由组件内部实现,可是实现哪一种业务逻辑应该让父组件控制)
• 存在大量计算逻辑并且纯函数封装度过低,若是纯函数封装度高，能够用FAAS甚至Serverless来解决这个点

如何维护迭代

• 熟悉业务的人梳理核心业务主线，毕竟８Ｋ多行的代码，不可能所有梳理清楚了。可是主线要梳理清楚
• 逐渐重构,不断重构。听起来一句大话，其实大道至简，你今年用最新的技术，三年后可能看起来就是一个很老旧的技术。只有不断、逐渐、从局部到总体的重构才能遇上时代的潮流,拥有不错的开发体验
• 业务逻辑千丝万缕,像我此次一共写了500行代码不到,引出了50多个BUG，而这个组件内部只是加了十行代码（仅仅一个函数）. 跟这块业务不熟悉也颇有大关系,必定要梳理输出整个核心业务主线文档。
• 严格遵循单向数据流,不使用脏数据,这是底线。老组件8K多行大量的脏数据,例如:

this.state.xxx = 'ooo'

• 组件拆分，不能超过500行。严格来讲，一个组件不能超过200行代码，我在公司是作了webhook检测的，只要超出就会企业微信全体通知而且@对应的代码推送人.
• 剔除反作用,尽可能封装无反作用的纯函数,原本业务不该该放在前端处理，这也是为了将来几年可能FAAS和Serverless化作准备
• 坚信祖传的代码是稳定的,不要试图去修改祖传的代码,存在即合理，若是写代码的人已经离职，必定不要触碰他的代码.有的代码写出来看起来很难阅读,很不合理,可是确定有他的实现逻辑。（除非你有百分百的把握，可是谁又能说绝对呢？一次大的线上事故，特别涉及到金额的时候，不是一个普通开发能抗住的）

最后

• 这段时间没写文章，主要是公司比较忙，还有学习计划还没有完成
• 临近国庆，最近就不发文了，下个月会输出1-2篇
• 如今，我要去修车了，前天晚上刮到一辆奥迪A6，心痛中。