运行十几年都没出现BUG的软件都是怎么做的？
作为一名开发人员都曾遇到过这样的情况，公司领导突然给了你一个其他人都不愿意接手的工作——运行一个遗留系统。由于它是在很久前开发的，所使用的平台早就过时了。因此维护并运行这个遗留系统特别的困难，甚至会因为你的一个小失误对系统造成严重的破坏。国外的一名开发者就类似情况，分享了一篇应对文章，让我们一起来学习下。实际上在某些情况下，系统破损是无法避免的，但如果你在对它的维护和运行中遵循一些重要的基本规则，可以在一定程度上避免这种风险。
图片来源视觉中国
舍弃那些过于花哨的东西，使用更沉稳的技术
在为平台做技术选型时，可以把目光聚焦到哪些经过时间历练，更加稳定的技术，而不是跟风使用哪些新颖的、吹捧起来的高大上技术。因为这种技术很少改变，即使它改变了，你一样可以依靠原有的可靠性功能继续维护运行。这样可以减少你的系统出错的几率。
不要过于依赖平台 造轮子未必是坏事
一些平台和编程语言在多年的发展中甚至连自身的基本功能都改变了，这确实令它在技术领域向前走出了一大步，但却在这个过程中忽略了向后的兼容性。而那些试图向后兼容的平台也会因为某些原因，或是一个不可预见的问题，最后不得不停止向后兼容。这几乎是软件版本更迭的一个自然趋势，就像是自然界中的生物进化一样。但两者不同的是，自然界的进化我们对此几乎没有办法，但软件版本的进化我们却可以避免，可以通过自制函数来避免对平台上的函数的依赖，以此来消除软件版本更迭带来的影响。
如果这个平台或编程语言为你提供了你所需要的特定功能，并且你的系统在某些非常重要的功能上还非常依赖这个功能，那也不能因此就彻底的依赖它。这个时候我们应该考虑是不是自己制作一个功能来替代它，这样才能消除对平台的依赖。我们也就不用在担心平台更新后，系统中的这个特定功能会停止工作。
当然这不意味着你应该自己编写所有的要用到的函数，但你对平台的依赖越少，你的软件在平台更新时发生故障的可能性也就越小。该个人网站的拥有者就曾多次采用这种策略，他为客户开发的软件最初是在PHP 4.x上开发的，（并不是说PHP 4.x真的出现过问题只是一个例子），现在PHP更新到了 8.0，他的软件依然能完全正常的工作。这种策略的缺点就是在开始时需要花费更多的时间用来开发软件，但从长远来看，它所带来的好处是巨大的。
不要轻易使用框架
框架确实不会为你的系统增加太多的复杂性，但它为你的系统所增加的故障风险却让其成为软件部署的禁区。一般只有”玩具“软件和非常小的应用程序才有理由去使用框架这类的东西。
库不等同于框架，但即使是库也会引起问题。你为一个软件增加的复杂性越大，就越有可能破坏这个软件的发展。我们需要考虑下真正需要多少库，并考虑只从这些库中提取出你需要的部分，或是自己制作提供确切功能的自定义函数。
有一种说法：当你和一个开发团队打交道时，使用一个现如今流行的框架是必须的，因为那样每个人都会知道这个框架并很容易理解这个软件的功能，如果你开发自己的解决方案，就没有人能理解这个软件。但这其实是一个假说法，作为一个软件开发者，最基本的就是能够理解代码，有些代码可能相对来说更难理解，但它只与开发者的个人专业能力有关，与该软件用没用框架没关系。现在的框架大多数都变得非常复杂，它们需要比底层代码更多的时间来理解。
制作高质量软件的还有一个要求就是要有明确的文档，确保你从一开始就把所有的东西都记录下来，并确保你采用一个明确的编码风格。这样一来，即使是初级开发人员也能很好地调查和理解该软件的内容。运行有明确的文档的内部解决方案，可以保证没有任何东西会被突然改变、删除或添加，从避免在下次升级平台时破坏东西。
然而，有些客户就是想不明白。他们总想着要一个短时间内就能完成的解决方案，一个可以快速搭建的解决方案，而完全忽略了软件长期运行会出现的后果。他们总是会对你说：“我明白你的意思，但我们现在就需要这个软件，等我们赚了大笔钱的时候，我们就可以专注于安全、性能和长期支持。”在这种情况下基本没有例外的，他们的软件最后都出现了问题。制造出一个垃圾软件很容易，也很迅速。高质量的软件需要开发者的深思熟虑和长时间的沉淀。
不要担心破坏所谓正确的规则
开发者应当考虑的是怎么建立更稳固，安全的软件。而不是解决盲目建立的软件中的问题。我们是开发人员，不是ctrl c/v的代码搬运工 ，所以我们要浪费时间去建立自己的函数或方法，而不是在这里做一个简单的复制、粘贴。
这一点与如何保持你的软件运行没有太大的关系，但它仍然很重要，因为当你遵循所谓的正确的规则时，你的头脑会变的僵硬，会让你身为开发者的创造性逐渐消失。要学会独立思考，用自己的头脑做正确的事，而不是顺着那种简单却固化的方式去完成你的代码。
页:
[1]