许式伟的架构课
许式伟
七牛云 CEO
84946 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 89 讲
许式伟的架构课
15
15
1.0x
00:00/11:10
登录|注册

结束语 | 放下技术人的身段,用极限思维提升架构能力

讲述:丁伟大小:10.21M时长:11:10
亲身经历的架构能力提升
通过规格串起整个业务系统
长期养成自我review代码的习惯
自学编程语言
与同学合买电脑
极限思维对架构能力提升的重要性
反复打磨既有系统
review自己的代码
规格为先,实现为后
学会“认同他人,反思迭代自己”
学会“共情”
全局视角掌控工程的演进方向
不仅架构师需要架构能力
武器库:业务只读、接口稳定、易于组合的模块 + 组合的方法论
分层:基础架构 + 业务架构
架构思维的范式在工程实践中的应用
从零开始构建信息世界
架构不是简单的知识点
架构思维的重要性
软件工程的特殊性
传统项目工程的架构师角色
作者的经历
提升架构能力的意识训练
放下技术人的身段
架构能力的属性
信息科技的演化过程
成为优秀的软件工程架构师
架构师的存在
结构
主题:架构能力的提升
时长:10个月
作者:七牛云许式伟
标题:放下技术人的身段,用极限思维提升架构能力
文章

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

你好,我是七牛云许式伟。
这个专栏从去年 4 月份至今已经有 10 个月左右的时间,到了要和你说再见的时候了。感谢你的一路相伴,感谢你的坚持。也希望这些内容能够对你有所帮助。
从工程角度来说,架构师的存在几乎是一种必然。传统项目工程也有架构师的角色,只不过软件工程有其特殊性,它快速变化,充满了不确定性,所以架构师的重要性的比重会被进一步放大。
但是如何才能成为优秀的软件工程架构师?
传统的架构图书往往从架构思维开始。但是,我认为它们错了。这里面最关键的问题在于:
架构并不是 “知识点”。
架构思维的确非常非常重要。但是,熟读架构思维并不足以让人成为一名优秀的架构师。
关于这一点,我经常拿中国传统的武学文化做类比。武功招式可以精确传授,是 “知识点”,掌握了就是掌握了,理论上可以做到分毫不差。但是,架构不是武功招式。它更像内功,它不是 0 和 1,没有清晰的掌握和没有掌握这样泾渭分明的区别。
在架构能力上,没有最好,只有更好。
这是为什么我们的架构课并不是从架构思维开始,而是采用双线结构。它基本上围绕着以下两个脉络主线来展开内容:
如何从零开始一步步构建出整个信息世界;
在整个信息世界的构建过程中,都用了哪些重要的架构思维范式,以及这些范式如何去运用于你平常的工程实践中。
这两大脉络相辅相成。
首先,我们通过还原信息世界的构建过程,剥离出了整个信息世界的核心骨架,这也是最真实、最宏大的架构实践案例。
其次,我们结合这个宏大的架构实践来谈架构思维,避免因对架构思维的阐述过于理论化而让人难以理解。
最后,架构就是对业务系统的正交分解。因此,整个信息科技的演化过程,自然而然形成了分层:基础架构 + 业务架构。
基础架构的产生是对业务架构不断深入理解的过程。越来越多的共性需求从业务架构抽离出来,成为信息科技的基础设施。
作为架构师,我们需要坚持对业务进行正交分解的信念,要坚持不断地探索各类需求的架构分解方法。这样的思考多了,我们就逐步形成了各种各样的架构范式。
这些架构范式,并不仅仅是一些架构思维,而是 “一个个业务只读、接口稳定、易于组合的模块 + 组合的方法论”,它们才是架构师真正的武器库。
这个武器库包含哪些内容?
首先,它应该包括信息科技形成的基础架构。努力把前辈们的心血,变成我们自己真正的积累。光会用还不够,以深刻理解它们背后的架构逻辑,确保自己与基础架构最大程度上的 “同频共振”。
只有让基础架构完全融入自己的思维体系,同频共振,我们才有可能在架构设计需要的时候 “想到它们”。
这一点很有趣。有些人看起来博学多才,头头是道,但是真做架构时完全想不到他的 “博学”。
从体系结构来说,这个基础架构包含哪些内容?
其一,基础平台。包括:冯·诺依曼体系、编程语言、操作系统。
其二,桌面开发平台。包括:窗口系统、GDI 系统、浏览器与小程序。当然我们也要理解桌面开发背后的架构逻辑,MVC 架构。
其三,服务端开发平台。包括:负载均衡、各类存储中间件。服务端业务开发的业务逻辑比桌面要简单得多。服务端难在如何形成有效的基础架构,其中大部分是存储中间件。
其四,服务治理平台。主要是以容器技术为核心的 DCOS(数据中心操作系统),以及围绕它形成的整个服务治理生态。这一块还在高速发展过程中,最终它将让服务端开发变得极其简单。
理解了这些基础架构,再加上你自己所处行业的领域知识,设计出一个优秀业务系统对你来说就只是轻车熟路而已。
这也是为什么这个架构课的内容结构是目前这个样子组织的。因为消化基础架构成为架构师自身的本领,远比消化架构设计原则,架构思维逻辑要难得多。
消化基础架构的过程,同时也是消化架构思维的过程。
把虚的事情往实里做,才有可能真正做好。
当然提升架构能力,不完全与成为架构师这件事情等同。
架构能力其实是一种属性,并不是只有架构师需要架构能力。软件开发工程师、SRE、甚至包括产品经理,都需要具备架构能力。
而架构师这个特殊的岗位,则是因为软件工程的需要而产生的。它从更全局的视角来把控工程的演进方向,以确保整个业务系统经历几年甚至几十年的迭代,仍然可以快速适应变化,而不至于老化。
成为架构师并不是一件纯技能的事情。
架构师需要放下技术人的身段,学会 “共情”。与用户共情,理解用户的所思所想。与开发人员共情,理解技术人的所思所想。与公司共情,理解公司的发展诉求。
架构师需要学会 “认同他人,反思迭代自己”。不要在不了解背景的情况下,随意推翻别人写的代码,而理由可能仅仅是不符合你的个人风格。当然反过来完全看不到项目的问题同样要不得,但这往往是受限于个人能力。要提升自己的架构水平,需要在实践中不断反思,不断在自我否定中成长。
不过我们今天把话题的重心收敛到架构能力上。怎么才有意识地通过训练来提升自己的架构能力?
实践对架构能力不可或缺。
在现实中,不少技术人员连函数规格都想不清楚。他们关心你是怎么 “实现” 的,但是却不关心 “接口规格” 是什么样的,接口规格是否符合函数的 “业务语义”。
要提升架构能力,首先得做到规格为先,而不是实现为先。不要动不动问怎么实现的。要首先谈这个规格合不合理,是否存在多余的依赖。进一步来说,要多去谈这个函数(或软件实体)的业务范畴合不合理,是否应该换一个切分的姿势。
其实 review 自己的代码也是一种极佳的架构能力的提升手段。对自己刚刚写完的代码,去 review 它,从中找出问题。如此反复训练,就能实现自我能力的提升。
这其实是最高效的自我提升的方式。如果团队其他成员 code review 发现了你的问题,你得反思一下为什么自己发现不了。
很多人追逐实现新的业务系统,通过做新系统来找到满足感。但是实际上对架构师来说,恰恰是反复打磨既有系统是更加锻炼人的。如果你一年前实现的系统今天仍然很满意,那就需要警醒,因为这一年你在原地踏步。
在架构能力上,没有最好,只有更好。
这里我想分享一段我自己 review 自己代码的特殊经历。事情发生在我大学期间,当时的电脑相对我们大部分学生的购买力来说,还是非常昂贵。所以我和另外 4 个同学花了 7500 元合买了一台电脑。
结果就是,我们 5 个人轮流使用这台电脑。这意味着,我一周平均只能用一天多一点时间。再刨除上课时间,我真正能够上机的时间并不多。
而当时的我对编程非常着迷,所以我绝大部分的上机时间都花在编程上。作为物理系的学生,正常来说我学的编程语言是 Fortran。但我很快就把 Fortran 课程自学完了,并从老师口中和 Fortran 课程的附录中了解到了 C 语言。
于是我找物理系高年级的同学搞到了 Turbo C 2.0,开始翻遍学校图书馆的图书自学 C 语言。
为了能够高效利用一周只有一天多的上机时间,我尝试把程序写到纸上,并且提前进行 code review,确保尽可能多地发现程序中的错误,以减少上机过程中的调试时间。
在一次数学建模竞赛里,我和另外两位同学(廖唯棨和程胜峰)一组,其中用到了 Dijkstra 的最短路径算法。看完算法逻辑的介绍后,我直接一遍写成最终的代码,没有经过任何调试过程。
这让在旁边看着的同学廖唯棨觉得很神奇,问我是不是之前实现过 Dijkstra 算法。但其实于我而言,这不过是长期养成自我 review 代码习惯的结果而已。
这个习惯持续了三年之久。这三年里,我开始的时候都是先把代码写到纸上并完成 review,然后再到电脑上。但是到后期这个习惯就变了,我不再需要把所有细节都提前写到纸上,而是只需要提前准备好骨架:整个程序串起来的思路是什么。
我大学期间写过很多高代码量的程序。其实第一个 C 程序就不短,是一个仿 DOSKEY 的程序。后来也做过汇编语言的 IDE。这是因为学汇编的时候,发现没有好的汇编语言集成环境,于是就自己做了一个。至于为什么学汇编?是因为我想写一个 C++ 编译器,感受一下语言实现者的体验。另外,我也尝试在 DOS 操作系统下实现了一个图形界面库,并用它做了图片查看器和 MP3 播放器。
在代码量非常大的时候,人的脑容量就完全无法把这个实现装到头脑中。这时 “规格重于实现” 背后的意义就完全体现出来了。通过规格串起整个业务系统,以此把业务系统装到脑子里,这就是很朴素的架构 “骨架” 思维。
这不是一个假想实验。
它是我的亲身经历。这段经历启发我意识到极限思维对架构能力提升的重要性。
架构没有最好,只有更好。在极有限的上机时间里,在没有电脑的情况下,我们只能选择把更多的逻辑装进脑子里。
这个过程还可以更进一步。我们不断训练自己对不同业务领域的架构范式的理解。直至最终,我们头脑中可以装得下整个信息科技的骨架。
到那时,单就架构能力而言,你就是最顶级的架构师了。
备注:我在文末准备了一份调研问卷,也欢迎你点击下方的图片参与调研,期待你的反馈。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

