技术增长的纵横术与攻守道

每天处理最多的还是业务需求，如何最大化的利用业务需求来磨砺技术是我研究的一个课题。这里记录下自己的一些思考。

寻求业务技术交叉点

业务需求需要通过技术来实现。只不过从0到1的过程已经解决过了，剩下的就是复制现有的模式。因此难以突破现有的技术瓶颈。不太容易出现质的突破与更新。但是用来“温故”是可以的。下面就拆解下，做业务项目可以温什么“故”。

架构类一般都有鲜明的技术栈。所以从横向上进行类别拆解，笔者从事的是大前端架构方向，涉及到 Hybrid，RN，YIS(新 Hybrid 架构), 小程序等框架。

--	Hybrid	RN	YIS	小程序

然后每个架构类型，针对采用的技术和解决的问题层次，可以进行纵深的分层。简单的按照从表面到内核驱动的顺序来：

这些是相同点，具备一定的通用性，在学习新的框架或者创作新的框架的时候，也可以从这个分层上考虑入手。每个分层下可以再细致的进行划分，然后可以做横向的对比。这个分层不一定准确，以不一定适应所有的情况，不过没有关系，在以后的慢慢完善就好了。

笔者也曾在产品一线开发，同样的套路，先对产品业务进行横向的划分：

--	产品1	产品2	产品3

然后对每个产品进行纵向的分层分析。这里按照软件生命周期的时间顺序进行分层分析。

其中领域概念和领域状态是对需求的理解和建模，了解整个业务的的核心业务模型，对这个业务模型的理解程度决定了和 QA，PM，Dev 等各个角色沟通的效率和深度。也可以按照纯技术层面的分拆：

也可以按照参阅角色分拆：

可以采用不同的分层方式进行分析，然后针对每个层进行更细致的横向比较，从而得到一些规律或者判断。

这就是在平常的业务开发中进行技术增长的方式，简称“纵横术”。通过纵向的分层，横向的比较，让不多的知识进行碰撞，联想，联系，从而得到更多的知识。

单个技术点的突破，一般需要借助于工程，工具才能形成强大的战斗力。占领的技术高低，要通过工程工具来守住，这就是“功守道”。换句话说就是，要产品化，甚至商品化。从而降低实施成本，降低使用复杂性，提升稳定性。