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 元现金返现，上不封顶，立即提现。