其实就是后端的一些编程过程导致的：可能存在状态扩展的是 1/2/3 ，数据库存了的是 0/1 ，手搓了业务逻辑的是 true/false 。以前大单体时代一堆接口可能还有一个项目框架限制一下，现在微服务时代基本处于管不了的状态。就算这种通用中间件可能 A 项目用 1.0 ，B 项目用 1.1,C 项目用 3.0 。大部分情况下为了通用性和适配调用其他服务的弹性和自适应，返回的信息基本都是透传，项目内可能压根就没转换过，json 的序列化和反序列化还是比较消耗性能的。
前端的一个项目往往由后端一堆项目的接口组成，经常跨语言跨项目组甚至跨部门跨公司，技术规范都有较大差异。这是分化带来的遗留问题，同时也带来了机遇和挑战。
如果作为前端感觉经常对接一群后端，他们组还不一样，可能收口就在前端，最好自己做 bff ，沟通成本会比自己实现高得多。如果经常只有一个后端对接或者后端就是个单体只给你们提供接口和服务，催他们 leader 写个统一的规范也是应该的。

吐槽没堆栈信息的是都不用 trace_id 吧。不用 go 的生态只单用 go 语言，有不契合当前熟练语言的生态东西和思想，引发很多吐槽确实很常见

lativ ，台湾品牌，质量还行。不过优衣库和 muji 都可以等节日四折

你要是刷题的话应该知道把，最基本的数据结构，大一大二就学。

@anmie 既然知道自己没怎么干活就不要瞎评价工作量好吗。。。。产品挑战你工期说你就一个页面一天别人一天能干完你怎么要七天，你啥感受？

老家除了 java 和 php 没得选吧

@rimutuyuan 正规企业都是再招一个好吗。。。。

刷题少了

bGF6eV9wYW5kYS0z 加我可内推

我水平倒是还可以，但是人在大厂。

用 obsidian 和 dataview+kanban 插件自定义的，除了可以根据 todo 标准敏捷工作流，还可以双向链接记录详细摘要。然后简单的查询就能制作报表、生成时间轴各种花里胡哨的东西

后端业务的话，通过测试报告/技术文档/prd/产运记录的反馈整理正向&逆向业务流。代码本质上就是实现业务的手段，懂业务很快能懂代码为什么这么设计

楼里讨论这么多，其实最大收益方式是把工程师转成产品然后出去谈客户

迅速转 web 服务端开发不行吗

操作角度：重写子模块，切流，把旧模块饿死后下线。
子模块划分：简单业务后台，调用依赖低于两位数的按业务拆分就行，复杂系统按 DDD 思想基于领域拆好界限上下文，可以参考这个系列文章 https://tkstorm.com/2021/07/%E9%A1%B9%E7%9B%AE%E5%AE%9E%E8%B7%B5ddd%E5%90%8E%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%80%83/。项目结构组织按照顺手得来，不必非要照抄，数据格式转来转去徒增工作量，保持高内聚低耦合的代码设计思想，找个技术好的单兵做好通用 sdk 开发。
项目进度把控方面：不建议成立技术专项试图一次花半年全改，这样很难体现你的收益。列好要改的点，每次业务变更的时候多留点 buffer 做重构，做好里程碑奖励和组织激励工作。
最后推荐阅读《凤凰架构》，再好的架构最终都会腐化。接受会腐化的事实，做好防范工作（代码合入审查），保持组织人员流动健康和业务正常推进（不要 996push ），持续重构和优化。

相对于 go 缺点：部署烦，跨平台烦，依赖安装一坨，异步编程极度痛苦，看同事 py 代码很痛苦
相对于 go 优点：灵活，可靠的第三方库多，很多语法糖相当舒适

有没有一种可能，先说期望的结果，然后聊详细落地方案是比较高效务实的沟通方式。期望结果不一致十分钟就可以散会，而不是 battle 三小时用户群体用户需求最后发现 A 想做京东 B 想做叮咚买菜？