软件工程师在又一次充满压力的发布后会遇到什么？好吧，我们在小组中遇到的第一件事就是我们公开发布的错误。作为软件工程师，我们在紧张的发布后遇到的最大问题是意大利面条代码，也称为大泥球。
追求完美的时间和金钱很少，也不应该。为了生存，我们必须尽一切努力让我们的软件正常工作并按时推出。事实上，如果一个团队完成了一个有空闲时间的项目，今天的经理们可能会将其视为下次提供更少时间和金钱或更少人员的标志。
您需要在预算范围内按时交付优质软件
成本：架构是一项长期投资。支付账单的人很容易拒绝它，除非有一些切实的直接利益，例如税收减免，或者除非有多余的金钱和时间可用。这种情况很少见。更常见的是，客户需要一些明天可以工作的东西。通常，控制和管理开发过程的人根本不认为架构是一个紧迫的问题。如果程序员知道做工是无形的，而管理者无论如何也不想为此买单，那么一个恶性循环就产生了。
但如果真的是这样，那么每个长期的软件项目最终都会导致一大堆泥巴。
我们知道这并不总是会发生。怎么会？因为关于管理者不将架构视为紧迫问题的说法是错误的。至少现在。IT 领域的管理人员非常清楚可维护性是业务的关键。
业务变得依赖于驱动它的数据。企业已经严重依赖其软件和计算基础设施。有许多关键任务系统必须每周 7 天/每天 24 小时不间断运行。如果这些系统出现故障，则无法检查库存、无法支付员工工资、无法安排飞机航线等等。[..]
因此，寻求使系统远离大泥球的方法是企业的核心。该系统仍然是可维护的。该系统确实有效，并且您作为程序员可以证明它确实有效。您的经理是否问您今天是否完成了编码，她是否问您是否可以在今天完成具有修复 A、B 和 C 的版本，或者她是否问将要发布的软件是否真的可以工作？你证明它有效吗？什么？
现在我的问题：
我们必须通过哪些方式来证明我们的经理和/或利益相关者我们的软件有效？我们的软件单元测试的那些绿灯是否足够好？如果是，那岂不是只能证明我们的大泥球仍在做我们期望它做的事情吗？该软件是可维护的？你如何证明你的设计是正确的？
[稍后添加]
Chris Pebble 他在下面的回答是让我的团队走上正轨。质量保证绝对是我们正在寻找的东西。谢谢克里斯。与利益相关者达成一致的 QA 政策并不是我的团队正在寻找的合乎逻辑的结果。
后续问题是 QA 政策中应该包含哪些内容？
- 让我的利益相关者可以看到该 buildserver 的运行
- 让 buildserver 不仅“只是构建”，而且添加作为 QA 策略一部分的测试
- 我的利益相关者就我们的开发过程达成协议（开发人员相互审查代码是其中的一部分）
- 更多的..
更多信息：我领导的团队正在构建由其他软件团队使用的 Web 服务。这就是为什么一个破坏性的网络服务会立即花费金钱。当演示层团队的开发人员或实际测试人员无法继续前进时，我们会立即面临压力，必须尽快修复错误，这反过来又会导致快速破解。
[稍后添加]
感谢所有的答案。这确实是关于“信任”。如果利益相关者不信任该软件，我们将无法发布该软件，利益相关者正在使用使用我们 Web 服务的网站自己积极测试我们的软件。当出现问题时，我们测试人员的第一个问题是：是服务层问题还是表现层问题？这指示我制定 QA 政策，以确保我们的软件适合他们正在进行的测试。
因此，我（现在）可以设想与测试人员建立信任的唯一方法是： - 与当前的测试团队交谈，检查他们能够手动执行的测试（从他们的测试脚本和场景中）并确保我们的团队已经将这些测试作为单元测试与我们的网络服务进行了检查。在我们发布演示层团队必须集成的版本之前，这将是一个很好的“签收”起点。需要一些努力来澄清为所有这些场景创建自动测试需要一些时间。但是，确保我们构建的东西确实有效，这绝对是有用的。