您当然希望您的代码尽可能由最熟练的开发人员编写，但这还不够。即使是最有能力的开发人员也会犯错误（虽然能力较差的开发人员显然倾向于犯更多的错误）。

为了获得相对没有错误的代码和算法，您希望从尽可能干净的代码开始，但这只是过程的一半。消除故障的最佳方法是让尽可能多的熟练开发人员梳理代码以寻找它们。这对代码和算法一样适用。您的解决方案需要由最有经验的人广泛审查。

你从哪里开始——原始开发人员的技能水平——只是起点。经过充分的审查，原始开发人员的技术水平并不重要。

所以关键是：任何代码中的安全价值都在于它的审查程度。无论它是由您、著名密码学家、大公司还是任何人编写的，重要的是有多少熟练的眼睛仔细检查了代码。

这样的规则倾向于支持已建立的框架而不是简单的解决方案。但是已建立不一定与 已审查相同，这也是许多安全专家倾向于支持开源解决方案的部分原因：一个开源项目如果不经过一定程度的审查就很难流行起来。

对于自制框架，一个称职的程序员是不够的。你需要一个称职的程序员，他有时间致力于实现和后续维护，并且十年后仍然会这样做。这是可以做到的，但在学生来来往往的大学环境中却并非如此。

如果您坚持已建立的框架，那么您将从框架维护团队的安全更新和一般工作中受益，这将使您的任务更轻松。

要记住的一点是，自制框架本身并不能提供安全性。它只是给人一种安全感。推理通常是这样的：“由于我们有一个自制框架，我们不会受到已知框架的已知错误和弱点的影响，攻击者永远不会猜测我们自己的错误在哪里”。这个推理是有缺陷的：攻击者已经知道你的代码，可能比你更好。尤其是在一所大学里，根据定义，这里有很多精通技术的人，他们有冒险精神、灵活的道德，而且通常有更多的空闲时间和可用的计算能力，而不是被认为是健康的。

所以你应该使用一个既定的框架。

你有两个顾虑：

1. 删除您的数据的“偷渡式黑客”通过同时利用数千个网站来阻止您的网络服务器运行。
2. “瞄准黑客”想要访问您的网络服务器，专门为了“更高的收益”，无论可能是什么。

只要您有可靠的备份、更新和恢复计划，首先就不是问题。除非你每隔一天就被黑客入侵，否则它将超过编写框架的成本。

即使您不使用框架，第二个也无关紧要。因为如果激励足够高，任何事情都会发生，包括社交黑客、从黑市购买零日漏洞等。你需要做的是降低激励。从 Web 服务器中分离出有价值的数据，您的框架的弱点不再重要。

自制框架的最大问题是：代码库中的专家太少。

编写自己的框架很有趣（好吧，它是为喜欢这种事情的那种编码人员准备的），但除非代码的所有权被广泛共享，否则这是一条危险的道路。

我曾在他们编写自己的框架库的几个地方工作过。通常，框架本身几乎完全由一两个开发人员编写。老板们坚信框架代码是一项宝贵的资产，而对代码了如指掌的主要开发人员几乎是不可替代的。

问题是，在我见过的每一种情况下，代码都充满了错误、安全漏洞和糟糕的实践。当首席开发人员最终离开时，他的继任者只能收拾残局。有时他们只是与现有代码战斗；有时他们会进行大规模的重新设计项目；有时他们会切换到第三方框架。

通常发生的另一个问题是技术和用户需求不断变化。如果您已经编写了自己的框架，则需要不断地对其进行改进以使其保持最新状态。如果框架是您的主要项目，这很好，但如果它只是您的后端代码，它会占用您的时间，而这些时间最好花在您的实际项目上。

最后，安全。这个是大的，真的。很多很多有能力的开发人员都编写了不安全的代码。事实上，如果我们是诚实的，我们都有。Java 不是由不称职的人编写的，但 Oracle 本周不得不针对 50 个安全漏洞发布补丁。你能说出的所有其他软件也有漏洞，而且可能仍然有漏洞。通过编写自己的框架，您绝对不会编写比任何知名第三方框架更安全的东西。事实上，它可能会变得更糟，而且您将没有资源去寻找安全漏洞。您将拥有“默默无闻的安全性”，因为没有人会看到您的代码，但您只需在谷歌上搜索该短语即可了解安全世界对此的看法。

所以总而言之，我会说不；自制框架不是一个好主意。

继续写一个——这是一个很好的学习练习——但不要指望它和已经存在的框架一样好。如果这么简单，就不需要现有的库了。