郭东白的架构课
郭东白
酷澎网络科技副总裁,前车好多集团 CTO,前阿里 P10
36979 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 67 讲
春节声明 (1讲)
模块二:创造价值 (21讲)
郭东白的架构课
15
15
1.0x
00:00/00:00
登录|注册

02|法则一:为什么有些架构活动会没有正确的目标?

公司内部目标不统一
CEO大搞运动导致团队压力
A/B测试导致系统臃肿
信息沟通不畅
开发者的个人利益
技术同学对先进技术的好奇心
3. 最让你感到兴奋的架构活动目标
2. 建造精巧轮子变成破轮子的原因
1. 判断项目重要性和决定思考力分配的算法
业务上:目标太多、不明确
技术上:缺少全局视角
目标的重要性:引导方向、做取舍、选择最优方案
案例分享:架构师缺乏明确目标
目标必须与公司战略意图相匹配
架构设计需要一个正确的目标来引导
架构设计是迭代的过程
思考题
目标缺失的根因
架构活动为什么需要目标
架构规划必须有正确的目标
架构师的生存法则

该思维导图由 AI 生成,仅供参考

你好,我是郭东白。今天这节课,我们就正式开始架构师生存法则的学习。
你肯定看到过这样的观点:架构设计就是一个迭代的过程,我们要不断发现并且补偿现阶段软件设计的不完美,然后通过各种手段打补丁升级。因此,架构设计永远都是螺旋上升的,没有也不需要目标的指引。
也有人认为定义目标并不是架构师的职责。毕竟目标是架构活动的一个输入,由需求发起方设定,不受架构师控制,所以架构师能做的就是想办法满足这个目标。
然而我要强调的是,在每个架构规划启动之前,应该有且仅有一个正确的目标,这是架构设计的起点。目标不正确,你和你的团队再努力都没办法成功。目标的重要性,就在于它能够一直引导我们走在正确的方向上,同时帮助我们做取舍,在多个备选架构方案中作出最优的选择。
这正是我要讲的架构师的第一条生存法则:所有的架构规划必须有且只有一个正确的目标,而且它必须与公司的战略意图相匹配,这是你架构设计的起点。否则,系统就会变得复杂和无序,缺少结构性。

架构活动为什么需要目标?

你可能不太相信为什么架构活动会没有一个正确的目标。这样的案例在现实中有很多,我来分享其中一个。
我们公司目前大多使用 Kafka 来做架构,但有一位架构师认为开源社区里正流行的 Pulsar 的设计理念与云原生趋势十分契合,值得在全公司推广。于是他经过多方调研,搭建了一套系统预研,并针对一些小场景做了测试。测试结果很让人满意,他便整理了一套 PPT 来找我做汇报。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

