DàYé首席路 | 架构界之六识(终篇)

佛性导读

费劲巴拉地讲完六识中的四识：眼识、耳识、鼻识和舌识，还差一个身识，就可以触发转识成智，达到第六识“意识”。吾以众生相讲这么抽象的道理，已然有点不堪重负。贻笑了大方倒不是很在意，讲错了道理或者道理没讲透被歪曲了，就真的罪过了。

终篇收尾，继续流觞论道。

身 识

身受触。

触觉相较于听觉和视觉，似乎很容易被轻视。实际上有研究表明触觉可以让人对事物更加的有确定性。比如热水和冰棍看着都冒着气儿，不摸一下是不可能知道冷热的，所谓的眼见未必真。不过触觉同样存在欺骗性，比如手机上的虚拟按键配合按下动画和声音，会让你感觉你真的按下了按键，实际上你按的是整块手机屏幕玻璃。

蒙台梭利是意大利的著名幼儿教育家，她思想中的感官教育占据重要地位，而其中最为重要的就是触觉的训练，因为触觉可以锻炼一个人的敏锐力和分辨力。架构师不是换个牛掰的青轴机械键盘，手指敲的咔咔响就是在修炼触觉了，从身识角度来讲，架构师应该感受更多，分别是从外到内的触觉刺激、从内到外的有效触达。

1. 触觉刺激

架构师的必备技能之一就是能敏锐的捕捉到各种外部刺激，即便很微弱的。区别于前几识的感官刺激，下面要说的几种基本都是抽象触感。

· (交付中)交付效率的触感

与交付效率相关的因素有很多，比如研发效能、迭代速率还有交付质量等等。单说研发效能，现在已经有各种课程、布道甚至有实力的公司都早已设立研发效能部门，就是用来解决“效率”问题，而“效率”的本质用大白话说就是“别瞎忙”或者“忙的快而有价值”。但这事跟架构师有啥关系呢？随便掰扯一下就一堆关系。过度设计会导致瞎忙，设计不周会导致重写或重构，线上资源功能缺失会导致无法投产，需求评审不力会导致交付偏差，代码评审不力会导致生产BUG或未来隐患...上面所有这些都需要再次耗费你的更多精力，效率能高就见鬼了。

可移步之前一篇关于效率的文章

· (交付时)临门一脚的触感

上场踢球不管你多喜欢盘带过人、意识多好、体能多充沛、速度多快，球没射到门里去，都是白搭。这不得不让我想到了西班牙国家队90分钟的传球倒脚，但就是不射门！（对不起，我们的国足也是不射门，那是起脚机会都没）临门一脚有多重要相信大家都清楚，可以试着自问一下自己在临门一脚上做的如何？

做不好临门一脚，一般有这么几个特征。第一个典型是虎头蛇尾，软件交付虎头蛇尾的案例太多了。UAT验收成功，上线后生产验证发现漏了一个脚本/应用，造成生产事故不得不回滚; 架构设计经过了多轮次多专家的严格评审，2个迭代后已然面目全非; 团队内部研发出一款很不错的效能工具，且已经在小范围内试用，但是大范围推行受阻后就慢慢沉寂于无形，不会包装不会推广...有时候真气急我会败坏道还不如一开始就没做那么好，本来100分的工作因为虎头蛇尾功亏一篑直接扣80分。 

第二个典型是错误的理解了门的定义。普通程序员认为只要写好代码，通过测试，就是Nice Shot了。而真正好的程序员应该考虑更多，你的代码易读么，别人读你代码会骂出声来么？你的系统部署后怎样算成功发布了？你的系统投产后怎样才算稳定运行了？所以真正的“射门”到底指哪个环节呢？老板让你画个架构图，你就真的交了个架构图，也没问清楚这个图给谁看的，对懂行和不懂行的画法完全不一样。敏捷里的DoD其实就是让人明确“门”的定义，也就是完成的定义，不然真有人错把点球点当球门了。

第三个典型是贻误战机式的射门。这个看微信的产生过程就很明了，当初三个团队都在做微信，谁快谁赢。不管过程如何艰辛，相信输的那方也是努力拼过的，但只从结果看就是贻误战机而输掉了。架构师的贻误战机通常表现在对事物的预判能力不足上，或者过于保守或者过于激进，前者可能会犹豫不决迟迟不敢做出决策，后者可能会把团队精力浪费在低优先级的事情上。

· (交付后)线上产品的触感

对交付投产的态度是用来衡量优秀架构师的重要指标。在项目早期的架构设计阶段是否就考虑到了投产后的流量、排障、监控、安全、运营等一系列事情，并将其体现在设计中？从投产后不断波动起伏的线上表现中，如何甄别出新问题找到改进点？如何挖掘高质量的数据(剔除爬虫、DDoS...)为决策提供支撑？如何快速的定位到问题所在(包括给客服提供的最新的管理系统和知识库)？等等。

