面向全栈的技术管理（多图）

3月25日周六，在中生代和飞马网的技术嘉年华上，斗胆披上吹牛的嫌疑，分享了面向全栈的技术管理，现赘述如下。

研发管理有着广义和狭义的定义，总的来说，研发管理就是在研发体系基础之上，借助信息平台进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等活动。 简单来讲，研发管理是面向结果，过程敏捷的一种实践。作为一名技术管理者，既需要培养团队的ABC，又需要管理你的老板，保持团队的新陈代谢，因为一切都是人的竞争。我曾在GitChat上做过一次分享，具体可以参考《老曹眼中的研发管理二三事》一文。

全栈，不是全能，和所选择的技术栈甚至业务栈相关。例如以LNMP（Linux ＋ Nignx ＋ MySQL＋ PHP），那么掌握了这四种技能，算不算一个全栈工程师呢？个人觉得可以的。全栈工程师就是技能涵盖了系统中所采用的技术栈。但是随着技术栈的变化，例如引入了缓存Memcache乃至其他分布式缓存，那原来的全栈工程师还是全栈么？全栈是否要随之变化呢？这是一种动态性演进，从而衍生出了所谓全栈架构师的概念，具体的阐述参见《再谈<全栈架构师> 》一文。

面向全栈的技术管理试图从采用系统思维的方式来探讨研发管理尤其是技术管理的可行性和方法。从系统的角度看，包括时间，空间 和人三个维度。对于研发而言，人是核心竞争力，可以把技术栈划分为面向空间的技术和面向时间的技术，然而时空又是密不可分的。

这是个人设想的全栈技术栈，面向空间的技术就象庖丁解牛，是对问题本身的分解和实现；面向时间的技术，主要是效率，开发的效率，程序运行的效率等等。 关于技术栈中每项技能的解释可以参考《全栈的技术栈设想》一文。

面向全栈的技术管理主要是通过系统性的思维方式解决技术研发管理的问题。这是典型的九宫格矩阵，从时间和空间的维度提出了系统思考的维度。可以缩放系统的概念范围，例如到模块的层面，会发现很多有意思的结论。

全栈的动态根源主要有两方面的原因，商务驱动和技术驱动都会导致架构设计的优化。商业需求是个大话题，超出了很多技术人的领域，这里主要看研发中技术管理的全栈思维方式。用一句高大上的词，就是技术前瞻性。 如何考量技术的前瞻性，可以借鉴TRIZ的方法。

TRIZ 是工程领域的神人阿奇舒勒提出的，关于TRIZ的相关知识推荐创新算法一书。

TRIZ 中直接可以借鉴的就是技术系统的9个演进方向，可以指引我们对系统架构的演进思考。

技术的完备性是思考的第一因素，我们的系统是完备的么？如何定位我们系统架构的完备性？没有监控的系统是完备的么？Bob 大叔的Clean Architecture 给出一种完备系统的参考。

有始就有终，每个系统或者每种技术都有者自己的生存周期，或者自己成长的S曲线。技术选型的时候需要对所选技术所处的阶段予以考虑。

系统自身的动态性包括三个方面，第一就是移动性，从互联网到移动互联网，从web到手机APP， 不是一种偶然，而是技术系统发展的必然。柔和性说明系统的可塑性强，简单地说，可重用性是柔和性的一种具体体现。可控性可否映射到配置化或者参数化么？

系统的传递性强调了通信的重要性，上图给出了大神AliStair 的六边形架构，指出了对外接口的作用，被当作了微服务架构的理论基础。引申一下，为什么会有“Social for Anything” 呢？

子系统的不均衡正是差异性的具体表现，每个子系统都有着自己的进化曲线， 这是我们关注系统瓶颈的一种思路。

回顾上面的九宫格系统思维，最高层就是超系统。主机托管IDC资源逐渐演变为IAAS，负载均衡、集群服务等进化为PAAS， 应用软件进化为SAAS，后台的服务进化为BAAS，连数据报表类的服务都在往DAAS上演进，所谓的平台化或者构建生态系统都是在向超系统的演化。

九宫格系统的最底层是子系统，子系统在向微观场的方向演进，正像“社会化大分工不断细化”那样，职责的原子化，颗粒度的细化等。举个例子，使用高效资源中的SSD 硬盘， 鉴于SSD的高效，衍生了RocksDB等匹配的存储引擎。更普遍的是，就是现在如日中天的微服务。

协调性直接影响的是系统的效率。流程，工具，子系统，最重要的是人与系统直接的匹配，也是大家熟知的康威定律。

系统架构设计的时候，我们往往强调以终为始。所谓终，延展一下就是心目中的理想系统。系统的组成是复杂的，架构的约束存在着自身的矛盾，提高理想度中有用对无用的比值是提高核心约束的过程，将部分功能转移是一种借力打力。

如何匹配系统演进的方式呢，这可能是就是全栈小团队的用武之地。全栈团队也有着狭义广义的说法，但基本都是业务线分割，高度自治，覆盖技术栈支持DevOps的小团队，自身就是一个完备的系统。

全栈团队的管理包括《老曹眼中的敏捷开发》中的ABC，如何促进团队的动态流动，通过敏捷过程完成连续性交付，同时提高DevOps及工具支撑。

敏捷过程往往会带来一些副作用，例如技术债务。技术债至少可以分为6类，甚至可以更细。我们能算一算每项技术债的利息么？

马丁大叔的《重构》是一种经典，但代码层面的重构并不适合架构或者系统层面的重构，因为重构的前提条件在系统层面往往是不成立的。因此，refactor 会演变成refine。

全栈团队的分享是提高系统流动性的有效方法。可以有团队内部的周期性分享，专业的技术技能培训，内部社区的建立，投身外部社区等等，让团队做自己的主人。

以上，是分享的全部内容。研发管理或者技术管理的分享一般都会充满争议，管理本身就是面向结果的实践。因为时空的变化，人员的不同，很多的成功和最佳实践往往无法复制，我们企图探索一些可以实践的不变的东西，但只是，在路上。