通过本文,我们了解到架构师需要不断提升自己的架构能力,而这并不仅仅依赖于架构思维,更需要通过实践和对基础架构的深入理解来实现。作者强调了放下技术人的身段,学会共情,并通过规格为先、代码review等方式来不断提升自己的架构能力。文章还分享了作者在大学期间编程的特殊经历,强调了通过反复打磨既有系统来锻炼自己的重要性。作者通过个人经历启发读者意识到极限思维对架构能力提升的重要性,强调架构没有最好,只有更好,并鼓励读者不断训练自己对不同业务领域的架构范式的理解,最终成为顶级的架构师。

2020-01-3113人觉得很赞给文章提建议

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

全部留言(50)

  • 最新
  • 精选
  • spark
    老师的专栏让我懂了一个架构师的上限,懂了上限就是见识和视野,也是努力的效率和做事的边界; 把一件事情做到极致就是一种信仰,老师同时把几件事情都做到极致; 用中国人磕头的方式表达敬意。

    作者回复: 客气啦🤝

    2020-02-07
    10
  • 亢(知行合一的路上)
    通过规格串起整个业务系统,现在正在实践,先把类的对外接口明确,用到了哪些数据结构,以及重要函数的实现逻辑伪代码,让系统在逻辑上是通的,然后再填充实现细节。

    作者回复: 👍

    2020-04-23
    2
    4
  • 木木
    越看越感觉架构能力就是抽象的能力,从业务中提取共性,发现规格,规律,对现实的模拟,对本质的理解。

    作者回复: 👍

    2021-08-18
    2
  • 沫沫(美丽人生)
    最近因为公司业务正在忙着移动办公的事情。来不及第一时间道谢,有少许遗憾。首先感谢许老师百忙中为我解答了这么多困惑,从这个课程受益匪浅。其次我们的邮件系统图片和文档的存储用的也是七牛云,遇到问题都很快的解决了我们的问题,有时候我们的商业场景需要从国外的服务器访问资源文件。也期待徐老师关于数据运营的更多分享。还有就是能不能开一门算法和数据结构的课,来更好的赋能国内的信息产业。谢谢!

    作者回复: 🤝

    2020-02-09
    2
  • nanquanmama
    其他架构专栏是百家争鸣 这个专栏是老子传道
    2020-02-02
    46
  • leslie
    10个月不容易:从开始坚持到最后;结束语早已看完,尾笔却一直不知如何去写;老师在付出的同时我也在坚持学习,最忙的时候一周5-6门的极客时间课程完全只能不断的压缩本就不多的睡眠时间。 借用老师的结束语”放下技术如的身段,用极限思维提升架构能力“:这个就像在问自己"什么是极客"?曾经一段时间陷入过这种困惑,为此看了不少极客时间的视频甚至问过池老师这个问题,事物做到极限且尽全力的去追求一种平衡,这个路上只有不断的广度与宽度以及不断的换位思考才能做好。 老师的课程中有提及好的产品经理应当从架构师出来,反其道而行之其实完全可以;合理的循序渐进我觉得才是我们所追求的路。学习的过程中和一些企业沟通过,提出的观点其实就是基于全栈去帮助一些企业梳理清楚了他们真正应当想要的是什么团队且看到了效果。 当市场或者说技术越来越复杂时:越往上就越要不断的换位,从应用层、设计层再到需求层,甚至有时觉得这个过程就像是网络协议,来回之间的换位找到最合适当下且具有扩展性的方案才是努力做的事情。 感谢一路以来老师的分享与解惑,学习中让我不断的去切换视角补充资料;2019年能把最初的年度计划12门最终扩充到了50门功课和学习中不断看到问题不读补充和充实自己是密不可分的。愿老师新年快乐,同时期待老师将来能有更好的专栏分享。谢谢老师。
    2020-02-01
    23
  • J.Smile
    约一个半月跟完了,起初看许老师的课很其他人一样感觉很不同,许老师并不是像其他架构课一样讲一些看起来很前沿的技术细节,而是从0到100完成了架构世界的进化史,这比了解任何技术细节更重要,而且跟进课程的过程中解答了许多我们作为程序员进阶过程中的困惑,非常感谢许老师,期望再出新作!
    2020-01-31
    11
  • Enthusiasm
    许老师的本科专业是物理学,物理学就是总结和阐释世间万物的运行规律的学科,物理学往上是Mataphysics(形而上学),说白了就是哲学...在IT领域,许老师用同样的方法给系统架构中的知识点做了一次升华,有时就像是在讲哲学一样,而哲学就是最抽象,最需要反复琢磨的学问.正如结束语所说,只有把一切道理化简成最抽象的骨架,我们才能真正说自己掌握了架构思维,又如华罗庚所说的先把书读厚,再把书读薄,是一样的道理.许老师的课,无不在实践和传达这个道理.
    2020-05-10
    10
  • 有米
    done !花了2个星期看完了,接下来就是重新梳理总结和输出,后续持续跟进补充,在工作中领悟。并不是看完了就能做架构师,要不然就真的是满天飞了。 另外,我学习不太喜欢长达半年的隔2天看一篇,这样思路容易断掉,我喜欢短时间内集中精力攻克并输出。 就像看电视剧一样,我也不喜欢天天追,我喜欢花个几天时间沉浸式的看完。
    2020-04-04
    7
  • Aaron Cheung
    规格为先 许老师的教诲非常受益 要提升架构能力,首先得做到规格为先,而不是实现为先。不要动不动问怎么实现的。要首先谈这个规格合不合理,是否存在多余的依赖。进一步来说,要多去谈这个函数(或软件实体)的业务范畴合不合理,是否应该换一个切分的姿势。
    2020-01-31
    6
收起评论
显示
设置
留言
50
收藏
88
沉浸
阅读
分享
手机端
快捷键
回顶部