2019-02-23软件过程不是搞科研，不是搞艺术，而是解决多人合作将一个想法落地的学科，其中包括严谨的过程步骤、规范，用于提高效率或防范风险的工具。
软件工程的主体是工程，这就要求我们具备基本的工程思维：模块化思维、抽象思维；具备一些关键的意识：质量意识、风险意识、交付意识。作者回复: 这个总结很赞👍
建议也可以分享到微博或者博客 1 56- 2019-02-23对于大型系统的建设，可否用敏捷方法来实现，一直是个问题。敏捷方法，适合于小团队（比如两个披萨团队）、小架构。对于大型单体应用的开发，至少在架构设计上是不适合用敏捷迭代方式的。为了解决大型系统建设的迭代开发、快速交付问题，业内不断在探索。随着微服务架构的提出，以及容器技术的成熟，和cicd的实现，单体巨石应用被拆解成分布式的微服务应用，此时，敏捷方法也就开始真正大行其到了。所以，微服务、容器、devops这三剑客和敏捷方法一起，互为依存、互相促进，成为了软件工程中最有生命力的技术工具和流程，使软件开发在质量和效率上得到极大提升。
作者回复: 总结的赞👍
这些技术得以流行，还有大公司近些年越来越多的实施敏捷，就是因为能帮助把大团队拆分成小团队，大服务变微小服务 1 11 
2019-02-23现在已经进入云计算时代，基本上大中小企业都在上云，复杂逻辑都在云端处理，真的还需要软件工程里讲的开发要搞这么多流程么？作者回复: 是的，云计算的兴起可以减少很多劳动，但不代表你就什么都不用做了，还是要做需求分析，再去做架构设计，做完架构设计你才能清楚哪些可以用云计算，那些需要自己去实现。最后编码完了，一样还要测试的。
8
2019-02-25老师，像我们中小公司，开发人员流失严重，如果像工厂流水线那样，即使核心开发人员全部走了，新招的开发在没有人带的情况下，能继续接上开发……
出了制定规范，开发文档之外还有那些措施？
我见过核心开发有威胁老板加工资的情况，不加就辞职，要是核心开发都走了，新招的开发都不敢动整个网站，盈利性的，都怕出错。作者回复: 软件开发，核心就是人，如果没有人，规范和文档都没意义的。要留住人，一个么得舍得给钱，另一个得有个好的环境，还有就是要有梯队，能把新人培养上去。
饭店里只有一个大厨，大厨当然敢乱提要求，如果大厨多几个，就不担心了。还是得要舍得下本钱招优秀的人。 7
2019-02-23关于传统的瀑布模型和现代的敏捷模型如何取舍和运用我一直有个疑问：传统瀑布模型前期进行了完整的需求评估，在技术选型，系统架构，实施路径上可以做好全面的规划，虽然周期长，不必要的反复工作会少很多，目标也更容易控制。那敏捷模型的迭代方式并不会把需求都考虑全面，未来的迭代可能会造成前面的技术架构或者实施细节等都不能满足新需求的要求。所有工作都要重来的问题，会存在大量的重复工作和资源浪费。 敏捷模型是如何有效地规避这些问题的呢？作者回复: 你说的问题确实存在，导致常说的技术债务问题，所以需要定期去重构，改进这些问题。
迭代过程中的重复工作确实存在，但是软件开发中的浪费其实主要不是在于迭代过程中的重复工作，而是在于需求不明确和需求变更导致的返工或失败。敏捷开发持续发布稳定版本的理念还是利大于弊。
有一些项目其实是瀑布模型和敏捷开发的结合，需求分析和系统设计的时候用瀑布模型，开发和测试阶段用敏捷，也是个不错的选择。 6
2019-02-24在今天没有不可替代的硬件，却有无数不可替代的软件。硬件早已不是共享的壁垒，而曾经被认为有很强可塑性的却已经是最硬的壁垒。
一台服务器、一块磁盘、一根内存以及交换机、防火墙等网络设备，更遑论鼠标、键盘、显示器，在冗余、复用、虚拟化等等技术之下，更换、替代、扩容如此之方便，经过简单培训的工人就可以轻松完成。
可是即便是美国国会图书馆，依然认为纸质是保存资料最好的方式，因为大量资料电子化后存放在不同介质，需要当时定制的软件才能读取这些格式。
今天的软件就是这么硬。也许有一天，有人会写写如何开发真正的软件。展开作者回复: 👍
5
2019-02-26如果你看过Winston Royce提出瀑布模型的那篇论文会发现，瀑布模型也是迭代式的，只不过被美国军方误用进而导致业界的误解。作者回复: 👍确实如此，《构建之法》中也有提及。
我们现在所实践的瀑布模型，和论文中提出的模型还是有些差别。 4
2019-02-25开发就是在堆功能 ，领导就觉得软件开发就是工作量的问题 多加班 一周工作六天 一天工作15个小时 就能很快出结果 就是计件工作，结果计划半个月的工作 4个月还完不成 领导就觉的是开发人员有问题作者回复: 是的，最初大家都以为软件是靠人数堆出来的，以为加人就能减少开发时间，所以后来有了《人月神话》。
不过这个问题，我建议你还是客观分析一下，为什么4个月完不成？是工作量估算问题？还是实现的方法不当？
如果你能帮助找出来原因，并有可以改进的优化方案，对你学习理解《软件工程》是有极大帮助的。
有具体问题欢迎留言。 1 4
2019-02-23软件工程是为应对软件复杂，需求多变而产生的理论，方法，工具的集合。作者回复: 👍
还需要注意软件工程的目标是构建高质量的软件。 4
2019-02-25土木工程专业转行程序员，好巧，原专业是建在实实在在的土建工程，现在是在虚拟世界建造数字工程。作者回复: 早期软件工程很多借鉴建筑工程的，相信可以帮助你更好的理解👍
3- 2019-02-24很多时候领导想要做的项目都是拍脑袋的想法，需求很模糊，不明确。如何才能做好需求分析？
作者回复: 需求需要反复沟通确认的，是一个从粗到细的过程。
最开始可以画草图，找相似产品对比，确认大方向。
然后把你的理解制作成原型，用原型去确认，根据反馈再反复修改。
最终确认了后再去开发。 3 
2019-02-23我理解工程就是在现实中，协调各种资源，完成复杂工作，解决具体问题的一系列标准、规程、方法，软件工程则是针对于软件开发领域的工程策略集。作者回复: 👍
3
2019-02-23软件工程的本质在于工程。
利用工程理论来保证高质量软件产品的产出。
工程讲究效率，成本，质量。
除此之外容易忽略是工作量与效益的权衡，这一点尤为关键。作者回复: 👍总结的很好
3
2019-02-23软件工程在小团队时候没有重视，追求速度，当团队扩大了，需求越来越多了，功能迭代一个接一个的时候，发现项目已经堆积得足够的大了，这个时候如何用软件工程的思维来维护开发质量呢？作者回复: 你说的这种是常见的现象，在团队扩大后，需要注意几件事：
- 对已有项目要考虑偿还技术债务，进行重构。《23| 技术债务：是继续修修补补凑合着用，还是推翻重来？》
- 要考虑逐步规范项目流程，例如要有代码审查、单元测试等规范，不能一味追求速度走捷径绕过这些好的实践《11 | 流程和规范：红绿灯不是约束，而是用来提高效率》
- 可以使用敏捷开发或者借助敏捷开发的一些好的实践，用固定的周期、用持续交付的思路，持续稳定的交付需求。
可以先从这几个角度思考一下。 3
2019-10-21过程其实是将工程分解成各个环节，有了环节自然就有角色，有了角色，就有了沟通。
老师，能再单独的从各个角色出发，说一下各个角色在各个环节中的作用吗？最好把公司经营者也说进去。作者回复: 这个话题有点大，我建议你可以结合《03 | 瀑布模型：像工厂流水线一样把软件开发分层化》这篇文章阅读。
这里我简单介绍一下：
一个项目立项后，首先要有负责人，组织和推进整个项目的进行，一般这个角色就是项目经理。《10 | 如果你想技术转管理，先来试试管好一个项目》
在项目开始的时候，也就是瀑布模型的需求分析阶段，需要有人去确认需求，根据确定好的需求去设计产品，这个角色就是产品经理。《19 | 作为程序员，你应该有产品意识》
在需求确定后，需要有人设计架构，对需求进行抽象，对模块进行设计和合理组合，这样的角色就是架构师。《23 | 架构师：不想当架构师的程序员不是好程序员》
在架构设计有了后，就可以开始基于需求和架构设计进行编码了，这个角色大家都比较熟悉，就是程序员。《27 | 软件工程师的核心竞争力是什么？（上）》
在编码完成后，需要有人对完成的结果进行校验，以确认满足需求，这样的角色就是测试工程师。《32 | 软件测试：什么样的公司需要专职测试？》
在测试验收通过后，就需要有人将完成的产品发布部署到生产环境，并且对生产环境的运行进行监控，这样的角色就是运维。《36 | DevOps工程师到底要做什么事情？》 2
2019-03-10如果说软件工程=过程+方法+工具，其中过程是否就是具体指软件的生命周期？方法是指选用的生命周期模型，比如瀑布、螺旋、迭代、敏捷？作者回复: 我认为过程应该包含过程模型采用的方法。而方法是指基于过程模型之下的方法。
因为过程模型决定了软件开发过程是什么样的，进而决定了采用什么开发方法。
比如你选择了瀑布模型，整个软件开发过程就是按照瀑布模型的分阶段来进行，对应的方法就是瀑布模型中的方法，例如需求分析、架构设计；如果你选择了敏捷开发，则整个开发过程就是一种敏捷迭代方式，后面的方法对应的就是敏捷开发的一套方法体系，例如Scrum、用户故事、持续集成等。 2
2019-03-02为致力于产生更高质量产品，软件开发以单一的编码，向着分工更明确，工作效率更高的方向前进。作者回复: 赞👍
总结的很好，后面可以再看看软件工程是怎么去达到这个目标的。 2
2019-03-01软件是程序+数据结构+文档。
软件工程，是可用性与开发难度之间平衡的技术，是效率提高与成本增加之间的博弈作者回复: 赞
在《构建之法》里面，也有另一种定义：
软件=程序+软件工程 2
2019-02-28我刚去百度了一下手工耿，简直要笑死了。这个专栏的老师和编辑真时髦，啥都知道编辑回复: 你的求知精神，也是很赞呢😁😄
2
2019-02-25软件工程和建筑工程这个类比很到位，能够比较直观的理解做好软件工程的重要性。软件工程过程中的每一步，其实和建筑工程类似，早期的房子比较简单，整个房子的模型很容易想象出来，而房子和内部的装修越来越复杂，靠几个人几乎不可能完成，软件也是类似。
但是在实际开发软件的过程中发现，如何内化这种软件工程的思维，还是有很大困难，因为对于一个新项目，往往最终的需求都不是很明确，很难去规划最终要把软件做成什么样？这里还应该和做软件设计的工程师的经验，知识架构，业务理解程度有关系。作者回复: 是的，还是需要经验的积累，学习不是一蹴而就的事。还是有些方法可以帮助你做的更好。比如说需求不明确，可以尝试原型设计；可以尝试快速迭代，早确认需求。
2