当一个架构师如同章鱼，将自己的触手伸到了整个产品生命周期的方方面面，才有可能真的设计出一个健壮的产品，否则不是纸上谈兵(过于理想化而脱离实际)就是焦头烂额(无法把脉产品而给不出真正的解决方案)。结构化数据、日志、埋点、CPU、内存、网络IO、磁盘IO等等都是章鱼式架构师所要触及的“钩子”，不用解释大家也知道这些“钩子”的用处了。

2. 有效触达

这个“触”我们要说一下触达这件事，也就是信息的传递。总的来说不管是技术架构还是业务架构，架构师都代表这个专业领域的最高战力，但不要期望单兵作战的架构师能有什么大的作为（一些神人除外），换句话说架构师必然要与团队协作，方能将设计方案精细打磨并实际落地。所以，就算你架构师一人的战力再高，若信息无法有效触达给队友，战力被归零都有可能。

<逃学威龙> 星爷的自嗨型手语，把队友都指挥跑了

· 如何与技术沟通

你不会天真到真的以为技术人之间的交流是没有障碍的把？恰恰相反，如同“文人相轻”，技术人在自己的技术领域当然也不会认输。这造成的现象是，架构师说完自己的方案，开发人员要不不好意思说自己不懂，要不不好意思说架构师不懂。不管哪种情况，架构师都应该以一种开放平和的方式与团队坐下来聊。既不能盛气凌人、以技压人导致团队不敢表达不同意见，更不能举棋不定、不敢决断引发团队对权威的质疑。

架构师与技术人良好沟通的前提是以技服人。架构师的设计或思想经得起基本的推敲是服人的第一步；欢迎不同意见的表达，但以合作的姿态来接受或者拒绝这个不同意见，是服人的第二步；最终的设计中埋入一些技术人喜闻乐见的亮点，即便是小彩蛋也好，可以是设计模式，可以是新奇算法，技术人最喜欢的就是此类技术“挖宝”了，这最后一步的闪光点才真正体现架构师的实力。

以技服人只是前提和手段，而我们的目标是有效触达。曲高和寡对于架构师来说可不是一件好事，因为这可能意味着你的思想过于抽象或者跳脱，导致团队一时无法吸收。不管是架构设计还是排障定位，架构师的表述都应该是明确的、具体的，不能含糊其辞、顾左右而言他。当一个架构师把高并发高可用高内聚等等这些大旗扯出来的时候，往往是露怯的时候，对于技术沟通无益。

· 如何与业务沟通

二进制的世界当然不同于碳基生命的世界。当技术与业务碰撞之时，鸡同鸭讲算小儿科，交付一个四不像产品才是最可怕的。

都说程序员智商高情商低，可有人说需求方们情商高智商低么？看问题不能只站一面，其实要解决它必须解决双方的“共同语言”问题。是程序员避免使用技术语言，转换为人类语言更简单一些呢？还是让需求方用技术语言来的更简单？当然是前者，所以程序员不得不背负上“不会说人话”的这口锅如此多年。程序员过于理性和工程化的思维，再加上多年系统训练的固化，很多自然界里很正常的实体和关系，进入系统化过程在程序员的脑袋里就变成了另一种样子(典型例子就是关系型数据库与自然实体之间的不一致不和谐，专业术语叫阻抗失谐 Impedance mismatch)。

举个我常说的例子吧，APP里“我的消息”一般避不开多种类型的消息，如活动通知(全体)、交易通知(个体)、聊天记录(实时)等，当需求方让你把所有消息都整合到一起分页展示的时候，从数据中台的角度考虑，这个可能不是什么事；但从微服务架构的角度，这些分别来自不同的微服务系统，底层数据通常也是割裂的，你第一反应应该会严词拒绝，那么你会如何说明这件事情？不出意外，不少程序员就会把我上面的话重复一遍，更加不出意外，需求方完全听不懂你的叨逼叨，这不就是个查询么?! 反正当我真的没办法跟这个需求方爸爸说清楚的时候，我就会说“你看淘宝/支付宝的消息就是多入口的，你知道为什么么？” 虽然有点扯大旗画虎皮的嫌疑，但是这个表述至少是正常人可以听懂的“人话”了吧？

· 如何与外界沟通

