软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

21 | 架构设计:普通程序员也能实现复杂系统?

宝玉 2019-04-16
你好,我是宝玉,我们已经正式进入到“系统设计”这个主题模块,今天我们先来聊一聊“架构设计”。
早些年,软件很简单的时候,不需要需求分析和架构设计,直接采用边写边改(Code And Fix)模型,也能做出来。后来软件复杂了,就对程序员要求特别高了,所以早些年的软件开发,都是个人英雄主义盛行。比如张小龙一个人完成了 Foxmail,求伯君完成 WPS,王江民写 KV 杀毒软件……
不过,那时候对于普通程序员来说,去写这样复杂的系统,也是可望而不可及的。再后来软件产品越发复杂后,靠高手的开发模式也不可行了。
软件需求越来越多,而高手又是稀缺资源,所以要解决的一个问题就是:让普通程序员也能参与其中,一起实现复杂系统,而不必依赖于很多精英。

为什么软件项目需要架构设计?

要想实现让普通程序员也能实现复杂的软件系统,我们先要看看什么样的是复杂的软件项目。复杂的软件项目,通常有两个特点:需求不确定和技术复杂。
关于需求不确定,我在前面的文章已经讲了很多,我们主要来看看技术的复杂性。技术的复杂性,主要体现在四个方面。
1. 需求让技术变复杂
如果需求本身很复杂,那么对应的技术也会很复杂。比如说你做一个个人博客网站,和做一个淘宝这样的网站,技术复杂度是有天壤之别的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • kirogiyi
    淘宝这样的网站,需求复杂、功能点多、访问量大,微服务可以对各业务进行拆分,细粒度的保证功能的清晰度和完整性,方便多人分工协作;降低相互间的依赖,减少资源冲突,以便于维护和部署。与此同时,在访问量大的时候,可以很容易的进行网络数据分流,减小单个服务的负载。

    而个人微博,需求点少,功能单一,基本上只是作为数据输出的载体,不需要用户过多的交互操作,并发访问量也不会太大,一般单个服务就可以胜任。

    极客时间的架构我觉得使用微服务架构比较好,用户管理、专栏文章管理、视频教程管理、评论管理、支付管理、优惠活动管理等等需求相对比较复杂,使用单服务不利于扩展、维护和部署。另外,还要考虑安全性、稳定性、流畅性方面的问题(钱啊,很重要,容不得半点马虎)。

    作者回复: 👍感谢分享!

    微服务是个不错的选择。

    极客时间好像不是用的微服务,参考这篇《极客邦池建强:难的不是从零打造一款产品,而是……
    》:
    https://www.infoq.cn/article/q7xlHaaiZ-9H6SwHXCNg

    2019-04-16
    7
  • 一路向北
    架构设计,一要有思想为基础,二是必须实践相结合,架构设计需要有高屋建瓴的眼光。架构的思想相当于是前人实践经验的总结。不过每次看这些架构的思想方法的时候,总是和实际的应用没能很好的结合起来,原因是不是架构设计的实践不够?或者是对各种实现的分析和思考太少?

    作者回复: 我觉得不仅要有架构实践,还要有不同场景的实践。

    举个例子来说,你平时做企业应用架构,没什么流量,没多少数据,复杂的地方都在业务逻辑,这时候你去看那些讲大数据、讲高并发的文章,很难带入到场景去。

    还有就是一些架构,不自己搭一遍是很难了解其中的优缺点的,这也是另一个原因。

    可以考虑有机会自己尝试把看到的一些好的架构实际的用一个原型程序搭一遍,造一点数据出来,用工具压测一下,这样会更有感觉更有深刻体会。

    和实际应用想结合的问题,一方面说明你现有的架构可能并没有什么大问题,没有那么迫切的需求要改造;另一方面可能还是因为缺少实践经验,心里没底,不知道真用上了有没有用。

    一点浅见,供参考。

    2019-04-18
    4
  • Mr.Chen
    老师好,持久层应该怎么理解,我感觉是数据库和数据操作层的和

    作者回复: 持久层如果包括数据存储(数据库和文件存储都算),那么就是你说的“数据库和数据操作层的和”。

    如果和数据存储层分开,那么就是指数据库访问相关操作。

    2019-07-25
    3
  • alva_xu
    老师,我们正好在考虑SOA架构,研究esb、api gateway等。前几天我写了篇文章发在博客上了,请老师点评。谢谢。《从巨石应用到微服务应用,从ESB到APIGateway,从前后端分离到中台出现,九九归一,Rest要一统天下?》, https://blog.csdn.net/alva_xu/article/details/89052040

    作者回复: 已拜读!因为对你的业务不了解,也不好妄加评价。

    当业务复杂到一定程度,分拆是很有必要的👍

    2019-04-16
    3
  • Felix
    深受代码整洁之道影响,喜闻架构整洁之道一书,立即入手,期待ing

    作者回复: 确实是很不错的书👍

    2019-04-18
    2
  • hua168
    宝哥,架构师与开发有什么区别呀?
    架构师一定要懂开发吗?是不是只负责架构设计然后让开发去做就行了?
    感觉架构师比开发清闲呀,名字也高大上,工资也不错吧~~~

    作者回复: 这个问题下一篇就会详细解答 :)

    架构师可不清闲,只是分工不一样而已,架构师大部分时间不是在写代码,而是在了解业务,在构思架构,做好比开发难多了。工资也要高很多!

    2019-04-17
    2
  • 青石
    项目计划和架构设计类似,都是自顶向下,由粗到细的过程。

    至于用图说话,只能勤画来练习了。确实很佩服那些脑子里装满了流程图的兄弟。

    作者回复: 是的,其实多画画就越来越熟练了。

    2019-04-16
    2
  • gfkdcadet
    老师推荐的资料一流!

    作者回复: 赞,有用就好。也欢迎推荐你觉得好的资料。

    2019-04-16
    2
  • dancer
    基于用例图分析软件需求,确认软件中关键角色和功能和HeadFirst OOAD里讲的一样。我觉得一开始不确定软件的访问量以及复杂度的时候,选用分层设计是非常好的。当业务发展好,需求越来越复杂 人员组织越来越大时,架构也会随之变化。

    作者回复: 分层架构确实是经典的符合服务端特点的架构。

    2019-04-16
    2
  • 小老鼠
    1、可否基于各种语言来介绍架构类型,比如JAVA、Python …
    2、如何做好数据库选型、web服务选型,比如Tomcat 、jboss、weblogic、Django、Flask⋯

    作者回复: 1. 语言更多的是实现的工具,通常对架构设计并不是决定性的,比如说分层架构,Java/C#都可以实现,甚至于不同层不同的语言;

    2. 数据库选型可参考《22 | 如何为项目做好技术选型?》

    2019-09-17
    1
  • butterflies
    老师您好,我现在自学python 遇到一些瓶颈,写的脚本有时候总是进行有难度,页面跳转还有页面闪退都有问题?还有对一些项目架构理解不够深刻 请问老师怎样才能更好的去实施呢?

    作者回复: 我觉得遇到这种问题,你可以先识别一下问题,比如说页面跳转或者页面闪退有问题,需要先甄别问题在哪里,如果还不能甄别,那么先增加一些相应的日志,缩小问题范围,直到能找到问题在哪里,找出来问题就好寻找解决方案了。

    解决问题的时候,总结归纳,解决一个问题争取能把一类问题都解决,以后再遇到类似的问题就不用担心了。

    项目架构理解是需要一个过程的,一开始先看,了解有哪些好的架构,然后再是用架构,用的过程中去体会总结架构好的地方不好的地方,或者说适用的领域,以后就知道什么情况下用什么架构了。

    架构的实施可以先从模仿开始,然后逐步增加适合自己业务特点的内容,最后再考虑是不是要设计出自己业务特色的架构。

    2019-05-09
    1
  • 纯洁的憎恶
    降低软件工程的参与门口,以调动更大规模的协作,从而解决更难更大的软件问题。架构设计可以在一定程度上解决技术复杂度问题,从而降低软件开发的复杂度,让更多的普通程序员参与进来。分而治之。把复杂系统抽象分解为多个简单的小模块,或者划分若干相对独立的层次,不至于牵一发而动全身。

    作者回复: 👍很好的总结分享

    2019-04-23
    1
  • R
    宝玉老师好
    反馈一下,上面评论里的链接不能选中复制 😂

    作者回复: 🤦‍♂️这个是极客时间的产品设计问题,建议根据文章标题搜索一下,很好找

    2019-04-18
    1
  • calvins
    极客时间的架构从需求方面分为两部分,第一是用户使用部分,第二是后台管理部分,后台管理包括文章,视频上架等商品类,优惠策略,广告等,访问量不大,内部员工使用,一般来说保证高可用就够了,用户使用部分,可以理解为商城部分,这部分主要面向用户,因为知识付费商城的特殊性,不会像电商网站那么高的并发,更重要的是稳定性与响应速度,所以web和app端可能基础服务是同一套逻辑实现,入口渠道,app,小程序,网站,后台服务商品展示为一类,广告活动为一类,订单支付为一类,用户管理为一类,基本上这四大块就能涵盖,所以传统的mvc三层结构就能满足。
    2019-11-29
收起评论
14
返回
顶部