实践是检验真理的唯一标准;简单胜于花哨
最近发表的评论
  • Composer 有没有类似 maven 中包继承的功能? at 1天前

    @hausir composer require other_project 这不是安装普通扩展包到vendor吗?

    maven那个是可以把其它的项目引入到自己的项目,和安装扩展包是两个概念

  • Composer 有没有类似 maven 中包继承的功能? at 1天前

    @hausir 我找个时间做做实验看看

    @__中国人 谢谢关注
    @Gabrielodbo 谢谢关注

  • Laravel-admin 发布 1.6.10 版本 at 6天前

    @terranc 好的,我回头试下

  • GraphQl 的优势是什么?来讨论下 at 1周前

    @xuding 这个不是关键点,REST api也可以做到不传fields,什么参数都不给,这个取决于你自己怎么设计。

  • 在 Laravel 中使用 GraphQL 一【获取数据】 at 1周前

    文章中的图片都没了

  • 劳动节快乐,Laravel 之道终于完结了。我的 Laravel 源码学习之路也算告一段落喽。。。 at 2周前

    TIOBE就是一个娱乐排行榜。

  • valet 切换 PHP 版本 at 2周前

    valet。绝对是被低估了的开发套件,绝对有实力担当的起最好用的开发环境的称号。

  • MySQL 社区规范 | 数据库篇 at 2周前

    @AlicFeng 如果仅仅是为了维持数据在500万行就做分库分表,代价太大。
    个人的亲自工作经验,mysql优化得体的话,上限可以达到2亿行之多的数据,很多小公司数据终其一生也达不到2亿行数据,所以设定500万行这个硬规定,会把很多小公司拖入过早优化的深渊。

  • Laravel-admin 发布 1.6.10 版本 at 2周前

    @song 楼主很棒,功能超赞。
    不过admin创建的菜单,不能自定义排序,这个小功能能否fix下呢?

  • MySQL 社区规范 | 数据库篇 at 2周前

    写的非常好。
    关于数据库行不能超过500万行这个,实际上在这个时代数据库超过500行太容易了,所以说有什么办法可以解决这个问题?

  • polarphp 0.0.1 alpha 发布:全新 PHP 运行时环境 at 3周前

    加油,干好了我给你打赏

  • (译)别再使用 JWT 作为 Session 系统!问题重重且很危险。 at 1个月前

    第一次看到jwt这个方法的时候,我就一直有个疑惑,这东西带来的价值是否独特?发出去的token如何作废?

    有没有引入新的问题需要再另外引入解决方案,引入新的方案还需要额外解决方案吗,再引入额外的方案为解决前一个方案引起的问题而再引入一个方案......................

    只是当初很多书籍和专家各种鼓吹jwt的好,不同的声音只会被打上“你不理解,你不懂”的标签。

    说点自己的观点,这些年,IT圈,尤其是js,以及以laravel为代表的一波phper,陷入了一种为了设计而设计,为了用技术而技术的怪圈,从而变成麻烦制造机。完全忘记了工程师的职责是什么,工程师的职责就是创造性的,干脆利落的,有经济价值的解决问题,而不是总在制造麻烦。

  • 设计模式超级简单的解释 at 2个月前

    介绍和注意里面对设计模式的定义非常准确。
    作为工程师,我们应该学习和了解设计模式,但是不能够为了用设计模式而模式。
    滥用设计模式的后果就是除了让代码看起来整洁一点,随之而来的就是逻辑碎片化,结构僵化,使得本来很好维的系统变的极其难维护。

  • 我是 Laravel 开发员,不是 PHP 开发员 at 2个月前

    @yourself 如果数据结构设计不合理,且代码流转过多,代码凌乱是必然的。
    区别只是:有的代码凌乱是暴露出来的,有的代码通过各种设计模式和黑魔法,把凌乱的部分碎片化并隐藏起来了。

    对于直接把凌乱的代码暴露出来的项目,我通常认为还有救,因为通过凌乱的代码,有经验的人一眼就能识别出项目的病灶在哪里。
    而通过各种设计模式和黑魔法把凌乱的代码隐藏并消解起来的项目,基本就没救了,因为在隐藏问题代码的同时,也把真正的顽疾隐藏了,一环套一环一栈套一栈的调用链无限拉大了调试难度,日积月累,这个项目必然变成一个黑盒子,无论是系统自己报错还是通过调试工具分析,都很难找到问题的原因所在,当然,你说不依靠工具,就就靠优秀程序员的脑子就能搞定,我是没话可说了的。

  • 我是 Laravel 开发员,不是 PHP 开发员 at 2个月前

    所有代码上的骚操作,都是在为数据结构设计上的失误打补丁
    一份设计良好的数据表和业务数据字典,会让你省下很多垃圾代码,因为代码的作用就是忠实的解释和描述业务字典和数据结构关系,主谓宾关系只要不乱,你的项目就会即干净又好维护

  • 我是 Laravel 开发员,不是 PHP 开发员 at 2个月前

    @yourself 你的这种做法只适合项目是你一个人做,或者你的项目不会流转。
    只要你的项目流转,会被不同的人编辑,代码凌乱根本无法避免。

    而一份设计良好的数据结构和业务模型,可以帮你构建出simple and clear的代码来。

    不去研究数据结构和业务数据间的关系,而去研究所谓的代码目录划分和骚操作,是本末倒置的做法。

  • 我是 Laravel 开发员,不是 PHP 开发员 at 2个月前

    @yourself
    你既然肉眼能够看清楚您接手的代码有如下问题:
    1、变量命名无规则。
    2、一个控制器3000行代码
    3、嵌套循环
    4、各种if嵌套
    5、10几个位置引用了同样一套逻辑
    6、一个方法里面new 8遍类

    那么是不是充分说明这份代码是十分透明的且直接的?
    这种代码简单粗暴鞭辟入里的代码只要是个编辑器,就能够做好上下文分析,所以说:
    所以说,无论是变量名无规则也好,10个位置引用了一份代码也罢,利用好IDE,做灰度重构完全不是问题。

    但是:
    如果一份代码new了8遍,10几个位置引用了一份逻辑,并且这些代码还琐碎的散落在各个文件目录下,引用时还不是直接引用,采用了各种__callStatic,各种黑魔方,各种“优雅”的骚操作,那对不起,这个时候恐怕IDE都帮不了你了

  • PHP-FPM 与 Nginx 的通信机制总结 at 3个月前

    赞👍。
    期待多一些这种讲解基础知识的文章,少一些那种什么代码目录划分,过度讲解设计模式这一类的文章

  • 我是 Laravel 开发员,不是 PHP 开发员 at 3个月前

    说点题外话:我现在招人的时候,都有点不敢用那些自称精通laravel和yii,zendframework的人了。好几个这样的人,都有一个共同点,活干不出来什么,却喜欢在项目中搞一大堆乱七八糟的设计,这样做给项目带来益处了吗?事实上并没有,比如我交代一个哥们,写一个代码,用来替换现有的金币查询逻辑,简简单单一个函数或者方法就完成了,结果这哥们儿搞了半天,测试的时候还老是不通过,我不信邪,看了下他的代码。我滴妈呀,就这么个简单的需求,这哥们又是单例,又是要解耦,还要弄成组件,业务先撇开不谈,一测试报错全是他这些设计带来的。什么问题没解决,他倒是又引入新的问题要解决,我愤怒的让他滚了。

  • 我是 Laravel 开发员,不是 PHP 开发员 at 3个月前

    @Shuyi 我以血泪经验告诉你,一份设计良好的数据库结构和业务数据结构,对于项目的可维护性而言,远远大于风骚的代码组织形式。
    风骚的代码组织结构,在90%甚至是99%的场景下,带来的困扰远远大于收益。
    我手中有一份7年前的php写的接口,这份接口代码超过了2万行,没有使用任何框架,变量命名各种风格都有,但是数据库结构完整的描述了业务逻辑,所以即便是新人,拿着源码只用了一天就可以进行开发工作了。

    另一个项目则是前年用Laravel构建的,我也是手贱,被laravel灌了迷魂汤,各种DI,service,IOC,response都用上了,还自我吹嘘这是“优雅”,扩展性强,现在再看这个项目,没人愿意接手,我自己都特么想把那时候的我纠出来锤一顿。

    最后奉上一句linus的话:Code is shit,Data structures are the soul.
    代码都是垃圾,数据结构才是灵魂