@heguangyu5 "对于没有测试用例保障的项目来说,迁移到 BPC 确实是你说的"不清楚到底有多少坑要踩"

测试用例要多少才覆盖这种"底层可能有 bug"的行为哪?

正常业务流程测试?
模拟 100 个并发测试?
模拟多少个协程并发会引起堆栈错误?
模拟用户输入中有 emoj 特殊字符会不会引起编码错误?

这需要测试的地方就太多了

@heguangyu5 至少目前为止, 普通人能接触到的途径, 还没有找到能对最新版 swoole 加密过的 php 代码能解密的途径, 我试过很多渠道, 都是"这玩意没法解密".

当然, 不排除很多更隐秘的渠道,能解密 swoole 加密过的 php 代码, 不过这样基本上对我们来说就够了.

如果用户能找到解密 swoole 加密代码的渠道, 这客户的技术水平应该比我们更强, 也不担心用户看我们产品的代码了.

其实用 swoole 加密的安全性也没问题, 虽然 swoole 加密需要付费, 不过这笔费用对于需要私有化部署产品的公司而言, 成本并不高.

主要是把 php 代码迁移到 BPC, 环境变化太大, 不清楚到底有多少坑要踩

@bronyakaka 其实最重要的一点是, 没有微服务经验, 下一份简历不好写

@ZoBoat 我们自己的内部项目. 2.0 版本引入 redux, 后来 3.0 版本, 大家一致同意把这个玩意从代码中全部删除, 再也不用这玩意了

比如状态关联, 很多项目中大部分状态关联都是 crud, 可能有一小部分全局状态关联稍微复杂点, 需要 redux.

但是引入 redux 的后果就是, 为了解决"1%的复杂状态管理", 导致其他本来很简单的"99%"的代码, 都变得复杂无比.

更烦人的是(可能我们用的版本不对或者 dva 的问题), 只要修改 redux 的 model, npm 的热加载无效, 必须重新跑一次 npm start 才行, 有点类似 java 中, 改了个 model, 整个一堆微服务都要重启的感觉, 这就太浪费时间了. 后端我都嫌 java 麻烦, 再搞一套更麻烦的前端吗?

反正我们的经验, 这玩意及其恶心, 最好别用.

新版本已经把 Redux 从代码库中全部移除了

@hjw45611 #58 小学政治书里面写的, 纺织工人团结起来打砸蒸汽纺织机的故事, 再次上演了

按照 OP 的逻辑, 如果开发了系统或者网络工具, 只要部署在 debian 上, 是不是都要开源?

@Mrun 不是瞧不起, 而是 php 这玩意薪资水平太低, 如果目前 php 岗位薪资能到 30K 起步, 你看多少人就要"真香"了

@x86 好多 spring boot 写的代码, 其实也是稀烂. 不看语言或者工具, 大部分码农的代码都是稀烂.

steam deck 如果能跑动, 就买

跑不动, 就算了

座椅通风, 夏天开了座椅通风太舒服了

@Sawyerhou 电不好说, 毕竟国内存在工业用地/民用电/商业用电 复杂的关系, 工业用电其实在补贴民用电

水/煤气/暖气 就是纯粹靠补贴了, 没见过那个城市的水/煤气/暖气企业是盈利的

@Sawyerhou 既对也不对, 不完全是"地方需要收入了才涨价", 应该是"地方没钱补贴水电煤气"

比如你是小公司的小老板, 需要招人

1. 明明有统招计算机, 甚至是一本, 为什么不选择统招一本?

2. 其实大部分大龄程序员, 日常的工作都是 crud boy/ sping boy, 换个新毕业的能力如果强一点, 半个月也能学会.

3. 大龄程序员毕竟经历过互联网 IT 的黄金时代, 经历过跳槽一次涨薪 50%的美好时代. 就算你惺惺相惜, 招了一个大龄程序员, 我相信这个哥们虽然委屈到这个小公司, 心里还是各种不满和牢骚, 一边上班一边骑驴找马, 看到薪资高的立刻就跳槽.

4. 大龄程序员大部分都是老油条了, 摸鱼技巧大于 crud 技巧


这是我的感想, 不喜勿喷

市场经济, 双向选择, 有啥不合理的?

行情好的时候爱答不理, 行情差了高攀不起

@lymanbernadette6 招聘本身也是一种广告, GNU's Not Unix