又一个觉得靠努力就能打破正态分布的……

健怡可乐他不香嘛

刷一遍生活大爆炸吧，这剧能完美解答这个问题

@lxtx2018 个人理解就是 P6 以下或者 P2-3 以下的都算初级吧，对应工作时间大概是 2 ～ 3 年左右吧

@fxjson 这种一般就是调用用户信息服务查了，订单表只存个 userId 。如果一定要存在一套 DB 里那也是冗余维度存储、多条 SQL 查。现在互联网 C 端业务已经很少有联表这种操作了。

初级研发跨语言找大厂工作问题不大，但面试官会对你的非常用语言的能力进行更严格的考核，所以你要多付出一些努力；中级研发还要结合对方的岗位需求情况来看，不少社招都希望找个来之能战的中级研发快速投入到项目迭代中去。这个回复不限于 Go 和 Java

@sampeng 人少分不出基础组件部门就直接用开源方案呗。。你可以了解下各大厂的人员分工情况

正常是先单体应用方便快速迭代，中期项目复杂度、流量真的上来了或者团队人员有了更细的拆分后才会重构到微服务的，把这个流程反过来搞是不合理的。另外微服务和语言没直接关联，Java 的微服务组件生态完善不是缺点而是优点，不要觉得是 Java 系的东西就是 low 的。

@sampeng 没听说过微服务靠运维团队支撑的，最多设立个基础组件部门，里面也都是做微服务中间件的研发

以前我过人行横道时也挺杠的，后来发现现实就是大部分没有人行道减速规定城市的司机过人行道时不加速就不错了，潜意识里永远是人会让着车，不到最后几米不减速，转弯时也没人管什么转弯让直行规则，连直行的车都不让就更别提让行人了，惹不起惹不起

251

只能家中常备蔡司镜头纸了

nginx 一般是标配啊，通常是 nginx 的功能满足不了（比如应用编排、直接对接基于二进制协议的微服务）或者二开维护麻烦才会搞应用层网关，后两者使用起来大同小异吧，如果你们真的是高并发的话后两者都有不少性能上的坑等着你们去填

可能需要换个思路用 gRPC 这类实现？不过 HTTP 1.1 下 JSON 格式绝对是当下使用和维护成本最低的方案。

简单的 M 端管理系统我觉得没问题而且现在也已经有一些方案可用了。但非 M 端的系统对性能和体验是有要求的，对于自动化系统来说这种调优能力即使是未来也很难实现。另一个就是业务逻辑复杂的系统，复杂到流程图能画两三页、各种状态机流转，这种业务如果用可视化的方法去拖拽我觉得和写代码也没什么区别了，调试和维护体验上还不如写代码，所以这种场景也是不适合的。

没问题，但如果是体量大的项目你要有造轮子的能力和人力，另外一定要和你们公司整体技术栈统一

对非前端、客户端的开发者来说不太友好，很多涉及底层的逻辑由于架构的差异会导致本地调试的结论并不可信，更别提一些底层工具链在 ARM 上的编译问题了。真希望只是小尺寸 MBP 改用 ARM，大尺寸的仍保持现状。

我们是自研的，需要一个包含产品、至少四个端研发和测试的完整大团队来做，成本还挺高的