多年来我一直是PHP开发人员,拥有许多工具; 我自己开发的工具,或者我学会信任的免费解决方案.
我最近调查了CodeIgniter,并发现他们有许多类和帮助程序来帮助开发,但在示例中没有看到任何我用自己的工具轻易做到的事情.简单的事情,如数据库抽象,电子邮件助手等.有一些有趣的代码与路线相关 - 将网址映射到正确的控制器; 但即使你编写一个带有漂亮网址的MVC风格的网络应用程序也不是特别困难.
甚至可以通过其他一些流行的框架看后,我还是什么也看不到,这将是该多节省时间的.即使看着论坛,我也看到人们正在努力让工具为他们工作.我确实理解他们如何对初级开发人员更有用,因为完整的系统设计技能需要一段时间才能完全理解和欣赏.
然而,我经常被告知我应该使用现成的框架来制作我的解决方案,但我仍然不相信.像我这样的人真正受益的是什么？我只是精英主义者,还是这是一个普遍的观点？
编辑:在这里看一些答案,我是否应该考虑将我的工具集打包为自己的框架,编写一些文档并发布教程？如果我对采取其他框架犹豫不决,是否会打开它并更多地关注它有助于提高我自己的技能/工具？
God*_*eke 34
框架有几个优点:
你不必写一切.在您的情况下,这不是一个帮助,因为您拥有自己多年来积累的框架.
框架提供标准化和经过测试的处理方式.给定框架的用户越多,遇到和编码的边缘情况就越多.您自己的代码可能会或可能不会以同样的方式进行战斗.
其他人可以被招募到具有标准框架的项目中,并且可以访问该框架的文档,示例和经验.您自己的代码段可能会或可能没有完整记录或有使用示例......但其他人最初对它们感到满意的可能性并不大.
编辑:
关于打包自己框架的想法,清理公共消费的好处可能大于让其他人使用它的好处.
原因很简单:您必须重新评估您对每个组件的假设,它们如何组合在一起以及每个组件的清晰程度.一旦发布了框架,您的成功将在很大程度上取决于启动和运行的容易程度.
通过很少努力获得巨大成功对于采用而言至关重要(这些胜利将鼓励人们进一步深入研究框架).Ruby on Rails在一个框架的例子中,只需很少的努力即可获得如此巨大的成功,然后隐藏了一些功能,这些功能可能会让人不知所措.(关于RoR应用程序质量的问题不是重点,重点是采用速度).
在人们采用框架之后,它是关于继续使用的便利性.像一致的参数使用模式这样的细节在这里完全不同.如果一个类在每个方法上都有许多参数,而另一个类在调用方法之前有预期被调用的setter,那么你将失去用户,因为他们无法对某个特定情况下的预期产生"感觉"而不诉诸于文档.
如果适当地解决了易于采用和易于解决的问题,那么您只需要很幸运,人们就可以采用您的框架.如果这些问题得不到妥善解决,即使对框架的初步兴趣也会迅速减弱.原因在于有许多框架:您需要脱颖而出才能获得让其他人使用您的工具包的优势(因为他们理所当然地对您的框架保持警惕).
Chr*_*ber 12
这是不创建自己的框架的另一个原因. Linus的定律 - "只要有足够的眼球,所有的错误都很浅".换句话说,使用给定框架的人越多,它就越可行,并且没有bug.
您是否看过Java有多少个Web框架？在当天,任何半开发的开发人员/架构师都可以编写自己的自定义Web框架.在一天结束时,95%的人看起来像是Struts的自定义实现(当时最流行的Java Web框架).所以他们基本上创建了一个Struts克隆:1)专有; 2)没有记录和测试.
让我们面对现实 - 编写我们自己的客户框架很有趣,但接下来会发生什么？自己跟上框架(或替代你的可怜的灵魂)成为一种维护负担.维护软件的成本要高得多,尤其是在定制框架方面.公司是否在业务中解决域名问题或维护框架的业务？
我忘了是谁说的,但我曾经听过一句好话:"创建自己的框架的第一条规则是:不要".其他人可能已经完成了这样做的努力,并且可能做了你本应做的同样的工作.节省时间,精力和测试.
Cru*_*han 10
关于使用框架的优点,这里有很多评论,当然我认为在很多情况下它们都是完全正确的.
然而
所有框架都有缺点,他们有一个可以适应它们的问题领域.如果您的问题完全在域的范围内,那么使用框架不是问题,并且大多数情况下,如果您的问题远远超出域,那么您很明显,所以您不会考虑它.当你试图将问题强制进入一个它不太适合的框架或者有一些不寻常的非标准功能时会出现问题 - 在这种情况下,你可以非常快速地完成90%的代码,然后花费你所有的时间保存了解如何弯曲或扩展框架,以便它可以完成一些模糊的要求.因为在这些情况下,您的解决方案/扩展必须插入到框架中,所以编码通常比您独立完成时更难编码.
在错误的情况下,这实际上可能是灾难性的.例如,如果客户要求您认为适合框架解决方案的项目并且相应地引用,那么在完成90%之后您会发现问题然后您可能真的在小河上,特别是如果它是客户端的某些功能坚持(而且一直都是).这些问题往往会出现,因为从go中可能出现的问题来看,并不总是很明显,特别是如果你使用的是一个你不太熟悉的框架(并且你不得不时).
这与在项目中部署任何第三方软件时出现的问题完全相同.根据我的经验,我对使用框架或类似物没有任何疑虑,但考虑到选择,我将始终选择最轻,最薄的包装,我能找到能满足我需要的东西.这样我获得了优势,同时知道如果确实出现问题(并且它们通常不太可能使用更薄的包装器),那么找出解决方法的方法可能比学习广泛的代码库更简单.在哪里我可以安全地修改它.