PPT架构师与写代码这件事儿

长久以来，在软件⼯程师的群体中存在⼀个鄙视链：把不写代码的架构师称作“PPT 架构师”。想来这是由于在这个⾏业中，程序员的群体⼈数众多，且“受害”⾯积严重导致的。同时从这个现象⾥，我也发现⼤家对编程和架构的理解不同。虽然⼤家说的都是同⼀个名词，但是每个⼈的背景不同，所表达的含义也不同，因此造成了很多的误解。在《聊聊架构》中对程序和架构的关系已经探讨了⼀部分，本篇内容本来应该也是要写的，但是当时偷了懒，最近觉得还是写出来比较好。

在讨论这个问题之前，我们最好先探讨⼀下什么叫写代码，或者叫编程 (Programming)。⽽在探讨编程前，还需要先探讨什么叫程序 (Program)。因为编程就是编写程序的简称。

很多程序员会对这⼏个问题嗤之以⿐，编程谁不懂︖程序谁不懂︖学个计算机语⾔，⽤这个语⾔来写代码就叫编程嘛！但是问题往往就隐藏在简单的概念⾥⾯，⼈们总是有意无意的忽略重要的细节，⼤家也不要被简单所蒙骗，就去轻视这个概念。⼤部分⼈对⽇常天天接触的概念熟视无睹，不求甚解，⽽且说出来的时候都以为别⼈理解⾃⼰所表达的含义。可是事实并非如此，别⼈只会听懂他⾃⼰有同样理解的部分，⽽把不懂的部分⽤⾃⼰所理解的来代替，于是吵架就开始了。因此，我习惯于在讨论问题之前，把基础概念都梳理⼀遍，在这些概念定义的基础上再展开讨论，这样就能够避免出现模糊不清的争论点。往往基础概念清晰了之后，问题也⾃然就解开了。

什么叫做程序呢︖在本⽂的上下⽂中，程序是英⽂“Program”的翻译，“Program”英⽂也叫“Programme”，⽜津词典的解释是“A planned series of future events or performances”。程序在中⽂⾥的含义可以分作两个字来分别解释：“程”者，有“过程、步骤”的意思︔“序”者，有“次第”的意思。合起来就是⼀步⼀步按照步骤次第发⽣的意思。英⽂和中⽂的含义非常接近。为什么要按照步骤次第发⽣呢︖因为前⼀个步骤结果是下⼀个步骤的输入，必须等待前⼀步结束后，下⼀步才能够开始，这就是程序。当然，在软件⾏业通常都称之为串⾏执⾏。

程序是⼀个无主语的名词，凡是无主语的名词，都是容易造成误解的。那么要说程序，⾃然必须要先明确程序的主体，这样也就可以把程序边界确定下来。明确了程序的主体，⾃然就可以明确程序的⽬的，即在程序中所有的步骤完成后，可以达成程序所服务的主体的某个业务⽬标。比如⼈吃饭，通过⼿臂获取饭，送到嘴⾥咀嚼，吞咽，完成吃下⼀⼜饭，再比如从吃第⼀⼜饭到吃饱为⽌，这都是⼀个程序，必须每个步骤都要按顺序发⽣。这个程序执⾏完成后，就达成了解决吃饭的⼈的饥饿问题，这就是⼀个业务⽬标。

⽤⽣命周期来描述，程序也就是该主体某个业务的⽣命周期过程，程序的主体也就是该业务的主体。程序在执⾏时，如果执⾏该程序的主体必须、也只能是该程序的主体本身，那么这个程序就被称为该主体的核⼼⽣命周期。如果这个程序可以交给其他的主体执⾏，那么该程序则是该主体的非核⼼⽣命周期，可以分⼯给其他主体来执⾏。

