VIP

chongyi

Chongyi Yuan
第 874 位会员
注册于 2015-02-16 15:43:56
活跃于 2017-05-15 11:31:40


专栏文章
最近话题
最新评论
  • 面对现实吧!维护大型 PHP 应用程序不简单! at 2017-05-08 21:52:13

    微服务就好,也便于横向扩展。

  • 一个小坑提醒:某个 Class 或某个 Trait 突然找不到。 at 2017-05-02 09:47:04

    @j511002 调试开发还好吧

  • 我是如何和美国的骗子练英语口语的? at 2017-04-17 09:48:02

    会玩

  • 开专栏,继续挖坑 at 2017-04-15 11:22:14

    @airycanon 被你发现了

  • PHP 爬取需要运行 JS 的页面 (Run JS While Grabing Web Page With PHP) at 2017-04-06 16:01:54

    @Clarencep 是的,我觉得这样的话不如直接用 nodeJS 了。。。

  • 让程序飞起来之 Laravel OPcache Package at 2017-04-06 15:57:00

    这个简单实用

  • 打造漂亮的 PhpStorm 界面 at 2017-03-21 17:31:46

    @ADKi 那么多东西哪能全部知道 :sweat_smile:

  • Laravel 的消息队列剖析 at 2017-03-20 15:17:48

    可以的。

    帮我省了一些工作 ~ 正好最近要用一些组件重构这一部分

  • 打造漂亮的 PhpStorm 界面 at 2017-03-20 15:16:30

    现在对于编辑器风格主题已经懒得折腾了 :joy:

  • [Laravel Meetup][北京][3.25] 正式开放报名! at 2017-03-16 13:50:14

    太远,来回划不来 :joy:

  • 【单篇】PHP 开发环境那点事儿 at 2017-03-03 12:02:35

    @zhuzhichao 已修正

  • Laravel 性能问题始终难以释怀,求指点 at 2017-01-10 09:45:46

    再补一句,什么框架语言,真的不重要,人才是最重要的。

  • Laravel 性能问题始终难以释怀,求指点 at 2017-01-10 09:44:22

    @leo 这个观点刚开始我是赞同的,不过现在我觉得仅仅只拿出这几条还不够。

    不过我先针对楼主的情形直接说答案:你如果明确地知道你的项目是什么类型,包括明白一些细枝末节的东西的话,你与其担心这个,不如先把规划做好,否则你选择任何一个框架,最终结果都是跳入深渊。

    我觉得讨论性能问题有很多限定条件,并不能说开发阶段不要担心,虽然大多数情形是这样的,即要不是瓶颈根本不在框架,要不就是加机器就很容易解决。但毕竟不能抛开项目本身不谈,所以各类因素往往很复杂,三言两语也说不清楚。

    最大的决定因素就是,项目本身类型和使用对象。其次就是整个产品周期的安排以及运营方案。

    不是所有项目都是依赖数据库的,根本不存在大量 IO 的系统比比皆是。亦或者频繁的计算和 IO 并存的。对于 IO 密集型应用,不去做优化,你拿什么语言,差距都不会十分明显的,这种情景解决方案就非常多了,根据需要选择,框架毕竟是给提供工具集的东西,因此或多或少都会提供一些简单有效常用的解决办法,如果没有提供,也只不过将由框架做的变成了由你做的罢了。

    对于密集计算,这个和语言本身、框架的设计就有着相对而言比较紧密的关联了。Laravel 弱在其生命周期中参与的部分实在太多,调用堆栈之长,你会发现框架给的那些优化方案其实都是杯水车薪。虽然我在这里这么说,但不意味着你真的会遇得到,就算遇得到,那么你拿任何语言、框架你也都遇得到,只是恰好 Laravel 放大了这一切。具体优化方案和 IO 密集一样有很多,但都脱离了 Laravel 本身,因为这些解决方案,并不影响你是否使用 Laravel,不过这取决于你的基本功,如果你把代码写的很糟心,那么重构可能更好。

    还有使用对象,项目使用对象决定了你开发的优先保障目标,面向外部人群和面向内部的系统思路可是不一样的,毕竟外部的不确定因素更多,说到这里你应该能明白。

    最后,产品周期安排是你必须在开发初期选择框架时就要关注的,如果草草上线,作为负责的有态度的开发者,明明知道面向客户群体复杂且庞大、系统涉及关键节点及其庞杂,这时候你更应该选择一个你更为熟悉的框架,不应该被各类广告、宣传、以及自来水冲昏头脑,否则最终你会为你的一时爽买单。很显然我就是其中的一员,不过这样也逼着我背下了一半的 Laravel 源码,我现在已经可以做到默写 40% 的 Laravel 框架了,只要放出新特性描述我都可以做到自己先实现起。

    总结,Laravel 的确是一个高效且优雅的框架,作为其重度使用者的我也觉得这个框架已经被神话了。如果你有足够的时间且理解你所开发的项目,真心推荐使用 Laravel 作为项目开发框架。但是,如果,就像我说的,如果你对项目做不到知根知底、PHP 基础不扎实、周期紧张、项目影响大,所有综合因素来判定后,慎重决定。如果你真的很希望使用且愿意为后果买单,像我这样愿意深入学习其优秀特性、思想,仔细阅读文档、源码,做到举一反三甚至能做到任意改造且升级自如,那么,你还会提出这种问题吗?

  • 基于 Laravel collect 的 PHP Extension at 2016-12-30 11:06:03

    @vikin 我现在也没得 windows 的机子。。。 :joy:

  • 基于 Laravel collect 的 PHP Extension at 2016-12-30 10:58:25

    @vikin 我离大佬还早,现在是光会写 PHP,还不会写 PHP :joy:

  • 基于 Laravel collect 的 PHP Extension at 2016-12-30 10:54:53

    @vikin 话说这个 windows 上编译通过没?

  • 基于 Laravel collect 的 PHP Extension at 2016-12-30 10:54:13

    @vikin 要得!谢谢

  • 基于 Laravel collect 的 PHP Extension at 2016-12-30 10:33:33

    @vikin 我不知道从何下手,官网的扩展编写部分,无论是中文的还是英文的,都不全。参考资料并不丰富,很多都很旧,新的 PHP 7 的 zval 结构变动了,还没研究,好累

  • 基于 Laravel collect 的 PHP Extension at 2016-12-30 10:30:07

    PHP 扩展的开发文档是官网上的那个吗?

  • Laravel + Vue 开发单页应用 at 2016-12-25 15:31:11

    可以的。

    不过我们那套系统层级太复杂太复杂,最终我们还是决定,前端部分拆成独立项目开发,这样好管理分支一些。