一旦您进入软件开发，旧驱动程序就会提供一些建议

作者: 华为云专家|人民副院长阿伯丁

1960年代爆发的软件危机催生了软件工程. 人们希望通过工程技术来管理，设计，构建和维护软件. 从那时起，最聪明的工程师一直在寻求更好的软件. 在路上很难找到.

开发语言已经过汇编，C，C ++，Java，Erlang，Python;编程范例包括面向过程（POP），面向对象（OOP），通用（GP），功能（FP）；从单机到分布式的云软件架构，包括Boulder，库组件模块服务，分层，微服务，MVC / ServiceMesh / Serverless等；软件工程的思想和方法包括瀑布模型（专注于以生命周期管理为核心的流程）（瀑布模型），专注于以需求演化为核心的迭代和敏捷开发（敏捷开发）以及领域驱动设计（DDD: 域驱动设计），以边界划分和控制为核心.

世界是丰富多彩的. 将现实世界映射到虚拟软件并非易事. 软件开发是一种权衡的艺术. 例如敏捷软件开发 源码，快速交货和安全生产经常相互矛盾. 开发效率和运营效率始终保持一致. 因此，在漫长的软件开发历史中，人们发明了一种解决问题的方法，几乎​​总是引入另一个问题，软件工程师不得不面对混乱的世界.

面向过程的（C）认为一切都是一个过程，并且可以将现实世界封装到单个过程中，并且通过级联和编排过程来模拟世界. 但是，由于使用软件解决了复杂的业务问题，因此该范例缺乏足够的抽象性. 尽管功能可以看作是模块化技术的最小粒度，但它们仍不能弥补模块化，过程和功能不足的不足. 操纵数据的分离也使软件偏离了高内聚和低耦合的方向.

为了解决上述问题，面向对象的范例（C +++ / Java）被设计为通过对象对世界进行建模. 对象将属性和方法封装在一起，并通过公共接口与外界交互，从而为软件设计提供逻辑层次. 模块化手段；而且，物体和现实世界的东西很容易映射. 对象通过组合来表示更复杂的概念，并通过接口来概括更抽象的概念.

使用泛型的动机更简单. 需要一种语言机制来解决跨数据类型提供标准容器的障碍. C ++提供了通过模板语言机制对类型进行参数化的功能，在编译时进行类型检查以及类实例化的能力，不仅保证了类型安全性并提高了执行效率，而且还增加了编译时间并损害了可读性，尤其是引入了新的游戏玩法，例如模板元编程使事情更加复杂.

UML诞生于流行的瀑布模型时代. 它是一种独立于特定编程语言的面向对象的建模工具. UML将面向对象的开发分解为三个阶段: 分析（OOA），设计（OOD）和编码（OOP）. ，此过程着重于分析和设计以及轻视编码的实现.

由于设计和实现被划分为两个相互制约的阶段，因此在开发过程中将存在两个模型，即UML图纸中所示的设计模型和隐藏在软件源代码中的实现模型，其中两个这个阶段将不可避免地导致设计和编码之间的分裂. 与不同的人进行设计和实施的实现似乎有助于分工和协作，但实际上增加了通信成本并降低了交付效率.

学者们曾经试图根据建筑师的UML设计图自动生成代码，看起来很漂亮敏捷软件开发 源码，但实际上只有在有限的情况下才能实现此目标；以及日益复杂的商业软件的开发过程中，工程学院认为在开发和维护上花费了更多时间. 最终的交付物只能是源代码，而不能是工程图，因此开发人员只能为了舒适而求助于设计原理（SOLID）和设计模式（GOF）. 设计师以“建筑师”开销而闻名.

瀑布模型的过程难以逆转，其结果只能在项目的后期看到. 为了应对瀑布的缺陷，敏捷开发试图改善软件开发的端到端通信方法. 极限编程（XP）是敏捷开发轻量级软件工程方法论的一种实现，它试图以螺旋方式发展，极限编程面临着软件活动的复杂性，承认不能在最初阶段就巩固要求，并主张开发人员应通过引入基本值，原理，方法和其他概念来灵活地响应需求变化，从而优先考虑代码.

敏捷发展体现在Internet蓬勃发展中. 根本原因是互联网应用的需求是动态的，很难严格遵循繁重的传统瀑布模型过程.

敏捷的重新原型方法甚至被误解为根本不需要设计和文档的开发方法. 敏捷的优点同时也是缺点. 毫无疑问，在人员流动大的情况下，增加文件编制的重要性. 难以维护，并且面对领域知识的复杂组织和应用，敏捷开发也受到质疑.

随着Web Service应用程序的爆炸式增长，以Java代表的新兴语言正在崭新的发展，并且Controller-> Service-> Dao或SOA设计已转变为行业的标准解决方案. 服务层扮演上帝的角色，所有事物都被填充进去了，所有的逻辑都被填充进去了，填充有吸气剂/填充剂DAO的贫血模型充满了恶臭. 数据驱动的开发模型已陷入泥潭，领域驱动的设计已进入人们的视野.