为什么要分⼯给其他⼈来执⾏呢︖⼀⽅⾯，因为⼈在同时执⾏多个不同程序时，来回切换的成本太⾼-- 理解了这个，就能够理解 CPU 进程切换的代价了，CPU 在同时作多任务切换时的成本与这个⼀样。如果当过程序员也会有同样体会，写代码的过程中被其他事情打断后，再切回来写代码时，会发现前⾯所写的代码看不懂了，整个思路得重新思考、从头开始。另⼀⽅⾯，分离出来非核⼼⽣命周期，也有利于执⾏核⼼⽣命周期，这部分在《聊聊架构》探讨过，不再展开。

⼀旦程序交给某个主体来执⾏，那么这个程序相对于原主体就变成了⼀个命令 (Command)。很多⼈对命令这个概念也是似懂非懂，因为这也是⼀个没有主语的概念。其实命令就是⼀个主体指使某个主体完成某个程序的⼀个代号 (Code)，⽤来推动某个主体执⾏程序，并获得该程序的执⾏的结果。

命令的执⾏主体也是有差别的。每个主体对⾃身⾏为的推动，也是通过命令来实现的，比如命令⾃⼰的⼿抬起来，坐到椅⼦上等等，这是本地命令，执⾏的是⾃身的业务程序。当命令交给其他主体执⾏后，命令出现了⼀个新的名称，变成从命令执⾏者对外提供服务的角度，把每个命令的执⾏称为对外提供的服务 (Service)。

⼀个命令可以是⼜头的，可以是书⾯的，可以是⼀个眼神，可以是⼀个⼿势，等等等等，只要预先约定好，并且命令发起者和执⾏者双⽅能够理解即可。有了命令，就形成了沟通，就可以传递信息，就可以展开并实施分⼯。因此可以看到，程序由许多的命令组成，每个命令则有可能是⼀个⼦程序，可以分⼯给不同的主体来执⾏，也就形成了⼀个程序树。

当然也可以说，程序就是命令，命令也是程序。最终无法可分的命令，是原⼦级别的命令，这是最细粒度的⼯作。最细粒度的⼯作能否再切分，取决于当前社会的技术发展⽔平。在计算机⾏业，计算机软件的命令最细粒度，就是 CPU 的指令，⽽在 CPU 硬件中，⼀个指令的实现则需要通过给许多不同的电路元件发出命令，等等等等。

所以，什么叫做编程呢︖通过上⾯的讨论就可以看出来，把不同的命令组合起来，形成⼀个程序来完成业务的⽬标，这个⾏为就叫做编程。也就是说所有⼈都在编程，只不过⽤的是⼈类的语⾔⽽已，并不仅仅是软件程序员能够编程，每个⼈都在编程。

那么架构师和编程有什么关系呢︖主体推动⾃⼰的⾏为、也就是命令，执⾏起来是很容易的，仅仅受限于⾃身的条件。比如对于⼈来讲，四肢是否健全，韧带是否柔软等等。但是⼀旦要把命令交给其他的主体去执⾏，并仍然保持该程序的完整，这就需要架构的⽀持。所以架构师往往就根据这个主程序拥有者的权利和责任，对这个主程序进⾏分⼯，形成⼀个程序树，并分派⼦权利和⼦责任，这就形成了⼀个架构，这个过程就是架构设计，也就是架构师的编程。可以看到，这整个架构设计编程过程和软件没有任何的关系，架构设计编程所遵循的其实就是我们所处的这个世间的规则，同样，软件编程也要遵从这个世界的规则、也就是架构。

回过头来可以看到，既然命令可以⽤⼜头来表⽰，也可⽤书⾯的，也可以是眼神或⼿势等等，那么这些⽅式都可以⽤来编程。也就是说，只要是能够形成⼈类沟通的⽅式，都可以⽤来编程。在软件⾏业，我们把编程限于计算机语⾔，多多少少有点太窄了，因为脱离了这个世界的基础，编程就没有什么意义了。更何况计算机语⾔是模仿⼈类语⾔的，仅仅是⼈类语⾔的⼀个⼦集，⽽⼈类语⾔也仅仅是⼈类沟通⽅式的⼦集⽽已。

