郭东白的架构课_03_02法则一为什么有些架构活动会没有正确的目标
你好，我是郭东白。
今天这节课我们就正式开始生存法则的学习。
你肯定看到过这样的观点，说架构设计就是一个迭代的过程。
我们要不断的发现，并且补偿现阶段软件设计的不完美。
然后通过各种手段打不定升级，因此架构设计永远是螺旋上升的，没有也不需要目标的指引。
也有人认为，定义目标并不是架构师的指责，毕竟目标是架构活动的一个输入，有需求，发起方设定不受架构师控制，所以架构师能做的就是想办法去满足这个目标。
然而，我要强调的是，每个架构活动启动之前，应该有，且仅有一个正确的目标。
这时架构设计的起点目标不正确。
你和你的团队再努力都没办法成功。
目标的重要性就在于它能够一直引导我们走在正确的方向上，并时帮助我们做取舍，在多个备选架构方案中做出最优的选择。
这正是我这节课要讲的架构师的第一条生存法则。
那就是所有的架构规划必须有且只有一个正确的目标，并且它还必须和公司的战略意图是互相匹配的这是你架构设计的起点，否则系统就会变得复杂和无序，缺少结构性。
你可能不太明白架构活动为啥会没有目标呢？那我们就先来讨论一下这个问题，其实啊现实中有很多架构活动都没有目标。
我先举个实际工作中的案例，我们公司现在主要使用卡夫卡做架构。
但是有位架构师认为，开源社区里正流行的posa的设计理念跟云圆型趋势非常契合，值得在全公司推广。
于是呢他进了多方调研，搭建了一条系统预言，并且针对一些小场景做了测试，测试，结果很让人满意。
他整理一套PPT来找我汇报他的PPT写的很好。
无论是poser的设计亮点，还是对我们公司的迁移场景思考的都很全面，我也从中收获不少。
但是我问他，你这么做的目标是什么？他显然没有料掉，我会问这么一个问题，所以沉默了一阵子才问技术先进性吗？事实上，在一个企业里，技术先进性很少，是一个架构活动的正确目标。
所以很多人做架构升计都只是为了做而做。
从我过去二十年的架构经验来看，有一半以上的架构活动在发起之前都没有明确的目标。
这种架构活动执行到了最后，多个协同模块之间必然是一个散乱的结构。
我在文章里放了一张图，展示了这种现象，听完音频你可以去查看一下。
总的来说，如果初期就有一个明确的目标，那么做到最后此模块和架期目标就会是大致对齐的。
同时也会最大化对目标的贡献，不过目标缺失是由多种原因造成的。
刚才我们讲的案例只是其中一个表现。
接下来我们讲讲目标具体缺失有哪些原因？下节课再来讲讲你作为一个架构师，具体该怎么应对。
关于目标缺失的根因，我们可以从技术和业务两个维度来寻找我先讲技术维度的那就是目标缺少全局视角。
由于技术原因导致的目标缺缺失，往往有个非常积极正面的出发点，那就是技术同学对于先进技术的强烈好奇心。
很多同学经常会在社区里讨论新技术、新趋势。
当好奇心转变成行动，也就意味着我们已经从一个深受技术理念影响的评价者转变成了追随者。
正是这种内在的驱动力，在推动着公司行业，甚至是整个技术的乃至整个社会的技术发展。
探索新技术是一种积极正面的力量。
我非常鼓励团队的同学这么去做不过。
就像我刚才提到的案例，从探索新技术变成漫无目的的架构，尝试中间缺失的就是全局思维。
也就是说，架构师没有从全局视角去思考架构活动的回报，以及他对企业整体复杂性的影响。
要知道，技术尝试跟业务产品尝试一样，每一次尝试都在耗费企业的机会成本。
如果一个正在处在创新期和成长期的企业，那么每次尝试还会耗费相关同学的心力。
心力是个非常有限且宝贵的资源，一旦尝试失败，耗尽心力的同学很有可能会选择离开，加剧整个企业心力的损失。
除此之外，每次尝试都会给原有系统注入新的复杂性，导致整个系统的复杂和无序，这就是商真的过程。
看到这里你可能要问我了，如果我兴起一个项目，是不是就可以引入新技术呢？一个公司当然要引入新技术，不过还是那句话，关键在于要有一个明确的目标，而不是以一种漫无目的浅尝折纸的态度去做技术尝试。
我曾经在一个不到七百人的研发团队里看到过，八个自动化BI报表工具五套UI组件十多套工作流引擎，这对日常运维软件升级、安全、合规和审计来说，简直就是灾难。
我相信这些技术设计的初心，从开发者的视角来看，或多或少都有一些技术先进性的理由。
同时我也可以断定引入这些技术的时候，很少有人思考过全局复杂性。
这就导致整个企业的软件从一个同构的系统迅速衰变成一个混乱无章的大杂烩。
这里需要注意一下，在这些让人吃惊的数字的背后，其实还有一个不太光彩的原因，比就是开发者的个人利益。
举个比较极端的例子，举个研发团队，曾经有个做大数据的负责人，匆匆忙忙引入了开源领域这个新框架，而且在会议上做了演讲。
但是演讲完没多久就提了抵御值，留了一个做了一半的烂尾项目。
也就是说，开发者的个人喜好、技术能力，甚至跟其他开发者的关系都会影响到他是不是会引入一个新系统技术层面之外。
还有另外一个原因就是信息沟通不畅。
比如说低层级的技术同学很少做跨团队跨部门的沟通，一些小范围的架构改造，也找不到一个官方版本可以借用。
而且从开头的时候，总觉得别人的设计太复杂，那就是过度修起。
所以自己去设计一个新写一个版本。
但是一旦业务逐渐增长，小工具变成了大工具，就变成了一个新的变种。
这里我给你分享一个案例。
当年在微软内部，有不少人骂微软的浏览器内核性能差，说是某某开业方案很好使，团队后来就请这些持反对声音的人一起去做一个内部项目，请他们在开源的基础上做起。
但是要求必须支持所有的测试场景，包括向后兼容的部分。
开始的时候开源版本性能是好，但是等杂七杂八的需求全部堆积上之后，性能反而变差了。
没过多久，项目就叫停了这个案例，告诉我们，一方面做业务和做产品的同学要有正确的取舍，不能见什么功能，就要什么功能。
另外一方面，我们做技术的同学也不能动不动就认为别人的东西过度设计了，认为我们的场景简单，就应该定制自己的技术。
要知道，往往你的场景简单，仅仅是因为你的业务还没做起来，等业务做大了以后，因会发现业务根本不是你想象的那么简单。
我见到过太多的所谓极简设计了。
事实证明，大多数的极简设计，要么找找夭折，要么越做越复杂，到头来还是得用专业版的设计替换。
总结来说啊，从技术维度思考，目标缺失的原因就在于缺少全局视角，主要有三方面的表现。
技术同学对于先进技术的强烈好奇心，开发者的个人利益以以及信息沟通不畅，比技术原因更常见的是业务原因，主要表现在目标太多目标不明确或者是目标摇摆不定。
比如业务leader有个非常有创意的方案，但是业务压力大，市场调研的准确度也很难判断。
所以很多时候需要AB测试来决定这个方案是不是要推广。
可以看到，业务同学连需求之间的一致性和相容性都没搞清楚，就把需求一个接一个的转给技术同学。
在这种大量AB测试的背景下，业务逻辑层层累积，系统变得越来越臃肿，老代码谁也不敢删。
还有一种情形在大公司里比较常见。
有的CEO喜欢高举高打上人之后，先大搞运动。
我曾经见过一个CEO,他在一个季度里同时启动了十个项目目标，五花八门，几乎把整个部门分成了十个子公司，让他们各自为战。
在这么大的交付压力下，团队根本来不及做，统一规划。
每个项目各自为战，整个季度几乎是全员九九七。
结果呢三个月以后，项目完工业务仍然是在原地踏步。
Ceo挑出个别数据上有亮点的项目，做了个表彰大会就万事大吉了。
运动虽然失败了，但漫无目的的随机大厦项目的办法却被完美的保留下来发扬光大，然后演变成董事长项目、集团项目、集团项目、必保项目等等。
这种混乱对技术架构的伤害很大，不过倒也不致命是有技术解的。
下节课我会专门来讲，只是这种行为对团队的技术文化的伤害非常大。
一般来说，那些追求极客精神和科学决策的同学，往往非常反感这种随机探索的管理方式，所以大多数会选择离开。
还有一种不太常见，但是极端致命的情形我们就得重视了。
那就是一个公司有两个明确的目标，这有点像华山派的剑宗和弃宗之争。
举个例子，在一个做电商的公司中，剑尊会认为业务要像自营一样，对整个供应链做强管控，这样有更好的用户体式也可以获得更多的市场份额。
而弃宗呢有两个道法自然，做业务就要走开放的平台模式，最大化平台的丰富度，由用户选择来淘汰。
落后的商家两派肯肯定是谁也不服谁。
如果是剑宗上位公司，就大兴剑宗玩法，一切设计都走供应链路线。
如果剑宗连续折戟，那么弃宗上位之前的设计都推倒重来，全走平台模式。
当然，任何时候剑宗里肯定有喜欢练剑法的，剑宗里也有用气自如的。
但公司内部不论是练气还是练剑，目标从来就不统一。
那么在商业竞争中，只能是比剑术剑，比气术气这种情形根本没有技术界。
一个公司在战略上不断摇摆，就证明这家公司没有战略意图。
我建议你另谋高就到这里，我们已经把目标缺失的两大根因介绍完了。
那么我们应该怎么应对呢？这正是我们下节课要讨论的内容。
好了，今天内容就是这些。
我来简单总结一下这节课我们讲了架构师的第一条生存法则，那就是每个架构规划启动之前都应该有，且仅有一个正确的目标。
而你作为一个架构师，必须要搞清楚架构设计的目标到底是什么。
只有找到了这个问题的答案，才能在多个方案中做正确的取舍。
不幸的是，我们多数的研发要求和架构规划在发起前都没有明确的目标。
最常见的就是竞争对手这么做了，我就照搬一下，做个AB试一试。
不论是业务产品还是技术尝试这么做，除了耗费大家的心力试，那会给原有系统注入新的复杂性，导致整个系统的无序。
因此，我们必须要做架构治理，剔除无序的元素，让系统重回到结构化的状态。
这也是我为什么一再强调架构规划必须始于唯一的一个正确的目标，并且这个目标还应该跟公司的战略意图相匹配。
最后是思考题环节，我在每节课的思考题环节都会留三道题，建议你任选其中的一道题作答。
目的呢不是要做的全，而是思考的要深，让你自己有所得。
第一道的题目是这样的，由于业务压力，我们经常会面临各种各样的重点项目。
那么你是怎么判断一个项目的重要性呢？你怎么决定自己的思考力分配呢？注意，我这里指的不是你被上级领导分配的重代码的时配。
而是你自己发自内心觉得某件事情很重要。
你主动花大量功夫去思考的过程。
也就是说你自主决策的个人注意力分配的算法是什么？接下来是第二题，你或者你周围的人有没有搭建过一个非常精巧的轮子，但是随着时间的推移，变成了诸多要被清理的破轮子呢？当时发明者有没有意识到这个轮子会增加系统的复杂性呢？为什么第三道题，在你参与过的架构活动中，最让你感到兴奋的一个目标是什么呢？为什么？欢迎你把你自己的思考分享在留言区，我有和你交流，我们下节课再见。