8000多行代码的组件如何开发和维护？较大的公司将有更多这样的项目，其中包含许多组件线和许多本机事件。技术栈刚刚从React0.14升级而来，UI组件库也大量使用了老旧的组件库。生意极其复杂，极其复杂！为什么会出现大量8K甚至1W行的代码？单页业务逻辑设计过于复杂，在不拆分的情况下实现业务逻辑时没有考虑组件拆分，或者组件拆分不够细化，组件不够纯粹。作为一个组件，最好是一个状态好的孩子。Parents（父组件）告诉它做什么，它就应该做什么（即具体的业务逻辑是在组件内部实现的，但是哪些业务逻辑应该由父组件来实现）。计算逻辑多，纯函数封装度太低。如果纯函数的封装度高，可以用FAAS甚至Serverless来解决这一点。如何维护和迭代由熟悉业务的人梳理核心业务的主线。毕竟8K行以上的代码不可能全部整理出来。但是主线还是要逐步的、不断的梳理和重构的。说起来好像是一句大话，其实就是越简单越好。如果你今年使用最新的技术，三年后它可能看起来像一个非常古老的技术。只有持续的、循序渐进的、局部到整体的重构，才能赶上时代潮流，才有好的开发体验。业务逻辑是密不可分的。像这次，我一共写了不到500行代码，导致了50多个BUG，而这个组件只增加了十行代码（只有一个功能）。跟对这个业务不熟悉有很大关系，所以一定要把整个核心业务主线文档梳理输出。严格遵循单向数据流，不要使用脏数据，这是底线。老组件8K多行，脏数据很多，例如：this.state.xxx='ooo'组件拆分，不超过500行。严格来说一个组件不能超过200行代码。我在公司做过webhook检测。只要超过200行，就会被企业微信和@对应的推码器通知。消除副作用，尽量封装无副作用的纯函数。业务不要放在前端处理。这也是为未来几年可能出现的FAAS和serverless做准备。我坚信祖传密码是稳定的。不要试图修改祖传代码。存在是合理的。如果写代码的人离开了，他一定不要碰他的代码。有些代码看着难读，不合理，但是肯定有他的实现逻辑。（除非你百分百确定，但谁能说绝对呢？网络上的大事故，尤其是涉及到金额的时候，一般开发者是无法抗拒的。）上期没写文章，主要是公司比较忙，学习计划还没完成又临近国庆。最近就不发了，下个月输出1-2篇。现在，我要去修车了。前天晚上刮了一辆奥迪A6，心好痛。
