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

68 | 软件工程的宏观视角

软件工程的不确定性
管理学的确定性
快速变化
不确定性
Fortran诞生
C语言诞生
50年历史
软件工程的未来
人力资源规划
质量管理
团队分工与协同
软件工程全过程
管理挑战
特点
历史
结语
架构师的职责
软件工程
软件工程的宏观视角

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

你好,我是七牛云许式伟。

软件工程

今天开始,我们进入第六章,谈谈软件工程。
我理解的架构师的职责其实是从软件工程出发的。也许大家都学过软件工程,但如果我们把软件工程这门课重新看待,这门学科到底谈的是什么?是软件项目管理的方法论?
无论如何,软件工程是一门最年轻的学科,相比其他动辄跨世纪的自然科学而言,软件工程只有 50 年的历史。这门学科的实践太少了,任何一门学科的实践时间短的话,都很难沉淀出真正高效的经验总结,因为这些总结通常都是需要很多代人共同推动来完成的。
为什么说它只有 50 年时间呢?
我们先来看看 C 语言,一般意义上来说,我们可能认为它是现代语言的开始。C 语言诞生于 1970 年,到现在是 49 年。再看 Fortran,它被认定为是第一个高级语言,诞生于 1954 年,那时候主要面向的领域是科学计算。Fortran 的程序代码量普遍都还不大,量不大的时候谈不上工程的概念。
这也是我为什么说软件工程这门学科很年轻,它只有 50 岁。对于这样一个年轻的学科,我们对它的认知肯定还是非常肤浅的。
我在这个架构课的序言 “开篇词 | 怎样成长为优秀的软件架构师?” 一上来就做了软件工程和建筑工程的对比。通过对比我们可以发现,二者有非常大的区别,具体在于两点:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

软件工程的宏观视角是一篇探讨软件工程的文章。作者从软件工程的年轻性、不确定性和快速变化等方面入手,指出软件工程与传统工程的区别,并强调软件工程的管理难度。文章还阐述了架构师的职责,强调了架构师需要对软件工程的执行结果负责,包括按时按质进行软件的迭代和发布、敏捷地响应需求变更、防范软件质量风险、降低迭代维护成本。此外,文章还提到了团队的共识管理、如何阅读别人的代码、如何写设计文档、发布单元与版本管理、软件质量管理、开源、云服务与外包管理、软件版本迭代的规划等与架构师工作密切相关的话题。最后,作者表示软件工程是一个新兴、复杂的话题,需要时间形成更清晰的认知。整体而言,这篇文章从宏观视角全面探讨了软件工程的特点和架构师的职责,对于了解软件工程的读者具有一定的参考价值。

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

全部留言(17)

  • 最新
  • 精选
  • Bachue Zhou
    感觉这样的架构师不仅让产品经理失业了,还让项目经理失业了😄

    作者回复: 产品经理关注的维度不太一样,关键词是:用户需求、技术赋能、商业成功。而架构师的关键词是:用户需求、技术实现、业务迭代。产品经理与架构师是一体两面,对人的能力要求的确会比较像,但是分工不同。项目经理在很多公司并不存在,它是交付类工作比较多的情况下的产物。

    2019-12-31
    5
    24
  • Geek_88604f
    关于软件工程的论述让人大开眼界,特别是关于软件工程本质的归纳高度很不一般。结合老师关于软件工程的宏观论述和当下的现状有一些疑问: (1)微服务对软件工程管理带来了很大的冲击。微服务强调小而自治,快速开发,快速发布,快速试错。微服务的研发团队通常也很小,10个以下,3~5也很常见,用户的需求怎么做几个人碰个头就开搞了,没有架构师参与,质量保证工工作也不多。这样做也不是没有道理,因为有些需求最终有多少用户使用可能是个未知数,投入的资源很可能带不来价值。这种情况下软件工程应该怎做。 (2)软件工程和微服务治理之间有没有什关联?传统的软件工程是服务上线前的治理,服务治理是服务上线后的软件工程。随着服务治理技术的发展,高可用用、高性能等质量属性通过服务治理就能搞定,会不会逐步降低线下质量保证工工作的重要性?

    作者回复: 1、微服务会让团队对架构能力产生更大的依赖。架构把控力不强的团队,大半会被微服务带进坑里。我们评价一个团队的架构能力好坏,看的关键是是否能够“坚持最小化的核心系统不变”,如果增加一个微服务团队不需要改变核心系统,那只能说你们的架构太牛了。 2、服务治理解决的是无缺陷系统的稳定运行,并不能解决非可用性相关的问题。

    2020-01-04
    6
  • py
    项目管理有去评判一个项目成不成功狭义来讲是项目有没有在限定的时间、资源把项目成功交付, 广义的来讲是项目客户满不满意、项目的成果有没有被应用并产生预期效果。 视角不一样 境界完全不一样,架构师也一样

    作者回复: 👍

    2019-12-27
    2
    6
  • 沫沫(美丽人生)
    许老师,有些产品就是要解决某个领域的特定问题的,像CRM这样的产品。像好用和易用大部分是由于产品设计决定的,如果一个产品设计的不好,比如用户使用的场景化考虑的不够,交互设计不够,这种情况下,架构师有什么好的办法吗可以让开发出来的产品好用呢,谢谢啦。易用性指标上,架构师可以做什么贡献呢?

    作者回复: 易用性需要打磨,没有捷径。所有角色都可以对产品提出见解,最终形成多个不同的方案来对比。

    2019-12-31
    2
    3
  • Charles
    许老师,如你所说产品设计阶段架构师参与其中,虽然有比较明确的职责,产品负责需求边界、架构负责技术方案,决策的时候有冲突了,这个时候依靠什么去决策?七牛一般怎么做?盼复,谢谢

    作者回复: 还是产品经理决策。如果还有疑义,可以找双方共同的上级。

    2019-12-27
    2
    3
  • Apa琦
    四年了不知道许老师还会不会回复,我有个小问题想请教一下。之前我一直认为架构可能就一层,看了一些架构书和您的课,逐渐理解架构可能有好多层,个人理解是有业务架构,应用架构(如果集群构成的子系统,nginx,数据库,各种中间价形成的),代码架构(具体到程序员写代码的分层模块如service,控制器等),不知道这样理解是否正确

    作者回复: 架构是分层的。最基础的架构是计算机的硬件架构,然后有操作系统和其他中间件构成的基础架构(当然你也可以把硬件硬件包含在基础架构中),然后再是应用架构。详见第一节的内容。业务架构我的理解就是指应用架构,代码架构可能和架构没啥关系,虽然有架构一词。

    2023-10-28归属地:上海
  • 诗泽
    许老师后续是否可以讲一下ai的浪潮下对做工程的同学以及架构师们带来的改变有哪些

    作者回复: ai 背后更大的浪潮,是马云说的 DT(数据科技)

    2019-12-27
  • 丁丁历险记
    其二,快速变化。建筑工程在完工以后就结束了,基本上很少会进行变更。但在软件工程里,软件生产出来只是开始。只要软件还在服务客户中,程序员们的创造过程就不会停止,软件系统仍然持续迭代更新,以便形成更好的市场竞争力。 这一段语音读错了,修改一下。

    作者回复: 收到

    2019-12-27
  • milley
    非常期待后面的课程,特别是如何阅读别人的代码
    2019-12-27
    2
  • Aaron Cheung
    期待软件工程的未来 在老师说的很多基础服务固化之后 后端工程师还能在何处进行发展
    2019-12-27
    1
收起评论
显示
设置
留言
17
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部