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

【问题标题】：Why do I need to use a popular framework?为什么我需要使用流行的框架？
【发布时间】：2010-09-21 16:42:39
【问题描述】：

我从事 PHP 开发已经很多年了，掌握了很多工具；我自己开发的工具，或者我学会信任的免费使用的解决方案。

我最近查看了 CodeIgniter，发现它们有许多类和辅助例程来帮助开发，但在示例中没有发现我无法使用自己的工具轻松完成的内容。简单的东西，例如 DB 抽象、电子邮件助手等。有一些与路由相关的有趣代码 - 将 url 映射到正确的控制器；但是，如果您曾经编写过带有漂亮 url 的 MVC 风格的 Web 应用程序，那么自己编写代码也不是特别困难。

即使浏览了其他一些流行的框架，我仍然没有发现可以那么节省大量时间的东西。即使查看论坛，我也看到人们在努力获取适合他们的工具。我确实理解它们对初级开发人员的帮助更大，因为完整的系统设计技能需要一段时间才能完全理解和欣赏。

然而，我经常被告知我应该使用现成的框架来生成我的解决方案，但我仍然不相信。对像我这样的人有什么真正的好处？我只是精英主义者，还是这是一种普遍的看法？

编辑：看看这里的一些答案，我是否应该考虑将我的工具集打包为自己的框架，编写一些文档并发布教程？如果我对采用其他框架犹豫不决，是否会打开它并让更多人关注它有助于提高我自己的技能/工具？

【问题讨论】：

如果您决定打包您的框架，请添加一个链接。谷歌代码或 git 项目很容易设置。我很好奇。

标签： php frameworks

【解决方案1】：

框架有几个优点：

您不必编写所有内容。对你来说，这没什么帮助，因为你有自己多年来积累的框架。
框架提供标准化和经过测试的做事方式。给定框架的用户越多，遇到和编码的边缘情况就越多。您自己的代码可能会，也可能不会以同样的方式强化战斗。
其他人可以被招募到具有标准框架的项目中，并可以访问该框架的文档、示例和经验。您自己的 sn-ps 可能有完整的文档，也可能没有完整的文档，或者有使用示例……但其他人最初对它们感到满意的可能性不大。

编辑：

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

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

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

人们采用了一个框架之后，就是继续使用的难易程度。像一致的参数使用模式这样的小细节在这里起到了重要作用。如果一个类在每个方法上都有很多参数，而另一个类有在调用方法之前需要调用的 setter，那么您将失去用户，因为如果不诉诸文件。

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

【讨论】：

【解决方案2】：

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

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

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

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

【讨论】：

【解决方案3】：

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

但是

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

在错误的情况下，这实际上可能是灾难性的。例如，如果客户要求一个您认为适合框架解决方案的项目并且您相应地引用，那么在完成 90% 后您会发现问题，那么您就可以真正上岸了，特别是如果它是客户的某些功能坚持（而且总是如此）。之所以会出现这些问题，是因为从“go”这个词中可能会发现问题所在的位置并不总是很明显，特别是如果您使用的是您不太熟悉的框架（而且您有时不得不这样做）。

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

【讨论】：

为“..我将永远选择我能找到的最轻、最薄的包装纸”
@pimbrouwers 当然这个精神仍然是正确的，但是我写了这十年，这些天我几乎没有在没有框架的情况下使用 PHP。 Laravel 如果项目是中等或更复杂的，但如果我想要简单快速的东西（例如数据库的 API）仍然是 CodeIgniter，我仍然对 Javascript 框架持怀疑态度，但是没有任何框架的日子但是最简单的PHP脚本已经结束了
我百分百支持你。对于 php 中的项目，我更喜欢 slimphp 和 idiorm。出于高性能和安全原因，在基础设施端与 nginx/php-fpm/apache 配对。但这当然是个人口味！在 JavaScript 前端，请查看 Knockout.js。这太不可思议了。它重新唤起了我对 JavaScript 编码的热爱。
@pimbrouwers Knockout.js - 我一定会去看看。

