skyworker

@vituralfuture 我猜 OP 是这样想的

@vituralfuture 因为是 B 端软件, 不想给同行, 或者其他人, clone 后自己打个 logo 就去赚钱的自由(说白了, 那个同行可以 clone 拿去做私活)

最近公司招聘都看是否有仲裁记录了, 小公司也是这样, OP 自己衡量下吧

@sagaxu 同意, 我的经验, 基础学历越高的员工, 综合水平更高的可能性更强.

学历一般的员工, 基本上他自己没有什么主动解决问题的能力, 上班就是把培训班或者毕业时学习的东西重复, 比如 crud

@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 麻烦, 再搞一套更麻烦的前端吗?