架构设计的重要性在于确立正确的目标,而缺乏正确目标的架构活动会导致系统复杂和无序。本文强调了架构师需要从全局视角思考架构活动的回报,以及它对企业整体复杂性的影响。文章指出了目标缺失的两大根因:技术上缺少全局视角和业务上缺乏正确的取舍。作者分享了多种业务原因导致目标缺失的情形,如目标过多、不明确或摇摆不定,以及CEO的随机大撒项目的管理方式。此外,文章还提到了技术同学对先进技术的好奇心、开发者的个人利益以及信息沟通不畅是导致目标缺失的主要原因。总的来说,本文深入浅出地阐述了架构设计中目标设置的重要性和影响因素,为读者提供了对架构设计的深刻理解。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《郭东白的架构课》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(95)

  • 最新
  • 精选
  • wesley
    以一个普通的员工聊一聊我对项目的重要性问题的看法吧 大致顺序为 系统紧急修复->高优先级业务需求->收益高的技改项目->普通优先级需求->普通系统维护升级 其中,系统紧急修复,例如最近的log4j事件,是无条件全投入的 在无系统紧急修复的情况下,对于高优先级的业务需求,根据投入、收益和分配到的资源决定具体的注意力分配,优先分配给投入少收益大的项目,其次是 投入大收益大分配资源多的项目,这种项目一般为团队中比较重要的项目,这一点主要以公司的整体战略和发展为先 收益高的技改项目排在第二位,注意是收益较高的技改项目,一般公司都会要求在需求之外有额外的贡献,这种技改项目不仅锻炼技术能力,很可能也是你的晋升关键; 普通需求排第四位,这个是本职工作,不出差错即可 最后的是普通的系统维护升级,保证系统的99.999可用,一般都不需要花费太多的注意力,每周固定抽一段时间集中分析处理即可

    作者回复: 是一个实在人!

    2021-12-14
    3
    23
  • Dom
    第一个问题 业务的项目是无穷的,研发的资源是有限的,首先要明确一点是不可能用有限的资源完成无限的需求,必须针对这些项目进行排序优先级,然后再根据优先级来投入资源。 在投入资源的时候,还需要明确行业的趋势及技术趋势,与我们当前的技术能力,这中间是有Gap,需要正面这两者之间的gap,在整个的业务过程中要不断提升技术框架,达到行业水平。 面对业务的项目,我们要从两个角度来完成,分别是现有研发技术框架完成、提升技术框架完成。这两个角度就需要去做平衡,使用60%的研发资源来完成项目,再使用30%的研发资源来提升技术框架,还有10%的研发资源用于团队的技术能力提升。 那如何去判断哪些项目是60%,哪些项目是30%呢?我主要通过两个维度来衡量,分别是【业务价值】和【技术价值】,通过这两个维度去画四象限,把所有的项目划到这四个象限中,对于业务价值低&技术价值低的项目使用外包或者公共服务的方式进行,对于业务价值高&技术价值低的项目使用当前60%的,对于业务价值低&技术价值高的项目使用10%的研发资源,对于业务价值高&技术价值高的项目使用30%的研发资源 第二个问题 轮子的问题需要注意两点,分别是与业务挂钩、固定的迭代周期。技术轮子开始的时候都很好,往后更多的是一个是一个膨胀的系统,无法管理。这个时候需要想办法让整个技术轮子处于可控状态,通过与业务挂钩,能够保证整个技术轮子的资源投入,不会因为员工离职等各种理由中断。二是需要固定的迭代周期,保持技术轮子的活力,控制复杂度,让整个技术轮子形成稳定循环。 第三个问题 通过技术帮助业务成长,这个会让我觉得非常有价值。 回答完这三个问题后,我自己还想到了黄金圈原则,通过why-how-what的方式来思考业务。我们在活动过程中,经常会使用what指导我们做什么,使用how指导我们怎么样做,但是很少去问why的问题,为什么做?或者通过不断的why可以让我们更明确我们的目标到底是什么。

    作者回复: 特别赞四象限的方法

    2021-12-23
    4
    15
  • ivhong
    思考问题二: 我在以往的经历过的团队中,设计并实现过许多精巧的“轮子”,也许我的“轮子”并不是很关键,有些“轮子”直到我离开公司,一直在转,并且几乎没有过二次维护。我分别介绍一下失败的“轮子”和一直运行的“轮子。 1)失败的“轮子”: 当时在游戏团队,为了提高玩家体验,要做一个兑换码系统,需要批量生成和核销,在接到任务的时候,只有一个需求:一个兑换码只能使用一次。当时我技术老大跟我说,虽说现在需求只有一个,但是未来,我们可能用到一个兑换码可以使用多次,或者一个兑换码可以被不同的人使用多次的情况,你要好好考虑一下哦!于是我就放飞了自我,研究出8种核销兑换码的类型,并且最后上线了。上线之后,就发生了2次bug,出于责任的压力,我直接把另外7中情况在代码中“屏蔽”了,只保留了满足需求中的情况,上线后就再也没有发现过bug。直到我离开团队,另外7种情况也没用到~~ 2)一直转的轮子: 当时团队需要一个日志报警系统,需要给制定的公众号推送报警通知。于是我接下了这个活儿。封装了腾讯SDK、报警策略、调用接口。。。等等,分别单独封装的模块做测试,然后再做整体的“黑盒”测试,最后就上线了。之后只要是接到优化日志报警系统的需求的时候,先考虑:这个需求到底是不是报警系统该做的,如果不该做的,宁愿单独写一套服务,也坚决不往这个系统里放;如果需求是报警系统里的任务,比如增加“短信”报警,或者增加报警策略,就单独增加、或者修改相应的模块,并做好单独的模块测试,再上线。 这些轮子带来的思考:1)千万不要做过度设计,2)模块划分、测试驱动 是很好的开发策略,3)目标单一,非常非常重要!!

    作者回复: “目标单一,非常非常重要” 是的, 其实最终进化出来的技术更健壮

    2022-04-12
    7
  • ivhong
    我是一个10多年的开发,一直是开发,我也想往“上”走,但是“上”又是哪呢?也许是性格上的缺陷,或者是学历的不足,最大可能是是“懒”,哈哈! 思考问题一: 情况1:不该我考虑的不考虑! 这个情况很符合我现在的工作环境,4、5个的项目(不同的框架,甚至不同的语言),一起堆过来,有时真让人抓狂!!遇到这样的问题,我会先那些提出需求的产品经理讨论项目的重要程度(安排优先级)!如果项目经理直接都说自己的项目重要,那么就把所有的项目预计的花费时间列出来,然后找到他们的领导或者我的领导叫到一起讨论优先级的问题(在我这个开发的视角中,是看不到哪个项目重要的,所以这事儿不该我考虑)。不论找不着上级领导确认,最后都要把最后的计划排期做成excel文档,邮件统一发出来,让所有人知道。 情况2:该我考虑的必须考虑! 我对项目优先级的判断先把项目需求现做下面的分类: 1)哪个项目既能高效完成,又能带来收益 2)能高效完成,不会产生拖拉的后果,带来的收益并不是很大 3)带来的收益很大,但是占用长期的开发时间 4)既没有收益,又占用开发时间 我的选择是 1 > 2 > 3 > 4。事事难料,难免全篇一律,所以优先级选择还可能根据所处的环境做不同的选择,单基本上不会变。

    作者回复: 很实用, 你这个行为非常赞!

    2022-04-12
    2
    5
  • neohope
    感觉不同公司情况不一样,不同阶段也不一样,现在大体如下: 1. 涉及公司关键营收的项目,或者说是现在生死存亡的项目,分配50%的精力 2. 对于支撑公司日常运行的项目,分配10%精力 3. 涉及开拓新市场的创新类项目,对其中有盈利能力有增长空间的,或者说公司未来的项目,分配15%的精力 4.涉及开拓新市场的创新类项目,对其中有盈利可能的,或者说可能是公司未来的项目,分配10%的精力 5.对于一些政治类项目,用尽量短平快的方式达到目的,分配7%的精力突击弄完 6.对于一些没有盈利可能的半死不活项目,分配1%精力定期check一下 7.对于一些应该早些下线的项目,分配7%精力早日送走

    作者回复: 最后一项太赞了👍

    2021-12-23
    5
  • escray
    直接进入思考题环节 按以往的工作经历,项目的重要性可能就是按照领导的喜好,或者是即将到来的最后期限。如果让我来决定,那么可以按照重要且紧急、重要不紧急、紧急不重要、不重要不紧急的优先级来排列。 如果让我自己来选,可能也比较喜欢“极简”设计,但是从某种程度上来看,所谓“极简”或者是“敏捷”的设计,有时候也是在思考上懒惰的结果。 在我参与的架构活动中,我比较喜欢和用户接触,去了解需求的过程,因为这样才能真正解决问题。

    作者回复: “我比较喜欢和用户接触,去了解需求的过程,因为这样才能真正解决问题。” 赞!

    2021-12-14
    2
    4
  • 借你一秒
    项目是否会对产品带来实质性的竞争力提升

    作者回复: 这个赞。 你有一个判断方法论吗?

    2021-12-14
    3
  • 日月星辰
    如何判断一个项目的重要性? 要是以前,我会看这个项目是否能让我感兴趣或者勾起我的好奇心,有可能是业务比较有趣或者可以运用新技术。 学完这一课,虽然我不知道公司的战略是什么,但是我会从用户的角度来看,这个项目是否有价值或者意义,再去考虑自己的因素

    作者回复: 谢谢!

    2022-04-13
    1
  • leesir
    关于轮子的思考: 在分布式环境下,任何一次系统调用都会增加复杂度。所以我相信,发明轮子的团队一定深刻考虑过引入新项目所带来的复杂度问题。一个好的轮子,一定会有多个应用场景,在全局的角度看,如果这个轮子能收拢同类功能,让大家一键接入,降本提效,整体效率一定是最优的。 思考过往,总结下自己经历过的好轮子变成废轮子的情况: 1、公司经营环境发生变化,团队职能发生调整。 比如一个中台团队,是为了更好满足于公司各业务线的基础需求而建立的。当因监管或其他因素导致公司业务大量萎缩,中台反而成为累赘,中台人力需要转变为业务人力。那这一大坨中台系统,在业务的视角来看,就会成为过度包装的轮子项目。 2、全局规划与局部紧迫性的不匹配。 轮子项目服务与众多业务线,一个轮子想要变得更好,需要沉淀足够的经验后不断演进。当某个别业务线因为自身的特殊性,总是急需一些定制化的功能又不能被满足时,业务团队不得不另谋出路。要么是fork一个分支,要么是重新做一个。从长期来看,必然是重复建设,但在短期内,在业务团队的视角来看,新的轮子各方面都优于老的轮子。 3、KPI导向。 公司从上到下,都不喜欢一件事情写5年。今年从0-1开发了新东西,反响热烈,第二年从1-10,新增了许多特性。第三年就没有了,取而代之的是另一个关注点有点不同的“一站式解决方案”。为了让绩效更好看,貌似大家都爱这么做。 对于控制不了的原因,只能默默接收。对于kpi以及技术先进性等原因,需要与郭老师一样,紧盯目标,甄别伪需求。目标感是学了2篇文章以来感受最深的一点。

    作者回复: 非常详尽, 赞!

    2022-02-09
    1
  • 学习使我快乐
    第一个问题 1、符不符合公司的战略目标 2、能不能为团队带来正向收益 3、需要各种资源大不大 4、个人是否能获得成长 依照这四个维度综合排序需求,不能成为被别人试错的工具人,做无意义的工作,只是苦劳而不是功劳

    作者回复: 我觉得试错可以的, 尤其是在最大概率的分支上, 也就是说我们认知就到这里了。 觉得可行,试一试。 这样是好的。 把你放在低概率分支上去试错那就不地道了。

    2022-01-19
    1
收起评论
显示
设置
留言
95
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部