为什么我需要使用流行的框架？

你可能有一点......但是我不会低估许多人的力量，例如，就我而言，phpBB 是要使用的 bb 解决方案。为什么？因为他们的支持板上有成千上万的帖子，而且有很多使用它的人知识渊博，可以帮助人们解决问题。

因此，就您而言，使用流行框架的唯一原因是许多其他使用它、报告针对它的错误、修复它并支持它的人。在您自己的图书馆上获得相同的覆盖率会很棘手。

您将错过的一件事是进入流行框架的所有验证。

你的例程根本没有流行库所拥有的相同曝光率。

框架有几个优点：

• 你不必写所有东西。就你而言，这没有什么帮助，因为你有自己的框架，这是你多年来积累的。

• 框架提供了标准化和经过测试的做事方式。给定框架的用户越多，遇到和编码的边缘情况就越多。您自己的代码可能会也可能不会以同样的方式进行战斗强化。

• 其他人可以被招募到具有标准框架的项目，并可以访问该框架的文档、示例和经验。您自己的片段可能完整记录，也可能不完整记录，或者有使用示例......但其他人最初对他们感到满意的可能性不大。

编辑：

关于你打包自己的框架的想法，清理它供公众消费的好处可能大于让其他人使用它的好处。

原因很简单：你必须重新评估你对每个组件的假设，它们如何组合在一起，以及每个部分的理解有多清晰。一旦你发布了你的框架，你的成功将在很大程度上取决于它的启动和运行的难易程度。

毫不费力地取得巨大胜利对于采用至关重要（这些胜利将鼓励人们进一步深入研究框架）。Ruby on Rails 是一个框架的例子，它不费吹灰之力就取得了如此大的胜利，然后隐藏了功能层，这些功能会让刚入门的人不知所措。（RoR 应用程序的质量问题不是重点，重点是采用速度）。

在人们采用框架之后，它是关于继续使用的易用性。一致的参数使用模式等小细节在这里发挥了重要作用。如果一个类在每个方法上都有许多参数，而另一个类具有在调用方法之前预期要调用的 setter，则您将失去用户，因为他们无法在不求助于文档的情况下“感觉”给定情况下的预期内容。

如果易于采用和易于生活的问题都得到了妥善解决，你只需要幸运地让人们采用你的框架。如果这些问题得不到妥善解决，即使是最初对框架的兴趣也会迅速减弱。原因是有很多框架：你需要脱颖而出，以获得让其他人使用你的工具包的优势（因为他们理所当然地对你的框架和你对其他人一样警惕）。

我认为主要原因是当你使用一个通用的框架时，有很多人会立即熟悉你的产品。

除此之外，我认为最重要的是，无论您使用什么工具，都能真正完成工作。如果它碰巧为其他人所熟悉，那么这是一个奖励。

框架代码可能经过充分测试，并且相对没有错误。通过使用它，您可以节省测试/维护自己的代码来做同样的事情的时间。

节省的任何时间都是好的。懒惰在编程中得到了回报。

我同意你应该使用你自己的自定义框架。它不仅让您更容易理解，而且还提供了终极的工作保障！

我能立即想到的三个原因：

• 一个众所周知的框架对于其他可能必须处理你的项目的开发人员来说是熟悉的
• 一个众所周知的框架将拥有书籍、讨论板和其他可用于查找更多信息的专家等资源
• 管理者通常会有一种“不要重新发明轮子”的理念。事实上，现有的解决方案可能已经解决了与创建自己的解决方案时会发现的相同的问题。

综上所述，您可能仍然有自己的解决方案。如果没有人开始新的东西，我们就不会有那么多框架（或脚本语言）可供选择。

您可能知道：“时间就是金钱”。因此，通过使用一个流行的框架，它有很多助手，网络上有很多代码示例和一个大社区，你可以在更短的时间内做更多的事情。

有时，使用框架是可以的，因为你变得更有效率，但在一些高级和困难的项目中，它可能会发生，以至于框架会阻碍你，你必须找到解决方法。

我认为没有明确的答案。您应该权衡利弊，并为您的项目做出正确的决定。