软件程序员编程和⼈类的编程区别，仅仅在于程序员要把⼈类的程序翻译给计算机来执⾏，程序员扮演的实际上是⼀个翻译的角⾊。那么这就要求程序员必须要同时懂得翻译的⽬标语⾔和源语⾔：程序员编程的⽬标语⾔是计算机语⾔，源语⾔是业务语⾔，那么就要求程序员必须同时理解业务语⾔和计算机的语⾔，也必须同时理解业务的运作机制以及计算机的运作机制。

从这个意义上说，PPT 架构师并非不编程、不写代码，只不过他编程所⽤的语⾔不是计算机语⾔罢了，他的代码是 PPT 或者架构图等，⽤的是⼈类语⾔以及业务语⾔，只是⽤PPT 来展⽰或运⾏⽽已。⼀个逻辑清晰、分⼯明确的架构师，假设他会写计算机代码的话，他所写的计算机代码、或者说他所翻译出来的软件代码，⼀定是结构清晰、职责明确的，同时他所说的⼈类语⾔和业务语⾔⼀定也是逻辑清晰的。

因此，PPT 架构师并不是什么可耻的事情，只要这个架构师能够理解好业务的主程序，作出正确的分拆并落地执⾏，这就是⼀个合格的架构师。但是这并不是说所有的 PPT 架构师都是合格的架构师，就如同程序员⼀样、并不是所有会写代码的程序员都是合格的程序员，不能够理解业务的主程序、不能够理解分⼯的架构师，甚至不能够落地执⾏架构设计⽅案的架构师，都不是合格的架构师。

为什么会产⽣这个争论呢︖背后的原因应该是因为架构师和程序员在合作的过程中，出现了⼤量的冲突，普遍形成了对⽴的局⾯。

这个对⽴的原因，⼀⽅⾯，从架构师的角度上说，基本上都是因为架构师不是领导者的角⾊，只能够提供建议，并无实施的权利，所以经常会非常弱势、缩⼿缩脚，也导致架构设计无法落地。可是舆论基本是⼀边倒的倾向，都觉得架构师是有问题，为什么没有听到架构师的观点呢︖想来是因为程序员群体的体量太⼤，⽽架构师的体量太⼩，因此架构师圈⼦的声⾳相对会⼩很多。

有⼈会挑战说，如果架构师是⼀个领导者的角⾊，不就又会出现“屁股决定脑袋”、并瞎指挥的情况吗︖在⽇常⽣活中，只有对结果不必负责任、并且有决定权利的领导者，才会出现这种情况。如果达到权责对等，那么这个领导者⼀定会深思他所作的决定，他不会去损害⾃⼰的利益，他做出的决定⼀定是对⾃⼰有利的。假设他给下属挖坑，那么最终影响的还是他⾃⼰的利益，他不会⼲这种事的。如果他不需要对坑负责，那么他就随便挖了。有些架构师没有责任感，也有⽅法逃避责任，并且只知道邀功的话，那么坑就多了。很多公司不信任架构师，其实就在于架构师的责权不清，无法追责，出了问题是其他⼈背锅。其实不仅仅是架构师，任何职位都是这样，责任权利不对等，就会出事。⼈员职责不清，软件系统⾃然也是职责不清，⼀塌糊涂。

也有⼈说，架构师是⼀个角⾊，不是⼀个职位。如果架构师不是⼀个职位，那么他就没有相应的权利，⾃然就无法落地他的架构。如果架构师不是⼀个职位，那么他不必承担整个系统的责任，可是他又有权利去做系统的架构改变的时候，那么可以想象，这个团队⼀定会遇到很多因此⽽导致的困难，因为架构师可以尽情的去尝试他⾃⼰的想法⽽不必担⼼负责任，因为最终系统的责任是由团队的领导者来承担的，⽽架构师的简历则可以写的很漂亮。当然也有⼀种情况，架构师同时具备影响⼒，有能⼒去影响架构，虽然他不必承担责任，但是这个架构师具备极强的责任感，那他也是可以把事情做好的，这类架构师应该是现在各家公司梦寐以求的⼈才吧。可是这类⼈太少了，吃的是草，挤出来的是奶，损害的是他⾃⼰的利益，也是无法长久的。因此，仅靠影响⼒，架构师很难玩转，即便有些⼈可以这么做，那么也⼀定是很累的，投入产出会相差很⼤。最省⼒的办法就是做到权责对等，这样才能够达到双赢。

