HarmonyOS鸿蒙最新当今软件发展的现状非常适合 Cloud Native 环境_软件危机当今，2024HarmonyOS鸿蒙春招面试-CSDN博客

本文链接：https://blog.csdn.net/2401_84871020/article/details/138984333

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

软件需求的发展

早期的软件，大多数是由使用该软件的个人或机构研制的，所以软件往往带有非常强烈的个人色彩。早期的软件开发也没有什么系统的方法论可以遵循，完全是“个人英雄主义”，也不存在所谓的软件设计，纯粹就是某个人的头脑中思想的表达。而且，当时的软件往往是围绕硬件的需求来定制化开发的，有什么样的硬件就有什么样的软件。所以，软件缺乏通用性。同时，由于软件开发过程不需要与他人协作，所以，软件除了源代码外，往往没有软件设计、使用说明书等文档。这样，就造成了软件行业缺乏经验的传承。

从60年代中期到70年代中期是计算机系统发展的第二个时期，在这一时期软件开始被当作一种产品被广泛使用。所谓产品，就是可以提供给不同的人使用，从而提高了软件的重用率，降低了软件开发的成本。比如，以前，一套软件，只能专门提供给某个人使用。现在，同一套软件可以批量的卖给不同的人，显然，分摊到相同软件上的开发成本而言，卖的越多，成本自然就越低。这个时期，出现了类似“软件作坊”的专职替别人的开发软件的团体。虽然是团体协作，但软件开发的方法基本上仍然沿用早期的个体化软件开发方式，这样导致的问题是，软件的数量急剧膨胀，软件需求日趋复杂，软件的维护难度也就越来越大，开发成本变得越来越高了，从而导致软件项目频频遭遇失败。这就演变成了“软件危机”。

“软件危机”迫使人们开始思考软件的开发方式，使得人们开始对软件及其特性进行了更加深入的研究，人们对待软件的观念也在发生悄然的改变。在早期，由于计算机的数量很少，只有少数军方或者科研机构才有机会接触到计算机，这就让大多数人认为，软件开发人员都是稀少且优秀的（一开始确实也是如此，毕竟计算机最初制作者都是数学界的天才）。由于，软件开发的技能，只能被少数人所掌握，所以大多数人对于“什么是好的软件”缺乏共识。实际上，早期那些被认为是优秀的程序常常很难被别人看懂，里面充斥着各种程序技巧。加之，当时的硬件资源比较紧缺，迫使开发人员在编程时，往往需要考虑更少的占用机子资源，从而会采用不易阅读的“精简”方式来开发，这更加加重了软件的个性化。而现在人们普遍认为，优秀的程序除了功能正确，性能优良之外，还应该更加让人容易看懂、容易使用、容易修改和扩充。这就是软件可维护性的要求。

1968年 NATO 会议上首次提出“软件危机”(Software Crisis)这个名词，同时，提出了期望通过“软件工程（Sotfwrae Engineeirng）”来解决“软件危机”。“软件工程”的目的，就是要把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”进行转化，从而解决“软件危机”包含两方面问题：

如何开发软件，以满足不断增长，日趋复杂的需求；
如何维护数量不断膨胀的软件产品。

事实证明，在软件的可行性分析方面，事先对软件的进行可行性分析，可以有效的规避软件失败的风险，提高软件的开发的成功率。

在需求方面，软件行业的规范是，需要制定相应的软件规格说明书、软件需求说明书，从而让开发工作有了依据，划清了开发边界，并在一定程度上减少了“需求蔓延”的情况的发生。

在架构设计方面，需制定软件架构说明书，划分了系统之间的界限，约定了系统间的通信接口，并将系统分为多个模块。这样，更容易将任务分解，从而降低系统的复杂性。

今天，制定软件需求的方式越来越多样化了。客户与系统分析师也许只是经过简单的口头讨论，制定了粗略的协议，就安排开发工程师进行原型设计了。开发工程师开发一个微服务，并部署到云容器中，从而可以实现软件的交付。甚至，可以不用编写任何写后台代码，直接使用云服务供应商所提供的 API，使应用快速推向市场。客户在使用完这个应用时，马上就能将自己体验反馈到开发团队，使开发团队能够快速的响应客户的需求变化，并促使软件进行升级。

通过敏捷的方式，最终软件形成了“开发——测试——部署——反馈”的良性循环，软件产品也得到了进化。而这整个过程，都比传统的需求获取的方式将更加的迅捷。

开发方式的巨变

早些年，瀑布模型还是标准的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型优点是严格遵循预先计划的步骤顺序进行，一切按部就班，整个过程比较严谨。同时，瀑布模型强调文档的作用，并要求每个阶段都要仔细验证文档的内容。但是，这种模型的线性过程太理想化，主要存在以下几个方面的问题在：

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果；
各个软件生命周期衔接花费时间较长，团队人员交流成本大。

瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的，所以瀑布式方法非常适合需求明确的软件开发。但在如今，时间就是金钱，如何快速抢占市场，是每个互联网企业需要考虑的第一要素。所以，快速迭代、频繁发布的原型开发、敏捷开发方式，被越来越多的互联网企业所采用。甚至，很多传统企业，也在逐步向敏捷的“短平快”的开发方式靠拢。毕竟，谁愿意等待呢？

客户将需求告诉了你，当然是越快希望得到反馈越好，那么，最快的方式莫过于在原有系统的基础上，搭建一个原型提供给客户作为参考。客户拿到原型之后，肯定会反馈他的意见，是好或者坏的方面都会有。这样，开发人员就能根据客户的反馈，来对原型进行快速更改，快速发布新的版本，从而实现了良好的反馈闭环。

今天，Cloud Native 的开发方式正在流行。Cloud Native 是以云架构为优先的应用开发模式。Cloud Native 利于最大化整合现有的云计算所提供的资源，同时也最大化节约了项目启动的成本。