端着咖啡，你大步走向书房，空荡荡的走廊里只剩下你的脚步声。当你跨过门槛时，你停下来点击打开头顶的节能灯。放在办公桌中央的笔记本电脑顿时映入眼帘，明亮的屏幕上图表散发着诱人的光芒。放下你的咖啡，你最终决定再做一次研究，看看是否还有之前遗漏的任何其他错误或误解。熬夜，熬夜，不过***，终于让你得到了客户的认可。喝了一口仍在吐出的咖啡，您决定最后一次检查您的客户需求。早餐在哪里？有。四间浴室，其中一间将在天花板上安装花洒淋浴喷头？有。三辆车的车库和宽敞的院子？有。一切准备就绪。出色的评价会给您信心：客户会很满意，施工可以立即开始。您合上笔记本电脑，拿起它，然后走出门，兴奋地向您的客户展示。如您所料，客户很高兴！他对院子的大小很满意，他和他的家人也喜欢您设计的游泳池和早餐地点。但美中不足的是……“你能让它飞起来吗？”这是工艺，不是工程穿过房子，它们都不会飞。然而，这样的场景在软件开发中往往会反复出现，一遍又一遍。客户要求的东西——他认为是合理的，但对我们开发人员来说可能是完全不可能的——至少到目前为止我们知道这是不可能的。今天的软件开发几乎没有章程，更没有共同商定的标准。通常，我们能做的是创造出尽可能符合客户期望的东西。几年前，关于软件开发是否可以称为软件工程的争论很大，源于TomDeMarco的一篇名为《Software Engineering: An Idea Whose Time Has Come and Gone?》的文章。DeMarco认为，短命的软件工程已经死了，这对于创建所谓的软件“转换”并不重要。DeMarco的论文认为，由于缺乏衡量（以及“软件”一词??的深度和广度），软件工程已经消亡。但我看到的是一种截然不同的现象：软件工程从未存在过。首先，我郑重声明，我同意德马科先生的主要观点。软件开发不是工程，因为在传统工程中，输出是有保证的，可以反复测量和控制。DeMarco的著名论点“你无法控制你无法衡量的东西”最好地总结了这一理念：如果你无法衡量你将要实施的变革的影响，我们怎么能相信你能控制它们？在我看来，这就是我们不能将软件开发称为“工程”的首要原因：我们无法衡量即将实施的变更的影响。当然，我们可以进行单元测试、集成测试——所有我们能想到的测试，但是当我们实施所有潜在的变更时，我们仍然无法准确估计对现有系统的影响范围。我们现在根本没有工具可以做到这一点，据我所知，我们已经很久没有工具了。我认为软件开发可以被认为是一门手艺。“工艺”一词可能更好地描述了我们开发人员的实际工作。工艺和工程学之间的主要区别在于，后者使用已知和公认的知识来解决问题，而前者使用更专业的知识，而前者所知道的人不多，甚至可能是不成文的或不被公众认可的.因此，我们可以得出结论，没有软件工程这样的东西，因为没有足够的普遍接受的知识来证明它是“工程”。那么“软件工程”可以存在吗？有用吗？软件工程这个词可行吗？假设有可能将整个软件开发领域转移到工程学科。然而，我们真的要这样做吗？在我看来，创造有用的软件需要一定的艺术技巧，而且有些创造形式无法用数学和工程学来精确表达。创造力使我们能够针对以前从未见过的问题提出新颖的解决方案。但如果我们不小心，它也可能导致我们搬起石头砸自己的脚。对我来说，将软件开发制定为一门工程学科消除了很多创造性的自由（当然不是全部），阻止了我们以多种方式思考来解决手头的问题。另一方面，利用工程策略可以显着改进标准规范、可测试性和项目管理等概念。此外，它还提供了一个常识库，可用作参考解决方案的来源，使它们更容易交叉引用。既然如此，分享和控制所有知识是否值得我们失去一些创作自由？我认为这不值得，即使上述权衡确实可以实现。软件可以用于所有基本的东西，多元化思维的巨大自由与其说是我们解决问题的障碍，不如说是一种福音。如果软件被迫进入工程化，那么需要考虑的变数太多，问题太多，范围太广。在所有软件开发中使用工程策略将是一场灾难。当我们将软件开发与工程进行比较时，本文开头的故事是一个常见但不正确的假设：将软件设计与建造房屋进行比较。这与事实相去甚远。房子是有形的，受重力等物理定律的约束，我们有几千年的建筑历史，知道如何建造宜居的房子。软件不具备这些条件，所以这样的比较充其量是幼稚的，最坏的情况下是误导性的。总之，软件开发永远不可能是软件工程。我们的职业是一门手艺，我们是工匠。软件开发是我们作为程序员，获取项目的专业信息和设计内容，然后实施满足客户需求的解决方案的过程。它是艺术，充满创意；它不是工程，也不需要是工程。这应该是我们的共识。你怎么认为？您认为作为软件“工程”的软件开发是一个有价值的目标，还是一项不可能完成的任务？欢迎大家发表意见，请畅所欲言！
