我对软件工程的反思

什么是软件工程?

WIKI 百科中给出的定义是:

是[软件开发]领域里对工程方法的系统应用。
1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。

软件工程的背后是软件危机

1970年代和1980年代的软件危机。在那个时代，许多软件最后都得到了一个悲惨的结局，软件项目开发时间大大超出了规划的时间表。一些项目导致了财产的流失，甚至某些软件导致了人员伤亡。同时软件开发人员也发现软体开发的难度越来越大。在软件工程界被大量引用的案例是Therac-25的意外：在1985年六月到1987年一月之间，六个已知的医疗事故来自于Therac-25错误地超过剂量，导致患者死亡或严重辐射灼伤[2]。

上面摘自维基百科, 从商业角度衡量糟糕的软件会导致经济的损失, 软件层面的严重问题甚至会导致数千万美元的损失。从生命的角度而言, 软件的问题会直接导致人类生命的丧失。离我们很近的例子数不胜数例如近年来的大型空中客机, 当下市场占有率正在逐年提高的电动汽车。即使有如此严重的后果但是如今的人类已经不可能摆脱软件而生活, 软件已经变成社会运转, 人们生活中不可或缺的一部分，这就是现实。

当我们谈及到软件工程时应当是严肃的

当我们谈及 工程 二字时应当是严肃的, 工程 意味着有目标有预期有很强的目的性 , 是对资源的调动, 而资源永远都是有天然的稀缺性。如果 工程 最终以失败告终，意味着对资源的浪费。这里的资源包含人力，物力，时间， 甚至是商业机遇。当决策者面对数百上千万甚至上亿的资金投入时应该保持严肃，认真，尊重科学和客观事实的态度。

软件工程包括

• 创立与使用健全的工程原则，以便经济地获得可靠且高效率的软件。
• 应用系统化，遵从原则，可被计量的方法来发展、操作及维护软件；也就是把工程应用到软件上。
• 与开发、管理及更新软件产品有关的理论、方法及工具。
• 一种知识或学科，目标是生产质量良好、准时交货、符合预算，并满足用户所需的软件。
• 实际应用科学知识在设计、建构计算机程序，与相伴而来所产生的文件，以及后续的操作和维护上。
• 使用与系统化生产和维护软件产品有关之技术与管理的知识，使软件开发与修改可在有限的时间与费用下进行。
• 建造由工程师团队所开发之大型软件系统有关的知识学科。
• 对软件分析、设计、实施及维护的一种系统化方法。
• 系统化地应用工具和技术于开发以计算机为主的应用。
• 软件工程是关于设计和开发优质软件。

软件工程的核心知识（SWEBOK）

ACM与IEEE Computer Society联合修定的SWEBOK（Software Engineering Body of Knowledge）提到，软件工程领域中的核心知识包括：

• 软件需求（Software requirements）
• 软件设计（Software design）
• 软件建构（Software construction）
• 软件测试（Software test）
• 软件维护与更新（Software maintenance）
• 软件构型管理（Software Configuration Management, SCM）
• 软件工程管理（Software Engineering Management）
• 软件开发过程（Software Development Process）
• 软件工程工具与方法（Software Engineering Tools and methods）
• 软件质量（Software Quality）

糟糕的软件工程带来的痛苦

用户的抱怨

还记得当初的 12306 么？每当到了临近过年的时候, 你进入 12306 的官网无论你刷新了多少次看到的都是白色的屏幕没有任何内容。

在用户抱怨的同时，用户在失去耐心，而我们正在失去用户对产品的信心。在竞争激烈的互联网信息行业中，没有垄断地位的企业承受不起这种打击，同类形的竞品太多了，用户觉得你的产品不好用，用不了1分钟他就会找到替代品。所以基于充分竞争的市场环境公司必须不断地提高产品的品质以满足挑剔的客户。

资金的损失

一个糟糕的软件工程最终会在不断变化的市场环境和需求下变得难以为继，维护成本大量增加，公司需要不断的招聘工程师来实现既定目标，但最终却得不到想要的效果。Why ？为什么事情会变得如此困难。糟糕的软件工程有一个共同的特点，僵化不具备弹性，面对变化的市场和需求软件无法及时的做出响应，工程师为了实现目标只能进行修修补补，这样最终只会导致软件工程变得更加糟糕，陷入了恶性循环。

开发团队疲于奔命

工程师的最基本职责就是保证实现需求，交付成品。当产品经理输出了新的需求后，工程师们的第一目标是交付功能。没有人再有多余的精力去关注糟糕的软件工程，即使他们充满了抱怨的同时举步维艰。他们会想出各种的临时解决方案，实现当下的需求，而随着这些"临时解决方案"数量的增加，整个工程变得更加糟糕，陷入恶性循环。

决策层对开发团队失去信任

随着软件工程质量的恶化，新需求的交付变得越发困难，决策层开始质疑开发团队对开发团队失去信心。

导致软件工程变得糟糕的原因

• 混乱的需求, 自身逻辑都无法自洽
• 混论的设计甚至是没有设计
• 混乱的团队管理
• 糟糕的软件架构
• 不称职的工程师
• 质量低下的代码
• 未经过充分测试的发布
• 太多的从未被优化的临时解决方案

当然上述几点并不是导致软件工程变得糟糕的全部原因但至少是主要的普遍原因，一个好的软件设计需要在变化中发现不变的部分，将变化的部分与不变的部分划清边界，隔离变化，并使得变化符合开闭原则（既对扩展开发对修改关闭）。这是软件设计的核心原则，无论用什么框架也好技术也好，最根本的是不能脱离核心原则。

DevX 不止于技术