每天处理最多的还是业务需求，如何最大化的利用业务需求来磨砺技术是我研究的一个课题。这里记录下自己的一些思考。
寻求业务技术交叉点
业务需求需要通过技术来实现。只不过从0到1的过程已经解决过了，剩下的就是复制现有的模式。因此难以突破现有的技术瓶颈。不太容易出现质的突破与更新。但是用来“温故”是可以的。下面就拆解下，做业务项目可以温什么“故”。
架构类业务的拆解
架构类一般都有鲜明的技术栈。所以从横向上进行类别拆解，笔者从事的是大前端架构方向，涉及到 Hybrid，RN，YIS(新 Hybrid 架构), 小程序等框架。
| -- | Hybrid | RN | YIS | 小程序 |
|---|
然后每个架构类型，针对采用的技术和解决的问题层次，可以进行纵深的分层。简单的按照从表面到内核驱动的顺序来：
| -- | Hybrid | RN | YIS | 小程序 |
|---|---|---|---|---|
| 交互 | ||||
| 组件 | ||||
| 框架 | ||||
| SDK | ||||
| 调度 |
这些是相同点，具备一定的通用性，在学习新的框架或者创作新的框架的时候，也可以从这个分层上考虑入手。每个分层下可以再细致的进行划分，然后可以做横向的对比。这个分层不一定准确，以不一定适应所有的情况，不过没有关系，在以后的慢慢完善就好了。
产品类型业务的拆解
笔者也曾在产品一线开发，同样的套路，先对产品业务进行横向的划分：
| -- | 产品1 | 产品2 | 产品3 |
|---|
然后对每个产品进行纵向的分层分析。这里按照软件生命周期的时间顺序进行分层分析。
| -- | 产品1 | 产品2 | 产品3 |
|---|---|---|---|
| 领域概念 | |||
| 领域状态 | |||
| 交互流程 | |||
| 视图组件分拆 | |||
| 数据管理 | |||
| 数据评估 |
其中领域概念和领域状态是对需求的理解和建模，了解整个业务的的核心业务模型，对这个业务模型的理解程度决定了和 QA，PM，Dev 等各个角色沟通的效率和深度。也可以按照纯技术层面的分拆：
| -- | 产品1 | 产品2 | 产品3 |
|---|---|---|---|
| 交互规范 | |||
| 兼容适配 | |||
| 组件 | |||
| 路由 | |||
| 框架 | |||
| 状态管理 | |||
| 埋点监控 |
也可以按照参阅角色分拆：
| -- | 产品1 | 产品2 | 产品3 |
|---|---|---|---|
| 产品 | |||
| 后端 | |||
| 客户端 | |||
| QA | |||
| UI |
可以采用不同的分层方式进行分析，然后针对每个层进行更细致的横向比较，从而得到一些规律或者判断。
这就是在平常的业务开发中进行技术增长的方式，简称“纵横术”。通过纵向的分层，横向的比较，让不多的知识进行碰撞，联想，联系，从而得到更多的知识。
| -- | X | Y | Z |
|---|---|---|---|
| a | |||
| b | |||
| c |
打的下，守得住
单个技术点的突破，一般需要借助于工程，工具才能形成强大的战斗力。占领的技术高低，要通过工程工具来守住，这就是“功守道”。换句话说就是，要产品化，甚至商品化。从而降低实施成本，降低使用复杂性，提升稳定性。
