程序员的点线面体

这里先抛一张示意图，点线面体是一种演进。在各阶段还有细分。

点：我们首先定义为解决具体问题，比如实现多文件的上传下载。一个复杂度一般的系统owner，我们都可以暂且纳入到点这个层面。但其实system就需要一些系统化思维。

从系统owner到二级域

如上图所示，System的  owner，从系统的角度是一个点。但从功能（Func）到System的角度可以是一个面的变化。有平台能力视角、稳定性视角、运维视角。

那么对于研发人员要迈出的一步就是，从完成功能A下载（点）逐步进阶到整体功能覆盖（线）、进而考虑多维视角：平台能力视角、稳定性视角、运维视角...

线：从但系统到产品线（二级域）可以理解为一种点到线的跃迁。之前考虑的是单个系统的职责、质量；现在要考虑一条产品线（N个系统）。

从二级域到一级域

从产品线（二级域）到一级域，可以理解为由线到面的跃迁。

在面的视野上，除了平台能力视角、稳定性视角、运维视角，可能又有了业务治理视角、业务运营视角等。

对于业务身份，你写的代码，是别人的噩梦吗？ 这篇文章曾提及，使用扩展点的方式。

扩展点的设计是这样的，所有的扩展点（ExtensionPoint）必须通过接口申明，扩展实现（Extension）是通过Annotation的方式标注的，Extension里面使用BizCode和TenantId两个属性用来标识身份。

业务身份对于业务层的跟踪和治理作用非常大，类似于技术侧traceId的可追溯性。

从面到体，就技术人员发展而言，我认为有2条途径，比如从一级域的问题终结者到全域架构，视野俯瞰是整个公司的技术架构；也可能是从架构师角色走向管理岗，比如CTO。

由线到面 vs 由面到体

解决的是由线到面的问题，还是由面到体的问题 我认为最大的分解点在于是

1：是否是解决的问题域有足够的扩展，比如从一级域到全域架构

2：是否重新定义问题域、技术输出模式、产品模式或者商业模式

（二者满足其一）

我们可以看一个例子，电商系统发展面临的问题。有系统问题、业务问题、技术支持问题。鉴于问题域是整个电商平台（够广）、问题维度涉及方方面面（有较强复杂度），是达到面这个层次的，但是还不能称之为"体" 这个层次，因为解决的问题域已知比较确定的问题域。

from 公开演讲资料《蘑菇街每秒订单数25倍提升历程》

对比，聚石塔这个case，就可以看到由面到体的变化。

从输出技术、到输出产品、到解决方案。解决是不同层次的问题。

from 公开演讲资料《聚石塔电商云容器服务应用和实践》

总结：点、线、面、体在任何专业领域都可以采用的4要素方法论。小到一位贴瓷砖的工人，大到数万人公司的参谋长。4要素方法论对于程序员知识体系，也有不同层的划分，就研发体系、运维体系也有各自的细分。本文所列的观点仅仅代表业务发展到一次规模公司的程序员的发展和自我完善途径。

声明：

2017年12月移动应用APP活跃度排行榜 参考：

http://www.askci.com/news/chanye/20180131/143916117331.shtml

内容启发：智能商业二十讲、产品思维30讲