01 | 到底应该怎样理解软件工程?
该思维导图由 AI 生成,仅供参考
软件是怎么被创造出来的?
- 深入了解
- 翻译
- 解释
- 总结
软件工程的演化史展现了软件开发从无序到有序的过程,类比建筑工程,将软件开发过程分为需求定义与分析、设计、实现、测试、交付和维护等阶段,形成了软件项目生命周期。瀑布模型的诞生让软件开发更有条理,但其无法应对需求变更的特性促使衍生出V模型、原型设计、增量模型、螺旋模型等模型,试图改善瀑布模型的缺陷。随着轻量级开发方法的提出,敏捷开发逐渐形成燎原之势。近年来,云计算、微服务等新技术的产生也对软件工程产生了影响。软件工程的核心是围绕软件项目开发,对开发过程的组织,对方法的运用,对工具的使用。软件工程的知识建立在软件项目的过程之上,可以总结为:软件工程 = 过程 + 方法 + 工具。软件工程的发展历程展示了其重要性和不断变化的特点,为读者提供了对软件工程的全面了解。
《软件工程之美》,新⼈⾸单¥59
全部留言(58)
- 最新
- 精选
- javaadu软件过程不是搞科研,不是搞艺术,而是解决多人合作将一个想法落地的学科,其中包括严谨的过程步骤、规范,用于提高效率或防范风险的工具。 软件工程的主体是工程,这就要求我们具备基本的工程思维:模块化思维、抽象思维;具备一些关键的意识:质量意识、风险意识、交付意识。
作者回复: 这个总结很赞👍 建议也可以分享到微博或者博客
2019-02-232101 - hua168老师,像我们中小公司,开发人员流失严重,如果像工厂流水线那样,即使核心开发人员全部走了,新招的开发在没有人带的情况下,能继续接上开发…… 出了制定规范,开发文档之外还有那些措施? 我见过核心开发有威胁老板加工资的情况,不加就辞职,要是核心开发都走了,新招的开发都不敢动整个网站,盈利性的,都怕出错。
作者回复: 软件开发,核心就是人,如果没有人,规范和文档都没意义的。要留住人,一个么得舍得给钱,另一个得有个好的环境,还有就是要有梯队,能把新人培养上去。 饭店里只有一个大厨,大厨当然敢乱提要求,如果大厨多几个,就不担心了。还是得要舍得下本钱招优秀的人。
2019-02-25330 - alva_xu对于大型系统的建设,可否用敏捷方法来实现,一直是个问题。敏捷方法,适合于小团队(比如两个披萨团队)、小架构。对于大型单体应用的开发,至少在架构设计上是不适合用敏捷迭代方式的。为了解决大型系统建设的迭代开发、快速交付问题,业内不断在探索。随着微服务架构的提出,以及容器技术的成熟,和cicd的实现,单体巨石应用被拆解成分布式的微服务应用,此时,敏捷方法也就开始真正大行其到了。所以,微服务、容器、devops这三剑客和敏捷方法一起,互为依存、互相促进,成为了软件工程中最有生命力的技术工具和流程,使软件开发在质量和效率上得到极大提升。
作者回复: 总结的赞👍 这些技术得以流行,还有大公司近些年越来越多的实施敏捷,就是因为能帮助把大团队拆分成小团队,大服务变微小服务
2019-02-23228 - 行者无疆关于传统的瀑布模型和现代的敏捷模型如何取舍和运用我一直有个疑问:传统瀑布模型前期进行了完整的需求评估,在技术选型,系统架构,实施路径上可以做好全面的规划,虽然周期长,不必要的反复工作会少很多,目标也更容易控制。那敏捷模型的迭代方式并不会把需求都考虑全面,未来的迭代可能会造成前面的技术架构或者实施细节等都不能满足新需求的要求。所有工作都要重来的问题,会存在大量的重复工作和资源浪费。 敏捷模型是如何有效地规避这些问题的呢?
作者回复: 你说的问题确实存在,导致常说的技术债务问题,所以需要定期去重构,改进这些问题。 迭代过程中的重复工作确实存在,但是软件开发中的浪费其实主要不是在于迭代过程中的重复工作,而是在于需求不明确和需求变更导致的返工或失败。敏捷开发持续发布稳定版本的理念还是利大于弊。 有一些项目其实是瀑布模型和敏捷开发的结合,需求分析和系统设计的时候用瀑布模型,开发和测试阶段用敏捷,也是个不错的选择。
2019-02-2317 - 分清云淡现在已经进入云计算时代,基本上大中小企业都在上云,复杂逻辑都在云端处理,真的还需要软件工程里讲的开发要搞这么多流程么?
作者回复: 是的,云计算的兴起可以减少很多劳动,但不代表你就什么都不用做了,还是要做需求分析,再去做架构设计,做完架构设计你才能清楚哪些可以用云计算,那些需要自己去实现。最后编码完了,一样还要测试的。
2019-02-2315 - 谭鹏开发就是在堆功能 ,领导就觉得软件开发就是工作量的问题 多加班 一周工作六天 一天工作15个小时 就能很快出结果 就是计件工作,结果计划半个月的工作 4个月还完不成 领导就觉的是开发人员有问题
作者回复: 是的,最初大家都以为软件是靠人数堆出来的,以为加人就能减少开发时间,所以后来有了《人月神话》。 不过这个问题,我建议你还是客观分析一下,为什么4个月完不成?是工作量估算问题?还是实现的方法不当? 如果你能帮助找出来原因,并有可以改进的优化方案,对你学习理解《软件工程》是有极大帮助的。 有具体问题欢迎留言。
2019-02-2528 - 一年软件工程在小团队时候没有重视,追求速度,当团队扩大了,需求越来越多了,功能迭代一个接一个的时候,发现项目已经堆积得足够的大了,这个时候如何用软件工程的思维来维护开发质量呢?
作者回复: 你说的这种是常见的现象,在团队扩大后,需要注意几件事: - 对已有项目要考虑偿还技术债务,进行重构。《23| 技术债务:是继续修修补补凑合着用,还是推翻重来?》 - 要考虑逐步规范项目流程,例如要有代码审查、单元测试等规范,不能一味追求速度走捷径绕过这些好的实践《11 | 流程和规范:红绿灯不是约束,而是用来提高效率》 - 可以使用敏捷开发或者借助敏捷开发的一些好的实践,用固定的周期、用持续交付的思路,持续稳定的交付需求。 可以先从这几个角度思考一下。
2019-02-237 - Sam_Deep_Thinking过程其实是将工程分解成各个环节,有了环节自然就有角色,有了角色,就有了沟通。 老师,能再单独的从各个角色出发,说一下各个角色在各个环节中的作用吗?最好把公司经营者也说进去。
作者回复: 这个话题有点大,我建议你可以结合《03 | 瀑布模型:像工厂流水线一样把软件开发分层化》这篇文章阅读。 这里我简单介绍一下: 一个项目立项后,首先要有负责人,组织和推进整个项目的进行,一般这个角色就是项目经理。《10 | 如果你想技术转管理,先来试试管好一个项目》 在项目开始的时候,也就是瀑布模型的需求分析阶段,需要有人去确认需求,根据确定好的需求去设计产品,这个角色就是产品经理。《19 | 作为程序员,你应该有产品意识》 在需求确定后,需要有人设计架构,对需求进行抽象,对模块进行设计和合理组合,这样的角色就是架构师。《23 | 架构师:不想当架构师的程序员不是好程序员》 在架构设计有了后,就可以开始基于需求和架构设计进行编码了,这个角色大家都比较熟悉,就是程序员。《27 | 软件工程师的核心竞争力是什么?(上)》 在编码完成后,需要有人对完成的结果进行校验,以确认满足需求,这样的角色就是测试工程师。《32 | 软件测试:什么样的公司需要专职测试?》 在测试验收通过后,就需要有人将完成的产品发布部署到生产环境,并且对生产环境的运行进行监控,这样的角色就是运维。《36 | DevOps工程师到底要做什么事情?》
2019-10-216 - 贤蛋蛋如果你看过Winston Royce提出瀑布模型的那篇论文会发现,瀑布模型也是迭代式的,只不过被美国军方误用进而导致业界的误解。
作者回复: 👍确实如此,《构建之法》中也有提及。 我们现在所实践的瀑布模型,和论文中提出的模型还是有些差别。
2019-02-266 - 老张在今天没有不可替代的硬件,却有无数不可替代的软件。硬件早已不是共享的壁垒,而曾经被认为有很强可塑性的却已经是最硬的壁垒。 一台服务器、一块磁盘、一根内存以及交换机、防火墙等网络设备,更遑论鼠标、键盘、显示器,在冗余、复用、虚拟化等等技术之下,更换、替代、扩容如此之方便,经过简单培训的工人就可以轻松完成。 可是即便是美国国会图书馆,依然认为纸质是保存资料最好的方式,因为大量资料电子化后存放在不同介质,需要当时定制的软件才能读取这些格式。 今天的软件就是这么硬。也许有一天,有人会写写如何开发真正的软件。
作者回复: 👍
2019-02-246