0

像大型项目怎么办呢?不用框架。都自己手写膜?
还是不用PHP。用其他语言做?

atekul 1.1k
2015-08-22 提问

查看全部 13 个回答

0

小、中、大型的项目都可以采用框架!有条件的话,建议尽量使用框架。

既然别人已经写好了那么多框架,那么就不要再去重复造轮子了,而是学习怎么使用它。

去学习一些重量级的框架,像Symfony、Yii、Phalcon、Laravel等等,
这些框架在很多大项目中都有使用。当然如果你以后参与到中、大项目中,也很可能会接触到他们,
你现在学习并使用他们,是为你以后打下铺垫!

一个重量级的框架,牵涉到的东西很多,也有助于深入学习PHP。

推荐答案

19

已采纳

犹豫了一下还是来回答一下这个问题,这是我面试的时候经常问的问题,因为每个框架和每个项目都是不一样的,选择框架是一件非常看经验和思考判断能力的东西。

项目大小只是决策的一个根据而已,甚至还是不怎么重要的一个根据。下面聊聊我认为选择框架时需要注意的地方

团队成员情况 & 未来团队成员情况 & 所在地职业市场情况

首先,如果团队现在和未来都只有你一个人(比如自己的toy project),那选自己最想用的就好。但只要不是这个情况,你最好先得了解市面上常见的各种框架,然后忘记自己的个人偏好。

了解你的团队成员的现在情况,考虑你的团队未来的发展速度,未来可能加入的团队成员的情况,以及你所在地职业市场情况。打比方说,Laravel或许是个不错的选择,但如果你在二三线城市,团队又必须高速发展大量招人,选择Laravel可能很快会让你陷进“composer和现代PHP技能培训班”的窘境,布教是一项伟大的事业,但不是你的职业

项目生命周期 & 未来演变方向

这就是我觉得远远比项目大小要重要的因素之一。有的项目,作为贵司的主营业务是需要长期维护,持续迭代的。而另一些项目可能作为一些边角、过渡的项目,可能做完以后不会再有什么后续的需求。最后还有一些外包/类外包的项目,交付以后就没有需求/后续需求可以当另一个项目。

再大的项目,需求再多,如果是第三种,无需考虑未来演变的,那么框架的扩展性就能够被牺牲(从而换取开发速度或其他好处),打比方说wordpress改改之类的选择就可以被考虑。再小的项目,如果是贵司的主营业务,持续迭代的,那么就算工作量再小,也必须慎重考虑框架的扩展性。

那么,什么是框架的扩展性呢? CI是扩展性很好的框架吗?ZendFramework1/2是扩展性很好的框架吗?

答案是,看未来演变方向。有的项目未来的压力在访问流量大,有的压力在数据量大检索频繁,也有项目压力在需求迭代快,变动频繁而周期短。项目面临的问题越是普遍,那么预设各种解决方案的框架可能越能减少重复造轮子,反之项目面临的问题越是极端,那么轻量化的那些框架可能更适合让你的团队自己研究解决方案嫁接到框架中。另外,项目维护的时间越长,变动越难预测,采用预设各种解决方案的框架的风险就会越大(那些预设的解决方案恰好能解决你的每个问题的概率越来越小)

框架本身的基本素质

性能和跑分。除了phalcon和Yaf两个C实现的框架,其他框架请认为一样快。另外除非你在主持类似新浪微博更换PHP框架这样的事,或者说除非你管理的项目web机器超过100台,请忽略PHP框架的性能因素

psr和composer亲和性。这是双刃剑,前面已经聊过怎么看待这个特质了。

安全性。某些框架甚至本身自己有安全漏洞不多说。另外如果框架层面提供了一些安全方面的东西,建议还是要简单看一遍代码,有时那可能反而不如自己写。

功能性。也就是预设的解决方案的数量和质量,前面有提过。

模块化程度。框架内的各个部分是否能够自定义,自定义的代价多高。

业务代码量(?)很难找到对应的词,总之有第三个特性和前面两个(功能性&模块化程度)一起,无法达到三者兼得。功能特别多,模块化程度又高可以随意定制、替换的框架,往往普通的业务代码也要写一堆。 一句话能写出一大堆功能的框架,往往模块化程度不理想,不容易自定义。 模块化程度高,而业务代码不啰嗦的框架,则往往没有丰富的预设功能。

周边生态和活跃程度以及兼容性。活跃的框架就还有成长和改进的空间,但相应过于活跃有时会导致应用无法兼容。另一个指标是周边的生态,有没有其他人基于这个框架开发一些周边的模块/插件之类的东西。


最后,如果一定要用“大”“小”这样粗暴的词语来描述框架和项目的话,我的建议是大项目用小框架,小项目用大框架。如果你看懂了我前面的说法,那应该能理解为什么我会这么说。

3

“大项目用小框架,小项目用大框架” 棒!

hylent · 2015年08月25日

展开评论

你可能感兴趣的

推广链接