软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6695 人已学习
课程目录
已完结 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讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

“一问一答”第3期 | 18个软件开发常见问题解决策略

宝玉 2019-05-09
你好,我是宝玉。我们专栏已经完成了架构设计和开发这两个模块的学习。这两个模块都是和技术有很大关系,也是很多人关心的内容。
希望你通过对架构设计内容的学习,能控制好软件项目中技术复杂的问题。遇到技术选型,能心中有数,通过一个科学的过程去完成选型;对于项目中的技术债务,能及早识别,及早应对。
通过对开发模块的学习,可以帮助你在项目中搭建持续集成环境,推行自动化测试,改进基于源代码管理工具的开发流程。借助工具和流程,让你项目的开发质量更上一个台阶。
本篇继续分享同学们的精彩留言,这些问答和同学们的分享都是对专栏内容的最好补充,希望可以帮助你更好地学习和理解软件工程知识。

一问一答

No.1
一路向北:每次看这些架构的思想方法的时候,总是和实际的应用没能很好的结合起来,原因是不是架构设计的实践不够?或者是对各种实现的分析和思考太少?
宝玉:我觉得不仅要有架构实践,还要有不同场景的实践。
举个例子来说,你平时做企业应用架构,没什么流量,没多少数据,复杂的地方都在业务逻辑,这时候你去看那些讲大数据、讲高并发的文章,很难带入到场景去。
还有就是一些架构,不自己搭一遍是很难了解其中的优缺点的,这也是另一个原因。
可以考虑有机会自己尝试,把看到的一些好的架构用一个原型程序搭一遍,造一点数据出来,用工具压测一下,这样会更有感觉。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • Sudouble
    以前天天追着某种开发语言的语法,最近渐渐地意识到,学好语法其实也仅仅起了个头,如同刚学会写字的小学生,要写出优美的散文,又是另外一回事了。

    还有是测试驱动开发的强大之处。自己写了一个小软件,最近要加新功能和补bug,庆幸那时候忍着补齐了测试代码,不然在改动里真是寸步难行。

    作者回复: 👍是呀,语言学会不难,要用好才行!

    测试覆盖很重要,重构的时候就省心了!

    2019-05-10
    1
  • _CountingStars
    重构最重要的原则是小步快跑 甚至小到你觉得这一步没有必要 这样做的意义是可以随时停下来 不影响用来的功能正常运行 如果出错 由于步子小 你很容易能找到哪里修改出现了错误 重构之前一定要写测试 如果没有测试你将不知道自己的重构有没有破坏原来的功能。

    测试可以使用BDD的测试形式 测试不是说为每一个函数 每一个类写一个单元测试 应该为那些 public api 写测试,为使用场景写测试。想把测试写好 可以看看 那本测试驱动开发 tdd by example 重构强烈建议看看 重构第二版 注意看每一个重构小步骤 每一个小步骤都是为了可以让重构随时停下来 而不影响原来的功能

    作者回复: 👍👍非常有价值的分享!

    2019-05-09
    1
  • kirogiyi
    特别感谢宝玉老师准备如此精彩的专栏,使我们无论在技术、架构、产品、管理方面都得以全面成长。看到IT同行如此多独特的见解,受益匪浅,同时发现自己还有很多需要思考和践行的地方。

    作者回复: 也谢谢你还有其他很多的精彩留言,补充了很多有用的分享👍

    2019-05-09
    1
  • 纯洁的憎恶
    学习到的知识一定要多用,而且要变着花样的用。

    作者回复: 👍知识应用了才能变成自己的

    2019-05-10
收起评论
4
返回
顶部