所以显示输出接口 io 和写 ssd 盘有什么关系

角度问题，用指腹侧面（或者说肉）按呀
我扭了半天才试出来怎么能碰到指甲的

phpcon 送 phpstorm 是吧，发推广或者 php 节点应该没问题

"项目管理"一般意义上指的就是多人团队开发的时间、进度、风险的协调推进和控制工作

而楼主你的描述东一榔头西一棒有在说环境隔离的，数据库维护的，巡检如果是运维意义上的巡检的话那就说到了运维，还说了个人精力管理，就是没有和项目管理有关的描述，也没有说你碰到的困难到底是什么

所以我觉得你应该先学会分析、辨别问题，从对你困扰最大的开始一个一个解决，至少提问的时候一个一个问

static::class 是 late binding 的，或者 get_class($this)，__FUNCTION__永远是字面上的那个，如果你要的是类似 debug log 的功能，那要的可能是调用你这个基类方法的那个方法的名字，那就只能从 backtrace 里拿

另外，我觉得你可能更需要的是 xdebug

我反而觉得做业务安全感比做基建高多了，做基建不写业务，一旦晋升受挫，跳槽范围就锁定大公司，小公司根本没这个预算。做业务一个不行换一个，一家公司不行换一家公司

怎么应对大公司瞎造轮子浪费资源的现象那是大公司 CTO 的课题你我都不到这个层面，不如说如果并没有花力气解决，说明这种浪费并不是大公司现在面临的最大的问题，倒是技术人员的晋升评级体系一直是个问题

不荒谬，想的太多书念的太少
缸中大脑也好机械宿命论也好都是很老的东西了

@jinliming2 你可以仔细看下 https://promisesaplus.com/ 这里有几个要点：1. new Promise 的行为并没有被标准化，2. promise 和 thenable 的处理是不一样的 3. 实践中一个 promise 实现却很难探测出 promise 和 thenable 的区别 4. 标准中的 onRejected 是有递归展开行为的

补充我自己的回复，楼主的出题基本聚焦于不在标准中的，而且实战中属于需要避免的写法，所以不是一个好的题目，类似 i++ + ++i

这种考察是否 promise 熟悉的方式我认为不合格

@rrfeng Fun 是 A 结构体的，类型为 B 的变量 b 即使实体是 A 也没法直接调到，所以才有那个匿名接口的类型断言

其实就是懒得写一个 Fun 的接口了而已，为此丢了编译期检查，又不愿意判 ok 引入 panic 的风险 :doge:

没有开源协议会妨碍你自己商业收费

你说允许客户二开后转卖，那么是否允许客户原封不动转卖？是否允许未付费的随机路人用作商业用途以及销售？ 如果不允许，那你做的就是“公开源代码的商业项目”，而不是“商业化的开源项目”，用不了开源协议

如果开源但希望禁止其他人用你的名字、组织和项目的名字来宣传，可以用 BSD 3-Clause，如果你还有商标或专利方面的考虑，可以看 Apache

本人不是律师或法律相关专业，更专业的以及更符合国情的意见请咨询相关法律专业人士

阅。还是 mini 香

我赞同工程师应当有产品素养，但不应当是为了替代产品的职责，而是为了正确找到产品需求和具体实现复杂度的平衡，产品即使懂技术，他也不了解项目的具体实现和技术债，所以产品需求当中一定有“虽然是好的体验但并不值得大量的研发维护成本”的部分，和“其实不需要太大成本就能做到更好的体验”的部分，工程师应当负责填补这个空白

我觉得楼主作为技术负责人，对产品团队若有若无的敌意是非常不可取的，先抛开产品团队其实并不差的可能性（你是否真的理解产品工作的复杂性？），即使产品团队真的不行，作为技术负责人，应该做的也是和产品负责人沟通交流看能否改善，产品负责人也不好沟通就和老板沟通。同时一定要避免煽动团队对抗产品经理，下面的人对抗就算了你作为领导也对抗那整个公司的协作配合的氛围就完蛋了。就好比销售和风控，开发和测试的关系是一样的，指责上可能有冲突，但团队之间一定是要配合的，讲默契的，这个氛围是需要双方领导一起来建设的

然而你不先工作这两三年，面试了也不会有那么多收获的

v2 还能试试走语音或者对接打码平台什么的，v3 因为根本没有 challenge 流程所以只能想办法伪造让自己看上去像普通用户，被判定以后无解

@shadowyue 问完概念让候选人举个实际碰到的项目里例子

@morethansean 写一些简单的并发和错误处理，面试过程中可能是本能以为 async/await 简单，会有人准备要用，然而最终很少有人能写出来，基本都要让他们回到用 promise 的路上

哦，如果你是说用 await 把所有的并发都变成串行也算是写出代码的话，那可能是 async/await 更容易让人写出代码

@rrfeng 所以说我观察下来就是能写写 promise 但一换 async await 就不行了的人挺多的。反过来 async await 写的好的，换 promise 也能写，就是幸福指数下降罢了，也就是说 async await 带来的字面上的简单让不少人误以为自己能轻松把异步代码写好了（然而并不）

我觉得 golang 关于语法糖的思路也是有这种拒绝虚假的幸福指数的倾向，不做让复杂的事情（异步／错误处理）表面上变简单，但并不降低实际复杂度的语法糖