chongyi

Chongyi Yuan
第 874 位会员
注册于 2015-02-16 15:43:56
活跃于 2017-02-24 11:46:52


专栏文章
没有任何数据~~
最近话题
最新评论
  • 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

    可以的。

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

  • [入门] Laravel 5.3 与 Vue 组件如何协作,轻松的完成前端的工作 at 2016-11-18 15:58:45

    不错 ~

  • 大家随便感受一下慕课网 229 的 Laravel 实战课 at 2016-11-17 16:59:14

    @overtrue 我还是自己博客写文章吧,我觉得写技术分享文章才能沉得下心来

  • 大家随便感受一下慕课网 229 的 Laravel 实战课 at 2016-11-17 16:55:39

    @overtrue 为啥啊

  • 关于 Laravel 项目里的 .env 文件的使用 at 2016-11-14 23:33:01

    @overtrue 其实换句解释方式就是,在 .env.example 定义一个模板,不同环境下复制一份出来改就好咯

  • 好用的 CURL 类 at 2016-09-30 10:08:59

    @Summer 爬虫必备

  • 遇到一个很奇怪的问题, 关于原生 sql 和 ORM 的 at 2016-09-28 09:19:02

    首先,你没说明上下文。比如我不知道结果到底有什么不一致。

    所以问问题请先将问题写的非常详细。

  • 从这篇教程开始, 成为 Sublime Text 大师 at 2016-09-14 10:05:37

    @Polly3D VS Code 是个好东西,和 Atom 类似,都是 “黑科技” :smile:

  • 从这篇教程开始, 成为 Sublime Text 大师 at 2016-09-14 09:37:38

    @Polly3D 编辑器就是编辑器咯,说白了就是 “记事本” ,再高级插件再多也还是个 “记事本”。IDE 顾名思义除了包括编辑器这一个组件之外,还包括调试工具、重构工具、部署工具、数据库工具、版本控制工具、代码分析工具、团队协作工具、任务调度工具等,且可以易于扩展。

    除了极客和极少数程序员,主流还是 IDE,毕竟功能齐全易用,编辑器只是开发中的辅助工具,因为其轻量,对于个别小的程序开发或者简单编辑,编辑器就是最合适的。

  • 从这篇教程开始, 成为 Sublime Text 大师 at 2016-09-13 16:03:42

    不错 ~~~ 不过编辑器我现在用的是 Visual Studio Code , IDE 用 PHPStorm ~ :smile:

  • 「PHPHub 社区」正式更名为「Laravel China 社区」 at 2016-09-13 11:21:29

    很好很强势

  • 打造完美的 Ubuntu16.04 开发环境【持续更新】 at 2016-09-06 17:39:10

    还是觉得 ubuntu 原生界面要好看些,,,逼格也更高。。。