VIP

chongyi

Chongyi Yuan
第 874 位会员
注册于 2015-02-16 15:43:56
活跃于 2017-06-29 15:00:31


专栏文章
最近话题
最新评论
  • Laravel 学习笔记 —— 神奇的服务容器 at 2017-06-23 10:45:35

    @839891627 这篇文章里是有问题,我博客原文是改了的,但是改的是传递的参数内容。你这样改实际上最好,不过是不用做 is_array 的判断的,直接用 (array) 转换就好,性能基本没有差异。

  • 替换 Laravel 分页组件默认生成的模板 at 2017-06-07 17:30:53

    @LeO荣 直接返回分页对象啊,里面包含了需要分页的所有参数

  • 有什么可以为 PHPer 推荐的纯干货的个人技术博客么? at 2017-05-27 11:27:39

    没我的不开森

  • 【扩展推荐】Zttp ——简化你的 Guzzle 调用 at 2017-05-27 11:26:54

    这个非常科学

  • Composer 中文镜像 / Packagist 中国全量镜像正式发布! at 2017-05-26 09:38:29

    @扣丁禅师 不过我这个对性能要求就没那么多了,实现也就相对简单太多了。同步频率基本是半个月一次。

  • Composer 中文镜像 / Packagist 中国全量镜像正式发布! at 2017-05-26 09:37:09

    @扣丁禅师 我也是基于 Laravel 写的 :joy:

  • Composer 中文镜像 / Packagist 中国全量镜像正式发布! at 2017-05-24 20:19:58

    这个项目是用 PHP 原生写的还是基于框架呢?我也写了个私有的 Composer 镜像用于公司内部。

  • 面对现实吧!维护大型 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 基础不扎实、周期紧张、项目影响大,所有综合因素来判定后,慎重决定。如果你真的很希望使用且愿意为后果买单,像我这样愿意深入学习其优秀特性、思想,仔细阅读文档、源码,做到举一反三甚至能做到任意改造且升级自如,那么,你还会提出这种问题吗?