程序员的技术层级

什么是技术层级

其实就跟阿里腾讯的技术层次类似，是给软件开发人员能力评定设定的标准，也是程序员进阶的指引。大厂的评级基本上是按照你对外输出的能力来评判的，也就是你能胜任的项目的复杂度，完成的速度和质量。这是以产出为导向的，毕竟产出才相对容易量化，也比较公平。但是产出其实有一定的欺骗性，产出高的不一定技术实力就强，尤其是跟当前业务不直接挂钩的能力，容易让程序员忽略自身的能力短板，导致没有形成结构化的，立体的知识体系。在脱离团队和公司以后会感到迷茫。我就从一个整体的，宏观的角度剖析一下一个程序员应有的知识体系。各个层级是逐层推进的，一般来说下一层的基础打好，上一层的能力才强。

第0层，理论基础

包括计算机的组成原理，操作系统，进程线程，数据结构与算法。我想这些东西没有一个程序员不了解，毕竟面试最容易考的，尤其是大厂。这些东西的重要性不言而喻，日常工作中也会经常用到。但是别钻牛角尖，这些东西并不是懂得越多越深就越好。比如红黑树的旋转，编译原理，这些工程中用不到的东西学了是浪费时间。

第1层，技术实践

这一层的东西也是硬通货，不管是平时写代码还是面试都是必问的。
一是你擅长的编程语言的特性，说得学术一点是语法语义和运行时，语法是指表达方式，比如什么是表达式，什么是变量，什么是操作符，什么是函数，什么是类。语义主要是各种关键字，if，else，case等等。运行时就是该语言的常用库，比如时间操作，文件io，网络，多线程，runtime gc等等。另一种对编程语言的概括就是数据+算法.数据就代表该语言的类型系统，比如内置数据类型，自定义数据类型，函数(函数也是一种数据类型)，以及各种类型所支持的运算。算法就是指程序的流程控制语句，也就是if else return这些。这样也能完备的描述一个语言，但是没有突出该语言的标准库或者常用的第三方库的重要性。
二是常用的工具和中间件，比如mysql redis kafka，以及跟语言相关的框架，比如spring，mybatis等等。

可以看出第二层的知识其实是学不完的，不同的业务场景对应不同的技术栈。但是精通2-3门语言，常用的中间件以及框架还是很有必要的。最好是形成T字形的人才，即一专多会，有助于提高技术视野，避免出现拿着锤子看啥都像钉子的现象，争取在不同的场景下能选择最合适的技术栈。

第2层，软件设计以及系统架构

虽然Robert Martin在《架构整洁之道》里面说了，架构就是设计，这俩概念没啥区别，但是我看很多书籍博客一般都是区别使用了这俩词语的。一般来说，软件设计是指一个系统内的模块划分，而架构设计是指多个系统之间的划分，也就是在分布式服务的场景下把一个复杂的系统划分为多个服务(或者说子系统，毕竟微服务来了，子系统可以无线划分为更小的子系统，一个进程代表一个子系统的时代已经过去)。
对一个系统内部的模块划分，通常是按照package来组织的，每个package又包括一组互相关联的类。对于package和类的组织原则其实只有一个:高内聚低耦合。具体来说就是23种设计模式，以及这些设计模式背后的只到原则: solid法则和迪米特法则。
对于系统之间的划分，主要是按照业务模块来划分的，即每个子系统负责一个业务，比如订单子系统，账号子系统，物流子系统。。。这样划分的好处是便于理解，子系统之间的边界也非常明晰。通常有个误区是按照技术来划分子系统，比如搞出一个缓存子系统，存储子系统，这么做是不对的，因为不同业务的存储或者缓存共用会导致互相影响，比如一个系统突发流量打爆了存储和缓存，导致所有的系统都挂了。这样的系统是非常脆弱的。所以每个子系统都应该使用自己的存储和缓存。子系统之间只可以通过rpc交换数据。即便有时候必须提供一个共享服务提供给所有子系统，比如文件上传服务，也应该做好系统之间的隔离，每个系统都应该有自己的独立的配额，避免系统之间互相影响。另外，把复杂系统划分为子系统的原则也是高内聚低耦合。所以Robert Martin说得是有道理的。

第3层 业务以及技术领导力

这时候我们应该跳出技术本身的范畴，想想技术的本质是什么。技术的本质是产品的实现。所有的技术都是为产品服务的，技术的发展离不开对产品的思考，所以真正的技术专家应该对自己所负责实现的产品有深度的思考，深度挖掘产品的业务场景。根据业务的需求重新审视自己的技术实现，以确保自己设计的软件系统能支撑所有的业务场景，并且随着业务的演化而演化。同时积累了大量的实践经验，能够看出当前软件系统的不足，能够规划出软件系统优化的方向，引进甚至创造新的技术。大数据，人工智能这些技术都是在业务场景的驱动下才产生的。同时，要想技术构想得以完美的实现，必须确保项目的顺利推进，于是项目管理，团队管理，风险管理，沟通反馈，汇报总结 等等这些能力要求就出来了。总之一句话，支撑产品交付的一切能力。

总结

知识只有形成了结构才会具有最大的威力。如果没有对知识结构立体宏观的理解，就很难寻找到自己发展的方向，意识不到自身的短板。曾经有一段时间我非常轻蔑业务知识，沉迷于某个技术或者某个工具的学习，直到我问自己一个问题:我学的这些是为什么？对我的职业生涯的帮助在哪？我以后该怎么利用我当前学到的知识？直到我渐渐领悟了以上的几个层次我才明白，技术应该怎么学以及怎么用的问题。