通常，我会非常快速地采用流行的框架，但不会在项目的关键部分采用，并且会及时扩展它们的使用。

我认为，如果你认为没有必要使用框架，那就不要了。

我之所以使用框架，例如用于 python 的 Django 或用于 Ruby 或 Webforms 的 Rails，以及用于 ASP.net 的 MVC，是因为它们使它们更容易、更快速地编写应用程序。在 Ruby 和 Python 的情况下，不为我使用框架会让我发疯。

如果你有一些有效的东西，并且认为没有必要使用框架，我会说坚持你觉得最好的。但是，我仍然会跟上框架的最新动态。

你本质上拥有的是你自己的框架。因此，它对您来说不是一个节省时间的方法，因为您已经花时间开发框架。如果你没有这个来构建，那么使用现有的框架肯定比推出自己的框架更容易、更快捷。

你需要看的是你的框架是否比其他选项更好，以及你对自己的代码的熟悉程度是否超过了让其他人看它，以及其他人以足够不同的方式使用它，以至于发现和纠正任何问题的可能性要高得多。

此外，如果你的框架比其他人的要好得多，你可以考虑向社区开放你的框架;)

任何有经验的开发人员都可以构建一个框架——具有挑战性的部分是说服其他人它值得使用。您需要为计划使用或维护它的人创建文档和教程。您可能需要创建一个演示站点来证明它有用并且实际上可以正常工作。

仅此一项就可能是一笔可观的投资，不包括中间可能出现的错误。当一切都说完了，花时间学习另一个框架而不是制作自己的框架可能是值得的。

你提到了 CodeIgniter——我个人觉得这是一个漂亮的框架——没有比这更准系统的了。

我认为如果您从头开始并且没有时间编写自己的代码，它们会更有用。如果您已经拥有多年来开发的代码库，那么它们的用处可能要小得多，但看一看它们的作用可能仍然有用。

例如，我敢肯定，大型游戏开发公司没有使用第三方工具、引擎和框架，不是因为它们不够用，而是他们自 80 年代以来就已经构建了自己的工具、引擎和框架。

另外，如果您使用的是现成的组件，则无法在其特定区域超过它。如果你需要成为某个特定维度的市场领导者，你应该在该维度上构建自己的解决方案，这样你才能发挥领导作用。如果您不需要此功能，那么使用与您的组件一样好的第三方组件可能是一个很好的解决方案，只要它可以轻松转换。不过，花时间在新工具上进行培训并接受其特性可能值得也可能不值得。

另一件要考虑的事情是，如果你能构建一些东西，你就真正理解了它。否则，你不会。现在，你不需要完全理解东西来使用它们，只要它们“只是工作”，但我们都知道这是怎么回事...... :)

关于使用框架的好处，这里有很多评论，当然，我认为在很多情况下，它们是完全正确的。

然而

所有框架都有一个缺点，即它们有一个可以适应的问题领域。如果你的问题完全在领域范围内，那么使用框架就不是问题，而且大多数时候，如果你的问题远远超出了领域，那么你就很容易看出来，所以你不要考虑它。当你试图将一个问题强加到一个它不太适合的框架中，或者有一些不寻常的非标准功能时，就会出现问题——在这种情况下，你非常快地完成了 90% 的代码，然后把你节省下来的所有时间都花在弄清楚如何弯曲或扩展框架上，以便它可以完成一些晦涩的需求。因为在这些情况下，你的解决方案/扩展必须插入到框架中，所以编码通常比你独立使用它更困难。

在错误的情况下，这实际上可能是灾难性的。例如，如果一个客户要求一个你认为适合框架解决方案的项目，并且你相应地报价，那么在完成 90% 之后，你找到了问题，那么你就可以真正走上小溪了，特别是如果它是客户坚持的一些功能（而且总是如此）。这些问题往往会出现，因为从go这个词中并不总是很明显，陷阱可能在哪里，特别是如果你使用的是一个你不太熟悉的框架（你必须不时地这样做）。