架构师需要持续的营养补足，闭门造车会加速知识的陈旧。优秀的架构师无一不是保持跟外界的联系，不管是从书籍中汲取知识，参加大会扩展眼界，阅读优秀的开源代码，还是疑难杂症的解决，知识总结(博客/公众号等), 争取大会主题演讲，成为开源社区committer，等等。与外界的这一来一往都会让你的知识体系在不断的更新迭代。可不能把这个“外界”简单定义为公司外，你自身之外都算外界。你看阿里合伙人的多隆，就基本没怎么见过他抛头露面，但江湖中就从来不缺他的传说，他能解决那么多棘手问题，一定是不断的在学习进步，他的口碑好，一定是在输出大量有益的知识帮助团队一起进步，这就是与外界的双向沟通。

也许你擅长学习不善于表达，没关系，用你的专业帮助团队解决问题就是输出。但不擅长学习就说不过去了，也就是获得持续输入是保持与外界良好沟通，让知识体系保鲜的必要条件。

意 识

意生念。

开篇我们就说这第六识不同于前五识，不能简单理解为物理脑的感受就是意识。转识成智，大约可以理解为把认识认知转成了智慧意念。它们有一些基本区别，简单说下我所参悟的佛法。

1. 佛法解读：第六识 vs 前五识

首先第六识与前五识一定是互相依存的关系，只有前五识没没有意识，就会视而不见、听而不闻、不嗅其香、食不知味、吹面不寒，而第六识又必须通过前五识来感知世界，否则产生的意识很可能是错乱的；其次第六识赋予前五识以“第六感”，你能看到时下正在发生的一切，但是审视过去和预见未来都需要第六识的意念加成。最近一季奇葩说里黄执中的一句听见“远方的哭声”，想必感动无数人，这当然不是耳朵真的听到而是思想赋予的"听见"；最后一点有些玄幻，第六识是超然世外的存在，不像前五识受生老病死等自然规律的掣肘，任你天马行空、肆意挥洒。

2. 架构师思维

笼统的说意识、意念还是过于抽象，我还是把它解读为思想或者思维吧。架构师思维到底应该怎么定义？我查了很多资料想了许久，也不敢下这个定义。Fine，我还是简单梳理下架构师思维的底座应该包含什么：

· 解决问题为导向的技术理性思维

工程师的核心能力就是解决问题。不管是设计方案、线上故障、客户服务还是其他，都应该以解决问题为导向。比如，即便客户提出了看似无理的要求，但是你要能挖掘出客户到底想要的是什么，无意义的互相拉锯扯皮浪费时间，还不如换个双方都接受的方式直接解决掉。

· 现实世界的业务产品感性思维 

架构师专注技术抗拒业务的痼疾由来已久，小鲜肉架构师们前赴后继的踩这个坑，老腊肉架构师们苦口婆心的奉劝后人不要踩这个坑。技术改变世界没毛病，技术驱动公司就有毛病。没有业务的技术就是无依的浮萍，别幻想了，好好琢磨下业务吧。

· 浪漫主义驱动的创新思维

不会天马行空的架构师是没有灵魂的人形脚手架，而创新就是架构师的灵魂，浪漫是创新有所获后的感悟。代码就像我们创造出的一个爱人，她越与众不同越纯粹完整，会越感觉到浪漫。反正我是这么觉着的...

其他的如商业、管理这些思维就不强压到架构师身上了，先把前面三个做好就很不错了。

浪漫HTML

3. 治学三境界

国学大师王国维提出的“治学三境界”做了个特别抽象的抽象，为世人所津津乐道，而解读也各有不同。

· 第一境界: 昨夜西风凋碧树。独上高楼，望尽天涯路

出自晏殊的《蝶恋花》。这说的是登高望远，明确目标和方向，了解事物的概貌。这也是我经常自我要求的，务必先看清楚想清楚再动手。

· 第二境界: 衣带渐宽终不悔，为伊消得人憔悴

出自柳永的《蝶恋花》(蝶恋花是一种词牌名，词牌是词的格式或者词的谱，词就是不同于律诗形式的长短句，所以不要感觉重名了，它也叫鹊踏枝、凤栖梧等。这是附赠知识点)。

原词是个情话表达为爱憔悴的艰辛和无悔，这里大师是想告诉我们任何大成就者都需要耐得住寂寞、坚定不移的追求自己的目标，即便很辛苦。

· 第三境界: 众里寻他千百度，蓦然回首，那人却在灯火阑珊处

出自辛弃疾的《青玉案》。这个最终境界就是历经第二境界的艰辛和磨练，最终豁然开朗，功成名就。

治学三境界，与君共勉。

总之

架构师的六识总算掰扯完了，不知道可有只言片语能打动到您。人的一生成长路如此漫长，又如此短暂，要学的东西太多，可怕的是，越学习越无知，幸福的是，越无知越求知，如此完美的"死"循环希望诸位都已投身其中，循环往复，早日觉悟“第六感”爆发小宇宙。

终篇附上全部六识的脑图，以飨各位关注的读者们。

往期推荐阅读