另⼀⽅⾯，则要从程序员的特质来探讨，可能有⼏个⽅⾯的因素。

⼀⽅⾯，可能是因为⼤家经常拿建筑来类比，把程序员类比为泥瓦⼯，太伤感情了，其实这个类比不准确，程序员可以类比为⼀个翻译官。类比的错误，就会导致很多架构师轻视程序员的⼯作，从⽽拔⾼⾃⼰的⼯作。其实⼈们都有拔⾼⾃⼰的所崇尚的职业的倾向，⽽实际上⼤家只是分⼯不同⽽已。那么对于程序员⽽⾔，作为⼀个翻译官，如果不能够很好的⽤⼈类语⾔来编程，那么要做到⽤计算机语⾔能够很好的编程，这是很难的事情。我想，这应该是很多⼈都忽略的地⽅，这对程序员的素质是⼀个很⾼的要求，这个要求⼀点都不低。去看看翻译官的⼯作，必须要深入到被翻译的领域中去，并通晓两种不同的语⾔，要做好是非常困难的。

再⼀个，从程序员本身的利益来考虑，对语⾔掌握的精通，对技术的掌握的多少，这是当前⾏业对程序员⽔平的⼀个评价，体现在每个程序员的个⼈简历上。因为这个比较容易打动雇主，也容易得到验证。⼤家也会发现，这个和翻译官追求精通掌握的语⾔要多是⼀样的道理。⽽架构师的出现，会平衡业务和技术，以求最合适最稳妥的落地⽅案，因此往往不会冒险采⽤最新潮的技术，而这就挑战了程序员的个⼈技术积累，因为这样会让程序员很难⽤上他⾃⼰想学的最新技术。同时，程序员是⼀个⾼智商的群体，通常都⾃视甚⾼，来了⼀个对⾃⼰指⼿画脚的架构师，却甚至不会写代码、或所写的代码⾃⼰都看不上，难免会出现敌对的情绪。⽽通常这个架构师会更偏向于业务，和业务⾛的比较近，会让程序员觉得架构师靠忽悠领导混饭吃，⽽拿程序员做炮灰。所以程序员第⼀反应是，架构师代码都没我写的好，还来指挥我写代码，架构师所设计的⽅案，从技术角度来看，那就更看不上了。如此，不起冲突反⽽是很难的事情。

其实在架构师的圈⼦⾥，也同样会有操⼼架构无法落地，程序员不听指挥等等的问题。这也就是为什么我认为架构师必须要对架构落地全⾯负责，不能仅仅当军师，或者仅仅靠影响⼒，因为权利和责任不对等，是很难做好⼯作的。这也是为什么要探讨“架构师是做什么的”、“架构是什么”，这个不搞清，程序员和架构师就无法很好的进⾏合作。只有搞清楚了各⾃的职责，才能够互相协助、互相⽀持，达到共赢 ---- 业务飞速的成长。

还有⼀部分程序员会有疑惑：业务不就是做些 CRUD 嘛，没什么意思，我做的是技术框架，不需要和业务打交道。

只要是需要记忆⽤户状态的应⽤，都是需要 CRUD 的，这没有什么问题。可是把业务和 CRUD 等同，只能说是对业务理解的不够，并且其所写的代码，业务逻辑⼀定会分散到数据库和访问代码中，这个项⽬成长的过程中⼀定会遇到比较⼤的危机。这部分内容，《聊聊架构》中已经探讨过，也就不展开了。