【解决方案4】：

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

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

【讨论】：

【解决方案5】：

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

您的例程与流行的库所拥有的曝光率完全不同。

【讨论】：

【解决方案6】：

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

因此，在您的情况下，使用流行框架的唯一原因是许多其他人使用它，报告错误，修复并支持它。在您自己的库上获得相同的覆盖率会很棘手。

【讨论】：

【解决方案7】：

我会在这里违背规律说，如果您正在构建的软件是您业务的核心，那么您应该使用自己的自定义框架。正如乔尔所说，“Find the dependencies - and eliminate them”。如果您只是为您的公司建立一个小网站，而您的企业没有维护网站，那么请继续使用框架。但是，当该网站是您的业务时，您不应该依赖其他人的框架来完成工作。

【讨论】：

【解决方案8】：

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

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

【讨论】：

【解决方案9】：

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

【讨论】：

【解决方案10】：

我马上能想到的三个原因：

其他可能需要处理您的项目的开发人员会熟悉一个众所周知的框架
知名框架将包含书籍、讨论板和其他专家等资源，可用于查找更多信息
经理们通常会有“不要重新发明轮子”的理念。事实上，现有解决方案可能解决了您创建自己的解决方案时会发现的相同问题。

综上所述，您自己的解决方案可能仍有一席之地。如果没有人开始新事物，我们就没有那么多框架（或脚本语言）可供选择。

【讨论】：

【解决方案11】：

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

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

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

【讨论】：

【解决方案12】：

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

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

另外，如果你的框架比其他人的框架好得多，你可以考虑向社区开放你的框架；）

【讨论】：

【解决方案13】：

您可能知道：“时间就是金钱”。因此，通过使用具有大量帮助程序的流行框架、网络上的大量代码示例和大型社区，您可以在更短的时间内完成更多工作。

有时如果可以使用框架，因为您变得更有效率，但在一些高级和困难的项目中，可能会发生这样的情况，因此框架会妨碍您，您必须找到解决方法。

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

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

【讨论】：

【解决方案14】：

我认为，如果您认为不需要使用框架，那就不要。

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

如果您有一些可行的东西并且认为不需要使用框架，我会说坚持您认为最好的东西。但是，我仍然会跟上框架。

【讨论】：

【解决方案15】：

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

例如，我确信主要的游戏开发商店没有使用第三方工具、引擎和框架，不是因为它们不够用，而是因为它们自 80 年代或其他什么时候就已经构建了自己的工具、引擎和框架。

另外，如果您使用的是现成的组件，则无法在其特定领域超越它。如果您需要成为某个特定维度的市场领导者，您应该在该维度构建自己的解决方案，这样您才能成为领导者。如果您不需要此功能，则使用与您的一样好的第三方组件可能是一个很好的解决方案，只要它是一个简单的过渡。是时候训练新工具并接受它的特性可能值得也可能不值得。

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

【讨论】：

【解决方案16】：

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

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

如果不是，则找到工作更好的框架并为该项目运行。

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

【讨论】：

【解决方案17】：

缺点。

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

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

大多数框架作品的文档都写得不好。

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

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

许多 php Frame 作品都是为 php 4 编写的，并且是在不同的环境中编写的。它们已经大大扩展，但正在显示它们的起源。全局约束的使用尤其普遍。我希望 php 6 让他们中的大多数人死亡。 Code igniter 避开了大部分内容，但它是新的，并且具有面向对象的部分。

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

大多数程序员会“破解”框架工作以使其完成他们想做的事情。这让未来的程序员摸不着头脑。这也使得“升级”框架成为不可能。

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

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

【讨论】：

"[我]需要 3 到 6 个月的时间才能掌握代码库。只有在那段时间之后，你才会发现你试图适应一个正方形的天气钉在一个圆孔里。” +1 +1 +1

【解决方案18】：

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

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

总而言之，考虑到您已经拥有自己的，我真的看不出有什么理由使用它……尽管发布该开源代码可能值得，以便其他人能够检查错误并提出改进建议。

【讨论】：