大家对编程框架怎么看？

如果觉得不爽，就自己写一个。

人云亦云才是最大的效率问题。

你用用不就知道了。

老听别人说话就像那个小马过河的故事一样了。任何一件事站在不同的角度去看都会有优点和缺点，框架也不例外，随着你技术水平的提高，用的框架也不会不一样。
你应该先尝试下，起码学习下别人框架的思想，最终才能得到属于自己的经验和答案。

很多人都是这样的，刚开始觉得框架碍手碍脚/不够灵活/不够有逼格，总觉得会遇到框架搞不定的需求，总觉得自己造轮子才够nb，用框架的是技术工，于是什么都喜欢自己去搞。
折腾了N久过后发现现实需求并不是那么灵活，自己搞个轮子也没多少人关注好像逼格也不是那么高，再一看框架才觉得相见恨晚。
要知道框架的开发者项目经验肯定比你多，流行框架的产生大多数是从现实需求的背景来的。

当然，自己造轮子是最快的学习途径。当然，有的框架的确很渣。

同意楼上，

楼主学 CI、Laravel 吧，前者容易上手，文档简单，后者发展迅猛，国外是主流

最近发现，做小项目的话，wordpress也很好用，API太强大了，二次开发太简单了

@66beta wp是用过一段时间，完全可以当框架来使用。

@akfish 存在即合理。

ThinkPHP、Laravel都用过，ThinkPHP的M方法用的很爽，当然Laravel也有ORM，
还有Laravel的artisan很好用。

我不是一名PHP Developer，但框架是独立于语言的，所以我说一下某个经历，希望对LZ有所帮助：

* 学某编程语言时，也顺便学习了某框架，但是在实际项目中编写代码的过程中，发现套用框架似乎太罗嗦了，为什么10行的代码，非要写成n个类？（貌似也就是LZ遇到的感受）
* 随着这个项目代码量的增加以及人员的变动（新加入和退出）结果发生了：要读懂旧的代码需要花费很长时间，最终会造成了某些Class不到万不得已的情况完全没人敢动的地步。
* 虽然这种情况可以用项目编码规定来约束，但毕竟这属于弱约束。
* 结果我自己仿照某个框架写了一个自用，主要是对开发人员的强约束与项目代码结构的强行规定。

结论：
在大项目中，框架主要针对的人（作用之一），框架具有强约束力以及统一的代码结构，只要使用了同一个框架，对新上手的开发人员来说，学习曲线很低。同样也能抵消一些由于中途离开的“代码真空期”。
即便不用框架，也最好实现写一个具有强约束与强规定的“自用”框架。

但框架的作用也不仅仅如此，比较“现代”的框架大多是帮助你：

* 减少代码量（对，你没看错，的确是减少代码量）。例如：HTML原本不具有数据双向绑定的功能，但Angular.js通过给HTML加上行为的方式（ng-xxx）使HTML具有了这样的方式。如果你需要这种功能，那Angular.js会帮你减少很多工作，让你更专心业务的开发。
* 使用现成的框架会让你的代码结构更加的清晰，如上面的例子。
* 项目的学习成本、学习曲线都因选择不同的框架而出现不同程度的下降。例如：让JS新手直接使用CoffeeScript会绕掉很多JS坑。（虽然CS不是框架，但道理相通）

但任何“规则”都是有它的前提与适用范围，并不是什么情况用框架都有好处：
* 如果是一个小型、周期短并且你又非常熟悉的语言，那么是否使用框架并没有太大的差别。例如，我前几天抽时间写的SimpTab，主要用了requirejs与jquery，只要在代码中分出MVC来就足够了，没必要用高大上的Angular.js。
* 如果是公司的项目，那么尽量还是要用一些框架，好处已经说过了。
* 如果你使用了某种不熟悉的语言，那么选择框架会让你少遇到坑。

我在框架选择上的经历：
不用框架（自诩很牛X，现实很骨感） → 自己写框架（越写越觉得自己的渺小） → 使用现成的框架（只要是高大上就用） → 根据项目特点选用适合的框架（适合就好没必要强求）

写了一大堆，希望可以帮到LZ :)

@kenshin

> 自己写框架（越写越觉得自己的渺小）

你怎么会有这样的感觉？是因为需要解决的问题太多了？

@raincious
我之前举例的项目是用Flex开发，当初我接手的时候，代码并没有使用现成的框架，而后再长达一年多的开发过程中发现了上面所说的问题，后来我开始仿照Cairngorm（Cairngorm是一个单例 + 事件机制 + MVC）做一个自用的框架，但自己写一个框架真不是一个简单的事情，需要考虑很多事情...

或者换个角度说，如果我开发了一个类似Cairngorm的框架，那么我哪里有时间做项目，这样本末倒置了，项目需要框架，但不能因为需要框架而写框架...