如果做的是技术框架，就真的不需要和业务打交道吗︖比⽅说学习算法，如果不知道算法的业务场景，这个算法是学不好的。比如排序算法，无非就是把现实空间的问题，⽤数学代号表⽰出来，因此算法离不开分治 (Divide and Conquer)，所分出来最有效的就是⼀棵树，因为空间的切分，是不允许有重合的。也可以发现，这不但和算法的业务有关，和架构也有关系。当我们把算法中的非核⼼过程交给其他进程或 CPU 来执⾏，这就可以形成并⾏，⼤⼤缩减计算所需要的时间，这其实就是架构。

再比如设计⼀个⽹关，如果不理解⽹关所⾯对的业务，任何⼈无法凭空想象出来⼀个⽹关如何做。很多⼈投入精⼒学习 OSGi，可是在互联⽹为何不流⾏呢︖这是因为服务器是可以横向扩展的，做成不同的服务来发布，比单纯的⼀个 APP 中的模块化成本更低。反⽽在终端设备上，由于硬件无法扩张，应⽤又需要模块化的话，OSGi 就能派上⽤场了。这些都是业务。投入学习⼀个技术，必须要先理解这个技术的业务背景，这样才能够有的放⽮，也会少踩坑。

哪怕去学习操作系统，那么多的设备需要管理，要做好这⼀块，需要⾜够的设备管理业务知识储备，那么多的⽂件需要管理，需要⾜够的⽂件管理业务知识储备，等等等等。很多⼈学习计算机的专业知识，往往不得要领，原因即是在此，因为不懂得技术背后的业务。我经常开玩笑说，食堂⾥的清洁阿姨都比我们的很多程序员都更懂内存的垃圾回收策略。比如每个⼈吃完了，盘⼦是阿姨负责收的还是每个⼈⾃⾏把吃饭盘收⾛的︖这是两种不同的模式。那么为什么不是所有食堂都要求每个⼈⾃⾏带⾛垃圾呢︖这似乎是更⾼素质的⾏为啊，为何计算机不采⽤呢︖这个问题提出来就很好了，这是标准的业务问题。如果是阿姨负责收的话，这是我们通常的垃圾回收场景，阿姨是怎么做到以最⼩的代价，最快的收拾空余座位的盘⼦的呢︖如果多个阿姨⼀起来收，她们是怎么互相协调的呢︖⼀个位⼦的盘⼦还没有收，有⼈等在旁边要坐，怎么办呢︖要做 VM 的垃圾回收策略的开发，这⾥就是最好的业务学习场景。

在食堂⾥经常会有盘⼦架，⼀般都会最少放两个，⼀个装满后，食堂收拾的师傅就会拉⾛⼀个，并换上⼀个空的，同时也不耽误⼤家，⼤家可以继续把吃完的盘⼦放在另⼀个盘⼦架上，这就是典型的双缓冲策略。那么食堂的师傅当然也比很多程序员更懂得双缓冲，尽管他不懂如何软件编程，但是他可以指导程序员如何写双缓冲，因为他更懂双缓冲的业务、双缓冲可以让⽣产者和消费者互不影响。

看到这⾥，我们还可以说程序员不需要懂业务吗︖恰恰是越懂业务，代码写得越好，不管是在计算机领域，还是在业务领域，都是如此的，只不过⼤家把计算机领域的不认为是业务罢了，以为只是技术，其实也是业务。⼤家千万不要看不起业务，业务学好了，计算机技术才可以学好。

程序员往往认为设计技术框架的⼈才是架构师，或是很⽜的程序员，这也是程序员鄙视 PPT 架构师的原因之⼀。确实是有很多设计技术框架的⼈是架构师，因为他掌握了技术框架背后的业务，并进⾏合理的分拆，形成不同的分⼯，组织⼤家⼀起完成，这就是架构师所⼲的事情，并且他具有资源调动的权利，可以落地实施他的架构设计。但是不是所有设计框架的⼈都是架构师，很多⼈不过是把别⼈的设计拿过来改改，以适合⾃⼰的场景罢了，也不具备资源落地他⾃⼰的架构设计，这类的不属于架构师。

