最近在某客上学习了一下郭东白老师的架构课,郭东白老师是原来阿里P10,是云计算和国际化电商平台领域的资深专家,他完整讲述了自身作为架构师该如何设计架构,以及对架构师的一些思考。整个囫囵吞枣般看完,好似虚竹一般,虽获得无崖子70年功力,但如何打出妙招,少侠我还多需努力。
一名软件架构师要为相对复杂的业务制定,并且引导实施一个结构化的软件方案。这个发现最终方案和推动实施的过程,就是架构活动。架构活动是作为架构师必须要认识清楚的,但同样也是很多架构师所忽略的。所有的架构规划必须有且只有一个正确的目标,而且它必须与公司的战略意图相匹配。这是架构设计的起点。
我们往往做架构设计时会偏离目标,主要可以归结为两大原因,一个是技术上的,我们常常因为开发者的个人利益(技术能力,与其他开发者的关系,个人喜好),或对先进技术的强烈好奇,无脑引进最新的但还未成熟的技术框架(后面找工作可以吹吹,手动狗头),或者跨部门信息沟通不畅,过度设计了很多不需要的逻辑;二是业务上的,也是我们常常感到无能为力,比如公司领导换了一茬,极大概率会吧年初规划的OKR推倒重做,甚至上任的CEO也不清楚目标,大兴土木,随机探索,再或是市场方调研准确度低,我们架构需要设计两套业务靠大量的A/B测试来决定哪一套业务才是最符合目标的。
那么,架构师该如何规划一次架构活动呢?我们可以从以下几个方面入手。
理解当前团队的商业模式,或者具体为团队的OKR,以及团队和公司的OKR之间的关系。我们对这个O进行数学建模,最好用一个公式来表达出,哪些因素会促使达成这个O,每个因素的影响有多大,比如有的电商平台的主要收入来自于交易抽成,那么公式可以为:
【总收入=GMV*Commission】
针对于上述量化描述,下面设计出的方案也要遵守三个条件:
在架构设计过程中,架构师的技术选型,要看准技术趋势,选择已经有规模优势或者是即将有规模优势的技术,而不是选择接近衰老期的技术。
推倒老的技术,有时会遇到非常大的阻力,因为这是人性的弱点,大家畏惧变化,以最小化改变来维持自己的心理安全感,写了10多年的java现在让他搞安全用rust,他一定是畏惧的,其次,就是经验主义,以前觉得用中台架构做到了业务成功,这次依然认为可行。
那如何看准技术趋势呢,可以参考Gartner热度曲线:
一个技术的发展一般分为五个阶段:萌芽期,至捧期,低谷期,灵感期和产出期。而架构师需要做的就是一个老去的技术就让他老去,快死的架构就随他灭亡,快死的架构不值得投入人力和时间去维护,更不用说去翻修或者是复用了。
在AI相关的技术热度曲线中,可以看到目前生成式AI,达到了至捧期。
在这一步,我们需要从多个视角对重大风险做一个全面的挖掘。
第一个是项目交付的视角,现阶段我们认为目标已经是合理的了,所以就需要在时间和人力的限制条件下,看看执行过程中是否存在风险,在当前交付的时间约束之下,是否会出现研发动作和设计完全变形的情况;在当前的时间要求和资源投入,实施方案是否高于质量底线,多个参与项目团队能否有效协同,是否有足够的时间,让团队处理出现的问题(线上问题,一个bug解一天)。
第二个是商业价值的视角,是否存在大幅影响最终产出的商业价值的因素,比如互联网企业最容易发生的恶性竞争,本来一个好的商业模式,大量玩家入场后,可能最后会变得无处逃生。
第三个是人性视角,是否某一个团队做的过于边角料或者做的东西不利于他们的考核,所以正如上一节所讨论,架构方案是否符合研发人员的人性。
第四个是其他风险,比如说监控风险,法律风险和安全隐私风险,你用的开源框架是否有一些重大的bug,或者用了一些盗版软件等。
那么如何在最短的时间发现最大的风险呢?
一方面要靠自己的判断,一方面要锁定公司内的领域专家,把项目背景和情况描述出来,然后认真听取他的意见反馈,然后与风险决策建议者一起碰撞,试图发现更大的跨域风险,每人每次大概1小时的样子,一般来说,覆盖一个大项目的所有视角,也就是十几个人。
针对风险的具体场景不同,需要对备选方案进行组合,最后给出预案被迫实施后的估计值:
在最后的决策环境,我们要站在对全局有利的视角,而不是从赞助者或执行者的视角,要敢于冒险,但也要保持理智。
假定我们已经树立了一组必保需求,然后从这组需求中推导了一组任务,并且我们以最大化某个项目目标的方式,将这组任务分配到了执行团队中。接下来就是规划确认环节,共八个部分:
我们先回顾一下代表架构师成长的五种角色:程序员、兼职架构师、跨域架构师、总架构师和 CTO。我们先看一下下面这张图,通过这个总结思考,我们能看到架构师这个职业背后更深刻的内涵。
如上图所示,这五个角色分别代表了架构师成长的五个阶段。在不同的阶段,架构师关注的是软件架构的不同侧面:
那么我们思考一下,想培养出这五个维度的能力,需要具备什么必要条件呢?
每个人的思维方式都不一样,有的人喜欢在别人逻辑推导的基础上发现漏洞,并试图修复优化;有的人喜欢对问题进行层层分解,自己独立得出结论;也有的人喜欢从其他学科中寻找类似的问题,从而发现新的解决问题的思路;还有的人喜欢在跟别人的深度讨论和辩论中逼近真理。通常来说,不同的思维方式会带来不同的推导路径,从而得出不同的结论。
然鹅,在现实生活中,你会发现,越是那些有挑战的问题,参与讨论的各方越是缺乏对问题的统一定义,因此很多时候我们花了很大力气,之后才发现大家讨论的都不是同一个问题,目标也完全不同。不信的话,下次在大家争论得不可开交的时候,你可以试着打断一下,然后让每个人把正在讨论的问题分别写在纸上,看看大家对问题定义的描述是否完全一致。反正我没遇到过一致的情形。
因此,越是有挑战的问题,越难找到统一的度量结论的标准。事实上,如果一旦思考清楚我们在一个问题上的目标,并量化出这个目标的指标,解决方案往往也就开始浮现了。它不再是一个未解的难题。
架构师该如何通过独立思考来最大化自己的增值呢?
谨以此文,多多勤勉,多多温习。
郭东白老师的架构课
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。