在简单的业务需求中，可能我拿到的后端数据，就直接可以去渲染视图层，然后就完善功能。从开发的成本和复杂度上考量上，是不值得去做业务拆分。所以，在复杂的业务需求中以及兼顾拆分和维护中，这种业务方法论就可以大展手脚了

无论做业务需求还是做平台需求的同学，随着需求的不断迭代，通常都会出现逻辑复杂、状态混乱的现象，维护和新增功能的成本也变的十分巨大，苦不堪言。下图用需求、业务代码、测试代码做对比： 图中分了 3 个阶段

然后我们依据状态机的定义进行逐个分析。 状态机之所以这样命名，大略都可以理解为管理“状态”的机器。从工业生产可用性的角度来看，任何事物都是可以近似看做有限的状态的。 怎么理解呢？比如一杯水的温度可以算作它的状态，理论上温度的值是无限的，比如我可以说水的温度从 30° 升到了 3…

在这个月月初的时候，我开始重新维护这个在线代码编辑器，和之前的不同的是，这次我是直接切换了一个分支来直接写，目前已经基本完成了第一版，这次所采用的技术栈主要有以下这些： 前端框架：NextJs 语言：

在日常的开发过程中，我们都会有一些常用的代码片段，这些代码片段可以直接复制到各个项目中使用，非常方便。如果你有接手过别人的项目，就可以很明显感受到几个项目一般都会有一些相同的工具类方法，这些方法就是之

什么是组件组合？React 有哪些组合模式？什么时候是提取组件的好时机？如何正确组合它们？什么构成了一个好的组件？

深入探讨使用硬核设计模式，包括PV操作、信号量，资源池模式。拆解并优雅完成高频面试题《请求并发数控制》

从手势识别开始，到 canvaskit 实现地图引擎，再到 react/vue 组件封装，最后构建出可交互的地图应用。

需求背景 前几天，甲方提了个需求，想让下面的数据循环展示，准备放在他们集团首页给他们领导演示用。 我们领导很重视这个事儿，拍了拍我，语重心长的说，小伙子，好好做。 我啪的一下就兴奋了，老板居然如此器重