对于一个寿命很长的PHP应用程序项目，自定义(自制)框架是否比(开源)流行框架更好？

Question

对于一个将由开发人员长期使用/维护的项目(比如: 20-50年)，自定义(自制)框架是否比(开放源码)受欢迎的框架更好？基本上，我的最高优先要求是安全性和非常长的寿命。

我目前的情况是必须维护用PHP5编写的15年前的web应用程序(当时，它是自PHP5于2004年7月发布以来最先进的应用程序。该应用程序使用自定义的、封闭的源代码框架(因为我当时设想还没有流行或成熟的框架)。

应用程序已经为组织服务了很长时间，而且它对业务非常重要。我正在尝试制作一个新的移动友好版本(与旧版本一起运行)。我应该使用相同的框架，还是应该使用较新的框架，如symfony或laravel？

当我阅读旧框架的源代码时，我意识到有很多缺点：

• 其中很多都没有遵循OWASP的一些最佳实践(我不能说是哪一个)；
• 没有自动测试，没有文档(每次我们需要改变某些东西时，我们都在逆向工程，希望事情没有中断)；
• 基本上是一笔巨大的技术债务

即便如此，继续使用我们的旧的、自定义的、封闭的源代码框架的考虑是：

• 更安全的
  • 安全通过默默无闻(只有我们知道源代码，不像开源框架，他们的代码基本上是‘泄露’通过互联网)，
  • 安全通过非常严格的网络防火墙规则，
  • 和通过强制执行的法律和组织法提供的安全)；

• 团队(我们)更容易理解；
• PHP5仍将在服务器上运行；
• 但它仍然是非常-非常短的应用寿命(我们的团队预计20-50年)；
• 它每天都收到大量的请求，没有框架(更少的占用空间/资源使用)；即使我试图改变到新的框架，并遵循所有的最佳实践，在20-50年之后，这将是一次糟糕的实践。
• 我们的需求并不在意应用程序是否过时(在html/css演示文稿中)；这不是我们的客户找到我们的地方。

我的问题是：

• 我是否应该建议改变架构和设计？
• 我的观点是否有错或被误导了？

相关问题(但非常不同)：https://stackoverflow.com/questions/1836351/thoughts-on-abandoning-proprietary-framework-for-a-larger-open-source-project (我的问题更多是关于安全性和长生命周期的)

Answer 1

这里有很多东西要打开。我们先从..。

1.通过默默无闻

实现安全

默默无闻本身并不能提供额外的安全性，除非它是完全完整和全面的，以至于它几乎无法平衡可用。

你的公司记录是保密的吗？

你确定攻击者找不到曾经为你的团队工作的人吗？

您确定以前或现在的员工都没有家庭机器上的源代码副本吗？

你确定他们保守秘密，不愿意泄露社会工程的企图吗？

您的服务器是否运行没有漏洞的操作系统？

您确定攻击者不能直接直接访问服务器吗？

您的团队真的那么好吗?框架中的所有接触点(这些接触点是公开的，因此一点也不模糊)都是安全的吗？

如果你不能对其中的每一个问题(和许多其他问题)回答强烈的“是”，那么默默无闻就不会有多大帮助。

把我们带到..。

2.更开放意味着更安全的

这只是一个简单的数字游戏。在全世界的开发人员中，有一定比例的安全专家。如果有更多的人能够访问您的代码--更多的专业人员将检查它并发现问题。

在过去的几百年里，这是几乎每一个协作项目的工作解决方案。这就是维基百科的运作方式。这也是大多数现代框架的运作方式。它们是开源的，部分原因是出于安全考虑。它使他们能够证明他们没有隐藏任何东西，而世界各地的安全专业人员则有机会为建立这些框架贡献他们的经验和技能。

在开源框架中实现的专用安全解决方案将在安全性方面击败您。也就是说，除非您绝对确信您的团队能够在定制的封闭源代码项目中实现世界级的安全性。这让我想到..。

3.代码

的寿命

你必须记住，你的框架不是漂浮在空隙中的。您的代码与许多其他系统进行交互。

你说你使用PHP5。现在它已坚定地处于“生命的终结”阶段，永远不会再更新。你是否习惯于使用一个系统，这个系统有很多众所周知的漏洞和被广泛宣传的漏洞？无论您的代码有多好，以及您对系统的模糊程度有多大，这些代码都不会运行。

当您说PHP5仍将在服务器上运行时，是否意味着它只是不确定地工作呢？随着时间的推移，主要的won服务器将放弃对它的支持，因为没有理由拖拽所有这些旧的、易受攻击的、几乎没有使用的代码。

因此，除非您在未来50年内将整个体系结构保持不变，否则您的应用程序将在某一时刻停止工作。如果你这么做了，那么就会有更多的漏洞需要担心。

4.没有什么是永恒的，

这里列出了30年前不存在的内容: https、http、JavaScript、PHP。

很难预测5到10年后网络会是什么样子，更不用说50年了。需求将发生变化。你的应用程序将不得不适应。如果您的团队能够成功地编写一个将持续这么长时间的web应用程序，使用一个基于已经濒临死亡的技术的封闭源代码框架--向您致敬。

Answer 2

一般来说，是，最好为这样一个长期的项目建立自己的有针对性的、有目的的框架。我这样说是因为他管理了几个20+年的PHP应用程序。20年来，你不会想被像PHP这样的东西困住。框架是方便的，但您必须深入了解它们，了解您对它们的未来可行性有很大的信任。如果他们对框架做了太大的改变，你的升级需要太多的重新布线努力，这可能会让你陷入一个旧的、不安全的版本中。

更重要的是，在没有必要做出这样的选择的情况下，你似乎提出了一种完全或完全没有的替代方案。您的应用程序不是用PHP 5编写的，而是用PHP编写的。PHP仍然存在，而且最新版本可以运行针对PHP 5的代码，通常很少或根本不做任何更改。因此，您更好的方法可能是调整代码，以便在PHP 7的最新维护版本中运行良好。