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

37|能力维度二:如何提升解决横向问题的能力?

熟悉代码和业务
与日常工作正向促进
商业回报容易量化
找到促进日常研发任务的支点问题
意识和习惯问题
抖音号:“郭东白”
郭东白
3. 稳定性重大问题总结
2. 团队横向领域的技术机会
1. 从程序员到兼职架构师的心得
兴趣、回报、人才供给竞争
最大化ROI策略
意愿和投入
性能
Save yourself:故障响应保底原则
Availability without cost consideration:中小企业CTO视角
When it comes to survival:高可用性保障方法论
Everything decays:分布式系统设计
Only rely on the most reliable:系统工程学科
Trust none:Defensive Coding
6. Save yourself
5. Availability without cost consideration is bullshit
4. When it comes to survival, everything can be downgraded
3. Everything decays, especially data
2. Only rely on the most reliable
1. Trust none
与日常代码工作连续性大
个人受益
稳定性是企业的第一性问题
竞争环境
商业价值
个人兴趣
责任边界
2. 优先级取舍
1. 认知盲区
技术债:性能、可扩展性、可用性、可测试性、可维护性、安全合规
兼职架构师:解决横向问题
程序员:结构化完成业务需求
作者信息
思考题
小结
其他横向问题
稳定性法则的出处和背景
稳定性经验分享
为什么从稳定性开始
解决横向问题的策略
跨越能力障碍
技术债产生原因
横向问题定义
角色差异
从程序员到兼职架构师的能力提升

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

你好, 我是郭东白。我们上节课讲了,程序员的结构化设计能力是向架构师过渡的重要基础。假设你现在已经拥有了这项基础能力,想开启自己的架构师职业生涯新篇章,那么该从开始呢?
这节课我们就来讨论一下这个话题。

从程序员到兼职架构师

我们先研究一下程序员和兼职架构师这两个角色的区别:
在软件架构这个上下文里,程序员指的是能够结构化地完成业务需求的一线软件工程师。
在软件架构这个上下文里,兼职架构师指的是能够解决自己所负责领域的横向问题的软件工程师或研发管理者。
从定义的描述中,我们很轻松就能看到两个角色的差异主要是在横向问题上。也就是说,兼职架构师这个角色,除了需要关注自己的代码外,还要关注横向问题。
横向问题,简单来说就是软件系统内部与业务无关的技术债,比如性能、可扩展性、可用性、可测试性、可维护性和安全合规等问题。这些问题都属于非功能性需求,也就是说,产品经理一般不会把这些问题直接写在需求文档里。
技术债的产生一般有两个原因:
你与周围同事在横向问题领域内有认知盲区;
由于日常研发过程中的优先级取舍,导致一些技术债被短期搁置。
可是日积月累,这些技术债必然会成为整个团队的负担,影响软件的整体质量。这个时候你就要意识到:机会来了!
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

程序员成为优秀架构师需要解决横向问题的能力,即软件系统内部的技术债。稳定性和性能是关键,作者分享了稳定性生存实用指南和强调性能的重要性。横向能力的深度和稀缺性在公司发展到一定规模时更为重要。在过渡到架构师的过程中,主动规划和投入度至关重要,兴趣和投入度最终带来能力的稀缺性。作者还分享了自己总结的稳定性法则,鼓励读者在工作中不断总结并修正。思考题包括跨越从程序员到兼职架构师的心得、团队中的横向技术机会、以及最近半年遇到的稳定性重大问题。

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

