54. 长命的临时解决方案

长命的临时解决方案

        为什么我们要创建临时解决方案？

        典型原因是因为我们有一些紧急的问题要解决。可能是开发团队内部的，某些填补工具链中的沟壑的方法；也可能是外部的，终端用户可见的，例如对某个缺失功能的变通方法。
        在大多数的系统和团队中，你都能发现一些在某种程序上与系统不协调的软件，这些是在什么时候就会改变的草稿，不遵守限制其它代码的标准和指导。免不了你会听到开发人员抱怨这些。创建它们的原因五花八门，但关键原因是简单的：有用。
        然而，临时解决方案能够产生惰性（或者动力，看你怎么看了）。因为它们的存在，极其有用、广泛接受，就不需要立即做什么其它的了。每当一位相关人需要决定什么行动最能增加价值，很多都比正确集成一个临时解决方案更高级。为什么？因为它已经在那里了，能工作了，也被接受了。唯一可以感受到的缺点就是它没有遵守选定的标准和指导，除非是为了一些利基市场，否则这就不算什么。
        所以临时解决方案就继续存在了，永久性地。
        如果临时解决方案中出现了问题，不太可能提供一个升级就让以可接受的产品质量重回正轨。怎么办？在该临时解决方案上的一个快速的临时升级经常能够搞定，也非常可能被接受。它展现出了和原来的临时解决方案同样的力量...只是更新式了。
        这会有问题吗？
        回答由你的项目和你对产品编码标准的个人利益决定。如果系统中包含了太多的临时解决方案，它的熵或者内部复杂度就会增加，可维护性就会下降。然而，可能问这个问题本身就是个错误。记住我们是在讨论解决方案，它可能不是你喜欢的解决方案，可能不是任何人喜欢的解决方案，但重做这个解决方案的动力却很小。
        因此，当我们看到一个问题时，应该怎么办呢？
        1. 第一时间避免创建一个临时解决方案。
        2. 改变影响项目经理决定的力量。
        3. 不管它。
        让我们更细地检查一下这些选择：
        1. “避免”在大多数时候都不管用。已经有一个实际问题要解决，而标准又显得太束缚人的手脚了。你可能在尝试改变标准上花更多的努力了，可敬却乏味的努力...而且这个改变不能及时影响手头的问题。
        2. 力量源于项目的文化，那是会抵制改变的。对于很小的项目可能会成功，特别就你一个人的，你可以清除垃圾而不用事先询问。如果项目已乱成一团糟而产生延误了、在某个时间来清理已成共识的情况下也可能成功。
        3. 如果前面的选择不管用，维持现状就自动适用。

        你可能会创建很多解决方案，它们中一些会是临时的，大多数都会很有用。最好地战胜临时解决方案的方法就是让它们成为多余的，提供一种更聪明、更有用的解决方案。希望你有接受不能改变的宁静，有改变你能改变的勇气以及区分二者的智慧。

原文：The Longevity of Interim Solutions by Klaus Marquardt