这实际上与在项目中部署任何第三方软件时出现的问题相同。根据我自己的经验，我对使用框架或类似工具毫不犹豫，但只要有选择，我总会选择我能找到的最轻、最薄的包装器，以满足我的需求。这样一来，我就获得了优势，同时知道如果确实出现了问题（而且使用更薄的包装器通常不太可能出现问题），那么弄清楚如何解决这些问题可能比学习广泛的代码库更简单，以至于我可以安全地修改它。

这是不创建自己的框架的另一个原因。莱纳斯定律 - “只要有足够的眼球，所有的虫子都是浅层的”。换句话说，使用给定框架的人越多，它可能就越可靠和无错误。

你见过 Java 有多少个 Web 框架吗？过去，对于任何半体面的开发人员/架构师来说，编写自己的自定义 Web 框架是很时髦的。归根结底，其中 95% 看起来像是 Struts（当时最流行的 Java Web 框架）的自定义实现。因此，他们基本上创建了一个 Struts 克隆，它是：1） 专有的;2）没有很好的记录和测试。

让我们面对现实吧 - 编写我们自己的客户框架很有趣，但接下来会发生什么？自己（或取代你的可怜的灵魂）跟上框架成为一种维护负担。维护软件的成本要高得多，尤其是在自定义框架方面。公司的业务是解决领域问题，还是维护框架？

我忘了是谁说的，但我曾经听过一句名言——“创建自己的框架的第一条规则是：不要”。其他人可能已经付出了这样做的努力，并且可能做了与你本来会做的相同的工作。节省时间、精力和测试。

我会在这里反其道而行之，并说，你应该使用自己的自定义框架，如果你正在构建的软件是你业务的核心。正如 Joel 所说，“找到依赖关系 - 并消除它们”。如果您只是为您的公司建立一个小网站，而您的企业没有维护网站，那么请继续使用框架。但是，当该网站是您的业务时，您不应该依赖其他人的框架来完成工作。

你能比公共框架更快、更可靠地解决你的代码问题吗？

如果是，请继续使用您自己的。

如果没有，那么找到做得更好的框架，并为该项目运行它。

这一切都归结为哪个代码库可以更好地完成工作（对于客户给出的更好的价值;)。

优点是它已经由多人编写和测试，因此不太可能容易出错。

缺点是它不是专门为您的应用程序构建的，因此性能很可能会变差。

总而言之，考虑到你已经拥有自己的，我真的看不出有太多理由使用一个......尽管可能值得发布该开源，以便其他人能够进行错误检查并提出改进建议。

弊。

大多数框架作品都不是面向对象的。（代码点火器确实显示出一些优点）

大多数代码都是通过包含完成的。试图找到问题就像在毛衣上拉一根线，必须解开整件衣服才能完全理解创作。

大多数框架作品的文档写得很差。

大多数框架作品都试图做很多很多很多事情。

我从使用 frame works 开发的经验中发现，需要 3-6 个月的时间才能掌握代码库。只有在那段时间之后，你才会发现天气，你正试图将一个方形钉子安装到一个圆孔中。鉴于大多数 php 项目都希望在这段时间过去之前完成，因此雇主要让任何使用大型“框架工作”的项目取得成果将花费更多。

许多 php Frame 作品都是为 php 4 编写的，并且是在不同的环境中编写的。它们已经大大扩展，但正在显示它们的起源。全局约束的使用尤为普遍。我希望 php 6 能把他们中的大多数人置于死地。代码点火器逃脱了大部分，但它是新的，并且具有面向对象的部分。

一些框架作品编写了不需要的代码，并导致问题。例如：CAKE 有一个最优秀的模型视图控制器，但它的会话处理是一场灾难。不幸的是，框架作品不是以模块化的方式编写的。通常，这是一个全有或全无的选择。

MOst 程序员“破解”框架工作，让它做他们想做的事。这让未来的程序员们头疼不已。这也使得“升级”框架工作变得不可能。

我还没有看到实现单元测试的框架工作。（你怎么知道你没有打破它）。

随时给我一个写得很好的对象。至少他们你马上就知道范围。