借楼出：
layaojing.com 辣妖精 600
paotu.cc 泡图 600
yadou.net 芽豆 600

感谢 op

100053 支持一下

@a132811 这种怕不是版权问题，传播知识，恐怕是为了让 github 好看的恶心行为，刷 star，改的内容大部分换换函数名，调整文件夹结构等为了抹去以前项目痕迹的行为

@egen 你可以看下这个人更新的内容。。commit 数多不表示什么，每天加空行，替换掉以前的项目名和函数名有啥价值，
还有那个 astaxie 的那个 pr 里边都是提交的什么。。正常人天天盯着那种去改么，还是说为了更多 pr 然后展示在个人主页，。
有么有可能看到这个

这哥们 vcaesar
另一个仓库 https://github.com/go-vgo/robotgo 跟 https://github.com/octalmage/robotjs 代码也有点像啊。。

header("Content-Type: image/jpeg");
echo file_get_contents($img_array[$img]);

我也是做量化交易的，先不说楼主这个利益啥的如何，起码好多人先了解下量化交易再来说，不要为了黑而黑，
量化交易本身作为一个行业还是有搞头，越成熟的领域竞争越大，反而不那么成熟的地方其实对于好多人才是机会，什么都成熟了，你去了还有你啥事，
就跟比特币一样，好多人都是觉得有么价值，而不是想的是这个有么机会挣钱，价值重要还是能不能挣钱最重要

我最近也在做量化方面的工作，希望有机会可以一起交流学习

刚看到 https://github.com/laravel/framework/pull/26898 Laravel 也要开始移除全局方法了

很多的框架都有各种全局的变量，常量(define)，函数，没在命名空间下定义，虽然有 function_exists 来判断后定义，但是会带来的问题是增加了开发人员的心理负担，比如定义了同名的，但是作用不同，那可能改变了很多。

框架作为底层，要减少应用开发人员的使用成本，减少黑魔法也很重要，也方便开发人员统一书写，比如 laravel 中很多时候，一个团队对一个请求参数的获取有好几种写法，我觉得这些地方就增加维护成本，虽然见多了就知道了，但是搜索替换的时候~

@ericgui 我就是觉得那些都设计复杂了，就想着搞个精简的只提供必需的，代码简练点的框架

@xiaotuzi 没咋个明白，我觉得已经够简单了吧，那咋个更简单了，比如？

@conn4575 这个其实是写着玩的，另外就是开源的框架中我喜欢 laravel 的代码，但是不喜欢 laravel 那种包都是依赖他自身生态的，我更喜欢 sf 框架那种组件化，每个包尽量少的依赖那种，所以会看到 sf 的包被大量的其他框架所引用，另外就是 lara 的代码写的比较绕

所以我就结合 n 多框架的实现，其中大量参考 laravel 的实现，简化提高可读性，另外就是减少依赖，当练手。

其实我建议新人都写一个自己的框架，练手也好，提高基础也好，这样会更能理解一个框架的运行原理，也更知道怎样的代码怎么写出来是具有可读性，可维护性，可扩展性特别是框架层面，在用其他框架的时候也会更加得心应手，很多时候以为框架很简单，但是只有自己去实现过一个后就觉得不是啥都是看起来那么理所当然，里边可能一个细节都是有思考的。

比如你写了框架你就知道用 composer 的好处不只是方便引入其他的包，对于框架还有个好处是，不让应用开发者随意更改框架核心代码（以后不便于升级或则框架 bug 修复啥的），但是为了在允许开发者自定义的地方要支持可扩展性，所以其实这些过程中的思考都能提高编码水平。

再比如，对异常的理解，如果吧 php 的异常和错误处理了解好了，就可以写出更好的代码，而不是通过 true false 之类，好多框架在这块的处理也不是很合适，比如错误发生的情况有的喜欢直接屏蔽，有的是直接 handle 处理了，其实更好的方式是转换为异常，这样写业务的时候，就算错误，你可以选择 catch，也可以不 catch 走全局的异常接管。这也是为啥不要直接裸写 php，框架其实对这些都做了处理可以减少新手犯错的可能，异常处理可以参考 laravel 和 yii 他们的处理方式，当然也可以参考我这里的一个包实现，https://github.com/Jetea/exception

@zn 这个是之前工作过的两家目前国内还算知名的互联网公司的思路中提取出来的代码，他们有类似这样的模块代码组织框架，其中一家公司 06 年就开始了，所以代码量复杂点的问题不大。

想象一下，如果大家用同一种方式来写逻辑代码和复用代码，而不是放到控制器中，是放到一个可以共用给 web，命令行脚本，第三方开放 api，移动端 api，admin 后台等多个不同的项目的公共逻辑代码库中，提高了复用性，

为啥不用微服务来复用，因为小公司来说，不用那么复杂的调用和部署维护，虽然 rpc 调用也简单，但是 http 还是有开销，特别是对于 php 这种每次请求都要从框架第一步开始。同是 ctx 也提供了 rpc 的可能用于在部分业务需要单独部署优化的时候。所以 ctx 这种代码共用到其他项目中，直接引入 require 的方式性能更好。

另外就是 ctx 是只要保证模块对外的方法输入参数和返回值不变，那么其他模块的开发者只需要关心自己模块的实现就行了，所以经过 n 多年后，就算新入职的同事，参与模块开发的时候只需要了解自己模块就行了，其他模块逻辑和其他模块的数据库根本不用关心。


一下子说的有点多，也有点乱，🤣

@jfcherng 哈哈，差不多，就是模块之间组织和调用。