2003年，埃里克·埃文斯（Eric Evans）倡导的域驱动设计（DDD）将“域核心”视为企业最重要的资产，并倡导通过泛在语言消除表达的不准确性. 域驱动设计继承并开发了敏捷开发. DDD将领域和设计视为软件设计的核心，这使业务人员和开发人员可以得到同样的关注. 建议一起工作以捕获拥塞的域模型. DDD战略设计从宏观角度确定边界上下文，而战术设计则在实现级别提供一些最佳实践.

传统模型秉承以数据（库）为中心的概念，而领域驱动的设计则转移到以领域模型为中心，这是基本的设计变更. DDD将问题空间和解决方案空间划分为四个边界，以确定核心，常规和支持这三个子区域. 在边界范围内，通过分层（基础层-域层-应用程序层-表示层）实现内部和外部隔离，并形成应用程序层. 提供保护层可有效隔离业务复杂性和技术复杂性. 以域层作为整个系统的稳定和凝聚力的核心是域驱动设计的关键特征.

回顾软件工程发展中出现的各种理论，每一种流行趋势都有一套不言自明的理论，它们都声称可以完美地解决一些问题，但无一例外，它们都落入了另一个框架陷阱，但是没有它们可以结束软件工程的无序设计. 我们不能跳出重构循环的自我娱乐周期，我们仍然处在充满各种技术债务的困境中，因此，跳出各种框架模型的精神束缚，回顾一下，我们不妨重新检查设计的本质，我们不妨考虑一下处理软件复杂性的基本原理.

解决复杂软件问题的方法可以简单地分为抽象，分解和隔离几个点.

在软件变化的洪流中，软件工程的先驱和先贤提出了各种编程思想和方法论，但是还没有一个从根本上彻底解决问题. 《神话中的月人》第16章因为软件工程是一个非常复杂的系统，所以可以断言没有万灵药，不仅不能治愈所有疾病，而且还指出在未来十年内可以没办法将效率提高十倍.

回顾历史，每一个完美的解决方案都从现有的解决方案开始，声称可以解决所有问题，然后进行布道，将公众带入精心设计的逻辑闭环中，然后虔诚地追随者，然后从理论到项目，最终交付的代码仍然充满各种歧义和污秽. 任何进化都可能导致瞬时不变性崩溃，留下羽毛，而那些新颖的理论最终将像烟一样散落在广阔的历史天空中.

古代: 我天生无知，但并不愚蠢，但教育使人们变得愚蠢. 古人说: 没有思想就学习是懈怠的. 因此，我们应该意识到投机的重要性. 对于知识，我们学习并学习，但不要盲目地跟随它. 在处理软件工程时，我们应坚持哪些原则？

首先，人是关键. 对于软件开发，没有最终的解决方案，因为软件是人们思想的外在化，并且人们本身充满缺陷. 我们必须认识到人类在抽象过程中不可避免的缺陷，以及人类抽象能力的差异，这意味着与规则和过程相比，人类实际上是软件实现过程中的灵魂. 思想和法律可以为人们提供指导，但是它们不能神奇地解决软件工程中的所有问题. 影响软件开发质量的关键因素是人员，而不是设计方法. 专注于形式而不是内容，专注于文档而不是交付的代码，都是颠倒的.

第二，从事实中寻求真相，对特定问题进行具体分析，并且软件覆盖范围太广，这意味着每个特定的实现规则都有其局限性. 它不能用严格的标准来困住自己的手脚，也不能固执. 由于规则，这是一个教条. 您不能使用天剑来剪指甲，也不能使用龙刀刮胡子. 例如，最简单的业务CRUD模型可能就足够了，有些可能适用于CQRS，六边形体系结构，贫血领域中的某些对象也可能可用，某些事件在暴风雨模式下可能更好，有时应该使用数据和操作分开，甚至阅读和写作. 应该将其分开，有时将数据和操作更好地封装在一起，并且只有将它与实际的刀子分开，这只会增加笑声.

第三，几乎所有语言和技术都有好坏两面，并且具有适用性，例如C. 尽管它缺乏抽象功能，但其核心语法集非常简单. 简单意味着专注且可靠，这意味着对程序员的要求更低. 您只需要掌握几十个几十年来没有改变的STD C API即可构建所有应用程序，但是您必须认识到它缺乏抽象能力和开发效率. 尽管C ++具有良好的抽象能力，但其语法集太大，并且似乎很难限制每个人以最小的公共知识作为行动，但是如果能够达成共识，或者如果每个人的水平都很高，那么它编写的程序就在那里确实是更好的可维护性.

第四，纪律！是的，纪律是关键. 无论方法体系多么完善，如果团队不能严格执行方法体系规定的纪律，那都是空话. 无论是整洁的编码，体系结构设计，敏捷开发还是领域建模，只有持续且持续地遵守纪律和纪律施加的约束条件才能不断提高质量.

最后，尽管没有灵丹妙药，但我们不应该太悲观. 软件工程一直在不断发展. 通过进一步的步骤，我们可以解决大量问题并引入一些可控的副作用. 但是从宏观的角度来看，软件工程仍然伴随着人类社会的不断进步.

那么为什么不尝试接受瑕疵呢？

点击以了解并首次了解华为的新云技术

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/ruanjian/article-251909-1.html