awesome stuff

可维护：
每个项目都有自己的生命周期，在开发结束之后，剩下的大部分时间可能就是在维护一个产品，这时候项目的结构和开发流程就显得比较重要如何让新来的同事快速接手或者自己重新写扩展的时候比较方便，这也是一个因素。像严格的 mvc 模式 c、m、v 目录基本都是被大家所认可的开发起来也大致知道怎么放代码怎么写代码。

性能问题：
很多人都在关注所谓的性能问题，但是真的从一个 hello world 上能比较出什么么，我写一个 40 行的单文件类，绝对比那些框架快，但是有啥用？
中小框架在意执行效率大型框架在意生产效率。
很多同学把程序性能当成头等大事，但是对于大型的项目来说，往往结构以及生产效率才是值得关注的。性能可以通过其他层面来弥补。

有一句话是这么说的：不要过早的去优化所谓性能，没达到瓶颈之前那就是过度设计。

了解框架层面以外的东西

我们大部分程序员可能一直都处在” 用” 一个框架的层面，不管是内部的、开源的、或者自己写的。

和上次新来的一个哥们交流给我的感觉就是我会用 xx 框架 xx 框架如何如何。
我反问换个框架你会用不给你三天时间熟悉一个新的框架两星期做个 demo 可否？
他不置可否。

所以不能被框架限制住了我们的思维，除了框架本身的 api, 更多的要了解框架层面以外的东西。
比如 http 协议比如设计模式比如缓存方案、数据库设计、大并发的处理，这些东西都是每个框架都会面临的共有的问题。

当一个东西重复出现的时候你就要思考这个东西他背后的机理是什么如何改进。
就和写代码一样我们最简单的重构就是看到重复出现的代码我们会把他用一个 function 包裹起来，或者用一个类封装起来、或者写成一个接口这都是很好的例子。

遵循 DRY 原则做到这个很难但是我们要有这个意识。

看 web 开发层面而不是 PHP 语言层面

现在的 web 开发虽然 PHP 占了主流但不代表是唯一。 Java、ruby、python、nodejs 都占有各自的一部分天地。

我们要了解和吸收的应该是其他语言在 web 开发层面比较好的理念和解决方案，而不是局限在 PHP。

这里以依赖包管理来简单讲讲：

我们应该都有这样的意识，当我想要某个功能的时候如果不想自己写我们可能会去市面上找已经写好的某个类库然后把他们用到自己的项目中。
在 PHP 层面可能只是一个单文件类，或者一个类库，封装好了想要的功能。于是我们把他集成进来了功能跑起来了客户很满意。 ok 解决问题。确实，在大部分情况下这样就够了。但是进一步思考一下，如果哪天客户对于这个扩展类的需求又变了，你是重新寻找新的类库？还是在之前的类库上增加扩展？如果要增加，该怎么加？是不是好加？加了之后怎么维护？也许你把他扩展了，自己用的很好，也想开源出去给别人用，放哪？有可能你会放到 github 上，但是谁知道？你也不可能花太多的时间去推广你的类库。当无人问津的时候，你写的东西可能就跟杂草一样，只能慢慢腐烂成记忆。

这也就意味着我们一直在重复造着各种各样的轮子，质量还层次不齐。

看看其他语言怎么做的
ruby 有 gem nodejs 有 npm python 有 pip。。
PHP 有什么？
老掉牙的 pear？ no！Composer 的出现就是为了解决依赖包管理。相当于上面其他的语言的依赖管理器

当我们想要一个功能的时候可以直接去搜索关键字找到需要的功能，
写一个 composer.json 文件把需要的依赖写进去然后执行 composer install
ok 这样你需要的依赖就集成到你的项目中了

好处是什么呢？