全部留言(16)

  • 最新
  • 精选
  • spark
    郭老师,take away~~~这篇内容提出了硬伤的问题。举例,有一个同事是女孩,结婚了,天天码业务代码,横向问题需要的技术积累根本搞不定,最后被淘汰了~~~ 我的例子,用了4年,天天住在酒店里(每天酒店费用200以上),节省上下班2小时,积累了算5000小时技术~~~ 技术积累需要兴趣、战略。智商普通,往往是逼到死,才能突破一点点。我的经验,至少也需要5000小时左右的技术积累,才能解决大部分技术相关的常规横向问题~~~

    作者回复: 5000个小时的积累, 都是硬通货啊! 不过我们的确处在一个极度内卷的时代。。。

    2022-05-17
    5
    13
  • jjn0703
    如果你曾经跨越过从程序员到兼职架构师这个障碍,能分享一下最大的心得吗? -------- 我们组有10人左右的后端,去年年末,组长休了产假,我兼职了两周的管理者(也许不能叫架构师)。兼职期间印象最深刻的是,要求我做一下来年组内工作规划,最大的心得就是,架构师要思考团队的人员配置、任务分配,考虑团队的技术栈,考虑怎么去提升研发效能等,总之和做研发是完全不一样的视角。

    作者回复: “视角的跨越”, 谢谢!

    2022-05-18
    7
  • Sean Zhao
    最大的心得,大概是勇于挑战问题吧,勇于尝试独立解决问题。 曾经有个同事抱怨说:我都干了五六年程序员了为什么还天天curd。 后来我给他一个从零开始工作,让他从设计文档开始。 结果他遇到任何问题都是先找别人讨论,然后把讨论结果写到设计文档里。愣是不敢先尝试自己拿一个方案。 怕错,不敢尝试自己做,甚至连自己独立思考的勇气都没有,如何能够跨出这第一步呢。 栗子有点极端,是真事。当我看到那份设计文档的时候,我第一次有了这样的认知。勇于独立开拓,勇于不依赖周边的人,才有跨越边界的可能。

    作者回复: 离例子非常非常赞👍

    2022-09-28归属地:北京
    6
  • tiny
    猪队友永远在你最危急的关头出现 ---------------------------------- 其实在顺风顺水的情况下,自己的个人能力能cover猪队友的猪行为,所以“猪”无关紧要,但是在紧急关头,这些猪队友可能是直接拖垮自己的最后一根稻草。 平时的时候就应该鉴别出这些猪队友,适当做一些隔离和有意无意留一些防护性证据,保护自己!

    作者回复: 赞回复。

    2022-07-24归属地:美国
    5
  • 钱嘉
    现在团队里面的横向领域中,最大的技术机会在哪里?我个人觉得我最想解决的问题是减少需求消耗的开发资源。一种情况是需求小、数量多,每一条需求还是要走全量的流程,很多开发资源就浪费在这里。第二种是很多需求深入研究后都是共性的需求,完全可以一套方案在保证一定扩展性的前提下解决所有

    作者回复: 你讲的第一种情形往往是业务平台试图解决的问题, 也有可以通过框架来解决的。 第二种还是比较难做好的。 一般实现需求的人都急于上线,很难看到跨领域和跨需求的抽象。

    2022-12-09归属地:美国
    2
  • young2
    从程序员到兼职架构师,我主要的体会是视野的开阔,原来想着大概这个领域技术的业务知识都了解了,好像没什么提升的点推动自己学习提升。转变角色后发现还有开发效率、性能优化这些更有挑战性的事情,成为兼职架构师的同时也参与技术管理,团队产出和组员培养也是一个重要的指标。

    作者回复: 是的, 认知的维度提升了一维, 很重要

    2022-06-13
    2
  • 罗杰
    第二个问题:我目前的工作是做游戏后端架构,带四五个人。公司没有运维,所以开发和运维的活都是我们干。在横向领域中,最大的技术机会是如何使用当前火热的 K8S 来 Server Mesh 来解决我们的运营困境。公司规模小,不可能组建运维团队,也几乎无法在一个二线城市招聘到合适的人才,所有这一切都需要我牵头去做。而我其实也并非能有这么多的时间花费在这些事情上。开发、技术管理和已经在运营的游戏都需要抽出精力去做。而且团队太小,引入这么大的复杂性是否有可能我也在考虑。主要是学习的成本并非一朝一夕,另外随着年龄的增长,我慢慢发觉职业初期或者在学校里面没有打好的基础,越来越凸显其重要性了。好多时候复杂的问题搞不明白,其实是底层的东西我们根本不了解。最基础的东西不研究透彻,盲目的追求那些火热的概念,反而会让自己更加迷惑。

    作者回复: “最基础的东西不研究透彻,盲目的追求那些火热的概念,反而会让自己更加迷惑” 讲得非常好, 感谢!

    2022-05-22
    2
    2
  • 花花大脸猫
    第一个问题:感觉也没有明确的界限,就是平常做事事事都会深入一些,关注的内容会广一些,会更多思考一些新的想法或者实现形式,久而久之,对于稳定性,性能,易用性,可扩展性就有一些自己踩坑之后的总结以及深度学习后自己的一套独特的认知,然后也会找机会与别人沟通输出一些想法,听取别人的意见。

    作者回复: 嗯, 很多人都是这样的。 其实究其原因还是passion驱动。 能够在探索中找到乐趣。

    2022-12-31归属地:美国
  • Geek_e214d6
    老师,我有个疑惑: 作为架构师,需要代码review吗?最近我发现,开发人员不按架构规划的套路开发,最后,因为不按套路导致环境出了问题,再来找你救火。这种情形,怎么解决

    作者回复: 这个一般比较难安排吧。 不在同一个团队, 代码review比较难安排。

    2022-09-08归属地:美国
  • 术子米德
    🤔☕️🤔☕️🤔 * 📖:横向问题~~~软件系统内部与业务无关的技术债~~~性能、扩展性、可用性、可测性、可维护、安全合规…… * 🤔:技术债,这个词看到就扎眼,如果说自己正在做的事情,就是在给未来者构筑债务,打死我也不肯承认,如果说自己接手的东西,有一点不是就喊成技术债,有点没头没脑对着空气喊ShaX的感觉。到底何谓技术债?就像最近接触到遗留系统这个概念,其中不能自动化测试,就是遗留系统的特征。技术债是否也有典型特征? * 🤔:曾经我对功能性需求和非功能性需求困惑得不行。直到有一天,看到书上说,所谓非功能性需求,就是质量属性。有点被启发的感觉,但是又不知道被启发在哪里。问自己,功能性需求,就是客户为此买单的项目,那质量属性,客户不买单嘛?先换个视角。如果我自己是客户,那我就只会付钱我要的功能,如果出现安全类的质量问题,我会全盘帅锅给供应厂家。这是我坏到骨子里嘛?也算,也不算。我之所以能甩锅,不就是我支付了维护费用嘛。再切换到供应商的视角,既然我收到维护费用,那我肯定是收进这笔钱,然后就不想产生任何额外的费用,落进我口袋的东西,再拿出来不是要我命嘛。Duang,就在这个瞬间,脑子里忽然间冒出来,为当下埋单的钱叫做功能,为未来埋单的钱叫做质量。为何我要追求高质量,就是不让自己埋未来的单,也就是降低未来的成本,才能真正提高利润。说白了,就是不要欠技术债。我滴天,所谓技术债,就是别给未来埋单的机会。 * 🤔:想明白非功能性需求、质量属性、埋未来的单,算是我自己认识自己是个架构师的入门之礼🎁。

    作者回复: 你是在翻来复为的读这个专栏??

    2022-05-30
    2
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部