那么很⽜的程序员是不是架构师呢︖那就要看这个“⽜”怎么来定义了，不同的⼈眼中的“⽜”法不⼀样。有些⼈认为那些技术框架玩的很熟的⼈很⽜，这类就很难符合本⽂中的架构师定义了，⽽且技术更新换代太快，很快他们就会遇到瓶颈。有些⼈把团队中的救⽕队员称为架构师，认为他们很⽜，往往这类⼈是团队中最⾟苦的那个。⼀个团队⼀但开始依赖救⽕队员，那么这个团队的⽕会越冒越多，救⽕队员也会遇到瓶颈，他的知识也很难得到传递，变成恶性循环。之所以他会成为救⽕队员，⼀定是因为他无法在研发过程中落地实施他的想法，迫使他只能够在事后来解决，⾃然他也无法成为架构师。

既然架构师主要是⽤⼈类语⾔和业务语⾔来写代码，当然也有⼀部分架构师也具备写软件代码的能⼒，因为对于很多⼈来讲，多学⼀门语⾔并不是难事。反过来，软件程序员未来⼀定能够成为架构师吗︖这是软件⾏业的晋升路线图之⼀，许多软件程序员把⾃⼰的⽬标定位为成为架构师。从前⾯讨论的结果来看，这就好比问，翻译官可以成为架构师吗︖这完全是两种不同的⾏业，所解决的问题完全不同，不具备可比性。⽽程序员要成为架构师的话，那就相当于改⾏了，或者说转型。当然此处的架构师也并非⼤家平常所指的资深的代码⼈员，或者是软件开发团队中能⼒超强的救⽕队员。

程序员可以成为架构师，因为任何⼈都可以成为架构师。程序员也并不必⼀定要成为架构师，但是要成为⼀个好的程序员，最起码要能够成为⾃⼰所写程序的架构师。⽽要成为⾃⼰程序的架构师，就要理解⾃⼰程序中的访问代码和业务代码的切分，做好⾃⼰代码的分⼯。如果做到这⼀点，代码就不会差了。做好了对⾃⼰⼯作的分⼯，⾸先就成了⾃⼰⼯作的架构师。如果想要转型架构师，就再进⼀步去了解业务的架构。接触的业务多了，就可以慢慢成为某个业务的领导者，可以去负责这个业务的架构，包括这个业务的软件架构，融合业务及软件于⼀身，负责对业务或软件团队的分⼯，这就是⼀个合格的软件架构师，因为不能够落地的架构师，不是真正的架构师。当然⼈们经常会说，这是在往管理的⽅向发展，可是不具备调动资源能⼒，又怎么能做好架构师⼯作呢︖！

真正⽜的程序员，是以很少的代码达到⽬的的⼈，是每天可以⾼效完成代码，不会经常有线上问题的⼈，是每天能够按时上下班的⼈。他不⼀定要成为架构师，但是他⼀定是具备架构师思维的，他能够合理拆分他⾃⼰所写的代码。不要因为⼤家⾼看架构师，就看不起程序员，其实程序员本身就是⼀个了不起的职业。

极客时间《从 0 开始学架构》专栏，目前专栏已有 2.6W+ 技术人订阅。50 期课程中，资深技术专家李运华从架构基础、三大架构模式和实战的角度，分享他近 10 年从业经历积累的一整套架构设计方法论。目前已经全部更新完，你学习后能快速理解陌生的架构设计，对架构设计游刃有余，照着做你也能成为架构师。

现在订阅，还有以下福利：

福利一：订阅专栏，一次性获得专栏全集，附赠《架构师成长技能图谱》一份

福利二：老用户每邀请一位好友购买，可以获得 24 元现金返现，上不封顶，立即提现。