许式伟的架构课
许式伟
七牛云CEO
立即订阅
21081 人已学习
课程目录
已完结 87 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (19讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
桌面开发篇 (14讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (13讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
服务治理篇 (10讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (11讲)
57 | 心性:架构师的修炼之道
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式:文本处理
66 | 架构老化与重构
67 | 架构思维篇:回顾与总结
软件工程篇 (10讲)
68 | 软件工程的宏观视角
69 | 团队的共识管理
70 | 怎么写设计文档?
71 | 如何阅读别人的代码?
72 | 发布单元与版本管理
73 | 软件质量管理:单元测试、持续构建与发布
74 | 开源、云服务与外包管理
75 | 软件版本迭代的规划
76 | 软件工程的未来
77 | 软件工程篇:回顾与总结
不定期加餐 (8讲)
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
加餐 | 如何做HTTP服务的测试?
加餐 | 怎么保障发布的效率与质量?
用户故事 | 站在更高的视角看架构
加餐 | 实战:“画图程序” 的整体架构
结束语 (1讲)
结束语 | 放下技术人的身段,用极限思维提升架构能力
免费
许式伟的架构课
登录|注册

74 | 开源、云服务与外包管理

许式伟 2020-01-17
你好,我是七牛云许式伟。今天我们聊的话题是有关于分工的。
在这一讲之前,我们涉及到分工这个话题,基本上都局限于企业内部,且大多数情况下主要在同一个团队内部。但今天我们聊的是更大的分工:跨组织的分工与协作。

外包及其理想模型

在软件工程中,我们第一个接触的外部分工毫无疑问是外包。所谓外包,就是将我们软件的全部或部分模块的实现职能交给外部团队来做。
但是,软件工程项目的外包实际上成功率非常低。这背后有其必然性,它主要表现在以下这些方面。
其一,任务表达的模糊,双方容易扯皮。期望需求方能够把需求边界说清楚,把产品原型画清楚,把业务流程讲清楚,这非常难。有这样专业的需求表达能力的,通常软件工程水平不低,遇到这样的需求方,绝对应该谢天谢地。这种专业型的甲方,它大部分情况下只发生在项目交付型外包,而非产品功能外包。更多的产品外包,一般是甲方不太懂技术,需要有团队替自己把事情干了,他好拿着产品去运营。
其二,交付的代码质量低下,长期维护的代价高。软件工程不是项目,它都需要长长久久地运行下去。但是接包方的选择相当重要。因为接包方的质量相当参差不齐,遇上搬砖的概率远高于设计能力优良的团队。事实上,有良好设计能力的团队,多数情况下也不甘于长期做外包。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • leslie
    每次看许老师的课程都能有所收获:收获不一样的视角和出发点去看待问题与解决问题;老师的课程不止是在教授架构,同时还点出了一个小企业如何去把握技术。
    记得郑晔老师的课程总会在结束时强调一节课结束时记住课程结束时强调能记住一件事就好,许老师的课每次学完第一遍我基本上同样只能记住几句老师课程中的经典:
    1.开源的核心思想是让全社会的程序员共同来完成一个业务系统;
    2.我们尽可能不要做太多事情。非核心竞争力相关的。
    谢谢老师每节课的真心付出和教诲:让老兵们每节课都能真正有所收获-让我们享受学习的过程;谢谢老师的分享,期待老师下节课的分享。
    2020-01-17
    1
    3
  • Geek_88604f
    目前有哪些大厂是采用服务外包的?

    作者回复: Netflix,最著名的案例了

    2020-01-21
    1
  • yga
    许老师的视角就是高!让人耳目一新。

    有个问题请教一下:文中说引入开源项目一定要有正规的评估流程,不知如何评估,需要考虑哪些点

    作者回复: 1、项目的活跃程度;
    2、项目的业务范畴、接口规格、实现是否符合预期;
    3、项目所处的状态,是快速迭代阶段还是进入稳定期、缺陷的数量与严重性如何;
    4、项目活跃参与者的背景。
    等等。

    2020-01-19
    1
    1
  • K战神
    核心业务最好是自己迭代演进。
    我们把其他非核心服务外包给其他团队。
    比如云供应商,这里既划清楚了边界也明确了责任。企业都在试图找到这样的一个点。

    迄今为止,我觉得郑烨老师的课被低估了。
    许大的课更是架构哲学,有时候自己稀里糊涂开发多年竟不知道到底为了什么开发。为了开发而开发?现在老师的课,我有了恍然大悟的感觉。虽然有点模糊,但是已经有了轮廓。
    2020-01-17
    1
  • Lane
    外包还可以这么来?这不就是designed by apple,然后富士康、立讯精密来代工的模式吗

    作者回复: 是这样

    2020-01-28
    1
  • Aaron Cheung
    早上看完 晚上补签到 在老师的说明下 充分认识了“外包”的含义
    2020-01-17
  • Geek007
    核心业务我理解也是一个企业的核心竞争力。也就是说企业的客户为何选择你不选择其他人?如果有其他企业带着一大笔钱进入相同的市场,我们会被替代么? 核心竞争力是需要牢牢把握在企业自己的手里,否则某一天客户就会被外包公司或者其他公司抢走。比如说苹果公司,它是全球协作的典范,整个产业链有无数分工写作,但是苹果的核心竞争力依然牢牢的把握在苹果自己手里。

    作者回复: 核心系统当然是核心竞争力,这一点毫无疑问。我们讨论更多的是哪些不是,哪些可以外包。

    2020-01-17
  • 知行合一
    颠覆了我对外包的认识,老师看问题的高度就是比我们高,谢谢许老师。
    2020-01-17
  • Jeff.Smile
    许老师很是博学,每节课都感觉像是指示明灯!
    2020-01-17
收起评论
9
返回
顶部