程序员有“代码跑起来，就不要动”的观点，主要是因为稳定性、风险管理、时间成本、以及已知状态维持等因素。在软件工程的实践中，一旦代码经过测试并在生产环境中运行稳定，就不建议进行不必要的修改。修改代码可能导致新的问题，这会影响系统的稳定性并增加项目的风险。尤其是在没有完备测试或者是测试较为昂贵的场合，任何改动都需要投入大量的时间去验证，因此，如果当前代码能满足需求且无严重的性能或安全缺陷，通常建议不要动。
改变稳定的代码意味着接受代码可能出现新bug的风险。即便是看似简单的修改，也可能会引起预料之外的连锁反应。在无法完全掌控变更的后果时，保持现状往往是最安全的选择。
一、稳定性和复杂性
在软件开发领域中，稳定性是衡量软件质量的关键指标之一。程序员倾向于维持已验证的代码不变主要是基于稳定性考量。由于软件系统往往相当复杂，每个组件之间可能存在着复杂的相互依赖关系，即使是很小的变更也可能在系统中引起不可预測的效应。
在讨论稳定性时，我们必须意识到系统的复杂性。复杂系统中的每一次变更都需要经过严格的测试来确保系统行为的预期性。如果系统已经运行稳定，意味着当前的代码库已通过了各项测试，满足了业务需求。对于已部署到生产环境中且服务于最终用户的软件，稳定性尤为重要。此时，即使是看似微不足道的改动，也需要考虑到重新进行全面的测试，以及监控可能出现的回归问题。
二、风险管理
程序员不愿意修改运行良好的代码还源于对风险的管理。每当代码被修改，新的风险便产生了，不论是安全风险、性能风险还是功能风险。程序员必须评估这些风险，并决定是否值得为了某些潜在的改进而去冒这些风险。风险越高的修改越被谨慎对待。
在风险管理方面，了解变更对现有系统可能造成的影响是至关重要的。而当风险难以量化或预测时，避免变更成为了合理的选择。在很多情况下，风险不仅仅源自于代码本身的修改，还可能来自于环境的变化，比如操作系统的更新、硬件的变更或是其他服务的升级。所有这些因素都需要在考虑是否进行代码修改时纳入考量。
三、时间成本与资源分配
另外一个原因是时间成本和资源分配。对于运行良好的代码进行修改意味着需要投入新的开发和测试资源，这可能会分散团队的注意力，延迟新功能的开发或者修复更为紧迫的问题。
时间成本不仅仅体现在开发新功能时，更多的是体现在解决由修改引发的潜在问题时。通常一个小的修改需要的测试远远超出了代码修改本身所需的时间。团队需要在项目的时间资源分配上做出权衡，经常会出现的情况是为了保证项目进度和资源的有效使用，选择保持稳定而非进行改动。
四、已知状态的维持
维持现有代码的一个主要优势是维持了一个已知且可控的状态。这个状态是基于目前代码在实际运营中的性能和表现所了解到的，而任何对代码的修改，都可能破坏这种已知的稳定状态。
在维持已知状态时，程序员会依赖于他们对当前系统的理解和预期。这种理解基于系统的日常运作和过往的维护经验。如果代码已经证明是可靠的，修改可能会导致之前的预期不再有效，造成不必要的麻烦和工作量。
五、持续性和可维护性
然而，值得注意的是，在长期来看，总有一些情况需要对代码进行调整，如技术债务的累积、新需求的实现或者外部环境的改变。此时，程序员面临的挑战是如何平衡代码的持续性和可维护性，保持系统的现代性和竞争力，同时又不破坏其稳定性。
维护性是代码质量的另一个重要方面。一个干净、结构良好的代码库比一个乱糟糟的代码库更容易维护和修改。如果代码库已经存在设计上的缺陷，即使它目前运行稳定，长期也可能面临技术债务的问题。在这样的情况下，即使存在“不要动运行稳定代码”的观点，也同样需要处理和改进代码，以保持软件的健康状态。
六、总结
最终，程序员之所以坚持“代码跑起来，就不要动”的观点，归根结底是出于对产品稳定性的尊重、对潜在风险的规避、对时间成本与资源分配的考量，以及为了保持软件的已知状态。但这并不意味着软件不会随着时间进行必要的演化和改进，而是一种软件维护中常见的实践，鼓励在当前实现可接受的前提下，谨慎地对待每一次可能引入新问题的改动。
相关问答FAQs：
为什么程序员要让代码在运行过程中保持静止？
代码在运行过程中的稳定性对于程序员来说非常重要。当代码在运行时，任何不必要的干扰可能导致程序出错或崩溃。因此，程序员倾向于避免在代码运行期间进行任何不必要的操作或干扰。
代码稳定性与程序可靠性有什么关系？
当代码稳定不被干扰时，程序的可靠性得到了提高。如果程序员不对代码运行期间进行不必要的操作，可以减少出错的机会，提高程序的稳定性。这种稳定性可以确保程序在运行过程中始终能够按照预期的方式进行，从而提高程序的可靠性。
有没有例外情况，代码在运行期间需要进行干涉？
尽管程序员通常倾向于让代码在运行期间保持静止，但也有一些特殊情况下需要干涉的情况。例如，当程序发生错误时，程序员可能需要暂停代码的执行，以便进行故障排除和修复。此外，在一些特定的调试情况下，程序员可能需要在代码运行期间进行下一步的单步调试，以便更好地了解问题的来源。然而，这些情况属于特例，一般情况下，程序员会努力避免任何不必要的代码干涉。
