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

Question

我多年来一直是PHP开发人员，拥有许多工具;我自己开发的工具，或者我学会信任的免费解决方案。

我最近调查了CodeIgniter，并发现他们有许多类和帮助程序来帮助开发，但在示例中没有看到任何我用自己的工具轻易做到的事情。简单的事情，如数据库抽象，电子邮件助手等。有一些有趣的代码与路线相关 - 将网址映射到正确的控制器;但是如果你曾经用漂亮的网址编写过一个MVC风格的网络应用程序，那么编写自己并不是特别困难。

即使在浏览了一些其他流行的框架之后，我仍然没有看到任何 大部分节省时间。即使看着论坛，我也看到人们正在努力让工具为他们工作。我确实理解他们如何对初级开发人员更有用，因为完整的系统设计技能需要一段时间才能完全理解和欣赏。

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

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

Answer 1

框架有几个优点：

• 你不必写一切。在您的情况下，这不是一个帮助，因为您拥有自己多年来积累的框架。

• 框架提供标准化和经过测试的服务方式。给定框架的用户越多，遇到和编码的边缘情况就越多。你自己的代码可能会或可能不会以同样的方式加强战斗力。

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

编辑：

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

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

通过很少努力获得巨大成功对于采用至关重要（这些胜利将鼓励人们进一步深入研究框架）。 Ruby on Rails在一个框架的例子中，只需很少的努力即可获得如此巨大的成功，然后隐藏了一些功能，这些功能可能会让人不知所措。 （关于RoR应用程序质量的问题不是重点，关键是关于采用速度）。

人们采用框架之后，就是继续使用的便利性。像一致的参数使用模式这样的细节在这里完全不同。如果一个类在每个方法上都有许多参数，而另一个类在调用方法之前有预期被调用的setter，那么你将失去用户，因为他们无法对某个特定情况下的预期产生“感觉”而不诉诸于文档。

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

Answer 2

这是不创建自己的框架的另一个原因。 Linus' Law - “如果有足够的眼球，所有的虫子都很浅”。换句话说，使用给定框架的人越多，它就越可行，并且没有错误。

您是否看过Java有多少个Web框架？在当天，任何半开发的开发人员/架构师都可以编写自己的自定义Web框架。在一天结束时，95％的人看起来像是Struts的自定义实现（当时最流行的Java Web框架）。所以他们基本上创建了一个Struts克隆：1）专有; 2）没有记录和测试。

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

我忘记是谁说的，但我曾经听过一句好话 - “创建自己的框架的第一条规则是：不要”。其他人可能已经完成了这样做的努力，并且可能做了你本应做的同样的工作。节省时间，精力和测试。

Answer 3

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

无论其

所有框架都有缺点，他们有一个可以适应它们的问题领域。如果您的问题完全在域的范围内，那么使用框架不是问题，并且大多数情况下，如果您的问题远远超出域，那么您很容易明白，所以您不会考虑它。当你试图将问题强制进入一个它不太适合的框架或者有一些不寻常的非标准功能时会出现问题 - 在这种情况下，你可以非常快速地完成90％的代码，然后花费你所有的时间保存了解如何弯曲或扩展框架，以便它可以完成一些模糊的要求。因为在这种情况下，您的解决方案/扩展必须插入到框架中，所以编码通常比您独立完成时更难。

在错误的情况下，这实际上可能是灾难性的。例如，如果客户要求您认为适合框架解决方案的项目并且相应地引用，那么在完成90％之后您会发现问题然后您可能真的在小河上，特别是如果它是客户端的某些功能坚持（而且一直都是）。这些问题往往会产生，因为从go中可能出现的问题并不总是很明显，特别是如果你使用的是一个你不太熟悉的框架（并且你不得不时）。

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

Answer 4

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

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

Answer 5

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

您的例程与普通图书馆的曝光度不同。

Answer 6

你可能有一点......但是我不会低估许多人的力量，例如phpBB是我所关心的 bb解决方案。为什么？因为他们的支持委员会上有很多，数千个帖子，很多人使用它们知识渊博，可以帮助人们解决问题。

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

Answer 7

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

Answer 8

你基本上拥有自己的框架。因此，对您而言，这不是一个节省时间的因素，因为您已经花时间来开发框架。如果您没有这样的构建，那么使用现有框架肯定比使用自己的框架更容易，更快。

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

另外，如果您的框架比其他人更好，您可以考虑向社区开放;）

Answer 9

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

仅此一点可能是一笔可观的投资，不包括可能在其间出现的错误。当它说它完成时，可能值得花时间学习另一个框架，而不是自己做。

你提到过CodeIgniter - 我个人认为这是一个非常漂亮的框架 - 它没有比那更多的准系统。

Answer 10

我可以立即想到三个原因：

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

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

Answer 11

我同意您应该使用自己的自定义框架。您不仅更容易理解，而且还提供最终的工作安全性！

Answer 12

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

除此之外，我认为最重要的是，您使用的任何工具实际上都可以完成工作。如果碰巧其他人熟悉，那就是奖金。

Answer 13

我认为如果你没有看到需要使用框架那么就不要。

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

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

Answer 14

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

有时候，如果可以使用框架，因为你提高了工作效率，但是在一些高级和困难的项目中，它可能会发生，因此框架会挡在你的路上，你必须找到解决方法。

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

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

Answer 15

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

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

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

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

Answer 16

您能否比公共框架更快，更可靠地解决您的代码所带来的问题？

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

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

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

Answer 17

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

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

总而言之，考虑到你已经拥有自己的东西，我真的没有太多理由去使用它......虽然它可能值得发布这个开源，以便其他人能够进行错误检查并推荐改进。

Answer 18

缺点。

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

大部分代码都是通过包含完成的。试图找出问题的方法就像穿上毛衣上的线，然后解开整件衣服以完全理解这件衣服。

大多数框架作品都有很差的文档。

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

根据我的经验，我发现使用框架工作需要3-6个月才能掌握代码库。只有在那段时间之后，你才能发现天气，你正试图将一个方形钉固定在一个圆孔中。鉴于大多数php项目都希望在这段时间过去之前完成，所以雇主会花费更多资金来让任何项目使用大型“框架工作”来实现。

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

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

MOst程序员“破解”框架工作，让它做他们想要的。这使得未来的程序员不断头脑发热。它也使框架工作的“升级”成为不可能。

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

随时给我一个写得好的对象。至少他们你就知道了瞄准范围。