如果你写出来的东西肯定没有现成的好用，那为什么不用现成的呢？而例子中为什么没用现成的原因：需要重构，但时间不允许，所以只能退一步...

当然，理想中的情况：
结合实际项目的特定，量身定制一个框架，这就是为什么很多大公司都有自己框架原因，一是有人；二是有钱；三是有时间；四是有大量的项目可做测试...

@kenshin 谢谢你这么详细的回复，也看过你的一些项目，赞。

造轮子是一种高效的学习方法

造完轮子你就会知道这些框架为什么这么碍手碍脚的

@66beta 之前不是说ci开发者停止维护，在找人接手么

@kenshin

> 或者换个角度说，如果我开发了一个类似Cairngorm的框架，那么我哪里有时间做项目，这样本末倒置了

这是说到点子上了。

我自己开发的网站因为别的框架不好用（完全无法满足自己的需要），于是用PHP写了一个完整的非全栈框架。后来你猜怎么了，维护这框架占用了我大部分的业余时间。好在后面框架成形了，可以用来搭建一些项目，不然时间就真浪费了。

@raincious
如果是非项目的话，你的这种经历会让你深入理解这门语言；如果是项目中发生的问题，那就可大/可小了，至少在风险预估上就过不去 :)

其实框架的作用在于多人团队，不在于个人开发，这就是为什么 需要OO，需要MVC 需要ORM，其实这些东西都比直接写sql写文档慢，而且要多写额外代码，但是你想过一个5-10人的团队开发吗？

如何统一不同的开发人员的层次？如何减少错误。

几年前做的一个没用框架的网站，代码量到一定程度以后加新功能真的有点想吐的感觉，还好最后网站不维护了。。。

那年学php的时候还不知道有框架，写了不少网站，现在发现有框架这个东西了，但不怎么写网站了

@kenshin

我觉得你这涉及到框架实现的问题。我一直认为使用全栈框架的风险很大，就不说迁移了，万一框架内的bundle有Bug（比如因为使用不当造成），那么隐患相当大。

我在个开发框架的时候（哪怕是给自己开发），通常都是选择最保守的路线（方针是“我是最笨的，别人有权利作选择”），不做大而全或者提供具体的功能（比如ORM这些（好吧，我的框架虽然是有，但是被独立放到了单元的部分，非框架组件）），仅仅面向项目管理，比如提供稍微强大的组件加载和管理功能。其他功能一律作为可以替换掉的组件。

如果开发者需要具体功能，可以使用Composer来管理自己的组件依赖等等。所以我框架做出来，严格来说仅仅只是一个按照一定规则进行组件加载的加载器，然后剩余的东西基于这个加载器规范进行管理。将框架本身的能造成的风险降到最低。

以上。



当然，我不会拿我自己这个框架作为负载产品的底层结构推广给公司用，理由倒不是不安全，而是这个框架的设计本身就不是为了敏捷开发。甚至于会降低开发速度（你必定需要写一些自己的组件，因为框架不提供），不适合互联网公司的开发。

而我开发这个框架是因为：

1、我不想总是跟在Laravel等一堆框架们后面等它更新，或者在它更新之后尝试让旧项目兼容新的框架。而我自己的框架做到现在最让我头疼的一次兼容性更新也仅是更换模板引擎（是的，要改模板），而我其实也能让它不需要更新就能兼容（重新打包下旧模板引擎然后设定下就可以了，但我想使用新模板引擎啊）；

2、很多MVC的项目的基本文件结构都是M一个大文件夹，C一个大文件夹（比如Controller\User\Account\Register\API这样的结构），V一个大文件夹。嗯，没错，我一开始也是这样用。但是当我项目里有100来个PHP文件飘在里面一层一层翻文件夹的时候真的感觉一点都不惬意。于是根据我的需求，我把一个大项目拆成了若干个小项目（我叫做Package）。这样文件结构就变成了类似 User.Account.Register\Application\Controller\API，虽然是换汤不换药，但是文件结构瞬间好了很多有没有，至少能让精力可以锁定到这个Package里，现在200多个PHP文件了，但是管理起来依然轻松。想如果用其他框架的话，想要这么做，得付出更大的努力才可以（但可能别的框架不需要翻文件夹？）。

3、不想妥协的接受某些设定。就拿配置全局访问设置的例子，配置有些在数据库里，有些在本地配置文件里，有些设置不需要加载，有些配置应该在使用的时候自动加载并更新缓存。一些框架很麻烦，多多少少得造点轮子。于是我造了个大轮子，我让自己的框架支持了分区自动加载，通过命名空间来自动预加载某些文件以便初始化。总归来说就是不妥协。

轮子不造，怎么知道好不好？我的观点是不论对不对，先造个出来玩。何况轮子造好之后很有意思+能学到很多不是么？