背景：leader 最近接手了个嵌入式上的管理后台项目，架构比较古早 Static Web <-> Nginx <-> CGI (C, via Unix Socket) <-> Backend Application (C) <-> Modules 。同事抢了前端部分的工作，我分到了和储存系统相关的后端模块。评审完原型后就开工了，我写好自己模块前端部分 API 的草案后，请前端的同事先帮我 review 一下，结果被怒批了一顿。

从对方比较尖锐的评价里我大概总结出以下几点：

对方观点：

1. 我不会做项目，完成任务优先级第一
2. 我不是产品经理，不要替产品经理操心
3. 我是学生思维，抓不到项目重点，写出来的东西不专业他看不懂（用不惯企微文档，加上有些术语想不到中文的名字， 草案就先用 md 写了英文的）
4. 我协作不到位，我写这部分前端接口没提前通知他（事实上一起开会时我不仅说了，还把规划写在白板上了）

对方理由：

1. 他也写了这部分 API ，比我的简单很多；我的命名不符合他的规范（这点在 review 前就提醒了，我的出发点是先确定数据结构上有没有分歧，之后命名样式一定会按照他的要求改好）
2. 他自称写过很多爬虫，也写过前端（他本职做 AI 算法的，211 硕）
3. 不能反映到前端原型的字段上就别加，不要自作聪明以为其他人没想到
4. 一年前上司曾批评过我过度设计，效率低

事后也虚心看了下他写的 API ，这里仅以我的视角总结一下他的思路（因保密协议就不贴代码了）：

1. 前端页面下一个子组件对应到一个 endpoint ，不再分级，组件全部信息放在一个相同的 JSON schema 里就好
2. 根据请求类型，后端自动去 request payload 里找需要的字段用或选择性更新 response body 里的部分字段
3. 对于一个组件内部依赖其它组件信息或状态的情况，后端应该在这个组件的 API endpoint 里也提供
4. 不假定某个地方需要扩展，不加冗余信息，产品有需求再改，总有办法能在现有接口上承载起新需求（顶多可能会让接口变得奇怪）

下面说一下这部分我的观点（个人职场新人，非 CS 专业，目前也就做做 embedded infra ，这方面可能不专业）：

1. 前端原型里部分组件 anti-pattern 的迹象很明显，一个模块里揉合状态信息、配置信息和控制指令，我倾向做 decomposition 拆到该 endpoint 的子路径里做（我很难接受前端把这种模式通过 API 扩散给后端）
2. 跨组件的状态信息，前端这边去调用对应的其它 API 处理，我的组件接口只维护生命周期在我模块内的信息
3. 在后端仅读 payload 的数据结构上做扩展冗余，及 response 里加一些未来可能用上的信息，不会对前端解析处理增加太多负担（私有 C/S 场景也不必拮据带宽成本）
4. 我的模块 leader 限制 C/C++/Rust 实现，一致性和 forward compatibility 比提前出第一阶段 demo 重要，未来有新需求需要调整数据结构或者实现时，改起来熵太高（后端规模远大于前端 / 前端 JS 解 JSON ）

其它的一些想法：

1. 在设计和评审产品原型时，从时间和交互维度审视十分重要（这次其实原型就有问题）
2. 产品经理几乎完全决定了一个产品的命运，很多时候向前端开发推进，需要先让产品经理认识到这个设计有问题（直接告诉前端要多点工作量可能挨骂）
3. 理想主义在职场很难行得通，某种程度上我发展得的比我同事差（比较看 leader 和项目的 context 就是了，这点确实我做得不好）
4. 即使我的主张合理，说服了大家做对的事情往往得不到任何好处，分外的事情，让市场和用户差评教产品做事就够了（自由市场也可能首先打我的脸）
5. 和人交好很难，这件事看出同事应该是对我有不少意见，但是自己实在想不到哪里得罪了人家（感觉很多时候我已经比较注意了，比如有些会影响到大局的细节问题在评审时我想提一下，但觉得在那么多人的会上说可能不合适，毕竟我不是产品也不是设计，leader 也没开口，也是后面单独找产品旁敲侧击让他意识到有问题）

也想听听大家的建议（比如技术方面或为人处事方面）

嗯，再补充一些细节吧：

1. 产品经理能 vibe coding 把原型网页做出来（虽然很粗糙），我模块的原型有问题要改结果一个星期还没改好，于是定接口时同事拿有问题的原型跟我对峙（产品想学习我理解，不过既然项目赶时间，老老实实上个 Figma 或者什么的不好吗）
   1. 原型里显示一个可能包含几十万个文件的文件夹没有分页，不加排序、过滤和搜索的情况下，期望用户能一下子找到自己想要的文件
   2. 原型过于简化，将操作/状态隐含在数据对象内，比如用户想临时关闭日程功能，做法是把之前辛辛苦苦写好的日程都删掉
2. 同事写的 API 规范中，很多字段应该是谷歌翻译的（概念不合适且有不少拼写错误），以及他开始打算 HTTP 明文传输密码，后面其他人说不安全换成了传密码的 sha256 （不加 salt 和开始有什么区别...)

（应该还有不少，就不浪费社会资源吐槽了）

背景：leader 最近接手了个嵌入式上的管理后台项目，架构比较古早 Static Web <-> Nginx <-> CGI (C, via Unix Socket) <-> Backend Application (C) <-> Modules 。同事抢了前端部分的工作，我分到了和储存系统相关的后端模块。评审完原型后就开工了，我写好自己模块前端部分 API 的草案后，请前端的同事先帮我 review 一下，结果被怒批了一顿。

从对方比较尖锐的评价里我大概总结出以下几点：

对方观点：

1. 我不会做项目，完成任务优先级第一
2. 我不是产品经理，不要替产品经理操心
3. 我是学生思维，抓不到项目重点，写出来的东西不专业他看不懂（用不惯企微文档，加上有些术语想不到中文的名字， 草案就先用 md 写了英文的）
4. 我协作不到位，我写这部分前端接口没提前通知他（事实上一起开会时我不仅说了，还把规划写在白板上了）

对方理由：

1. 他也写了这部分 API ，比我的简单很多；我的命名不符合他的规范（这点在 review 前就提醒了，我的出发点是先确定数据结构上有没有分歧，之后命名样式一定会按照他的要求改好）
2. 他自称写过很多爬虫，也写过前端（他本职做 AI 算法的，211 硕）
3. 不能反映到前端原型的字段上就别加，不要自作聪明以为其他人没想到
4. 一年前上司曾批评过我过度设计，效率低

事后也虚心看了下他写的 API ，这里仅以我的视角总结一下他的思路（因保密协议就不贴代码了）：

1. 前端页面下一个子组件对应到一个 endpoint ，不再分级，组件全部信息放在一个相同的 JSON schema 里就好
2. 根据请求类型，后端自动去 request payload 里找需要的字段用或选择性更新 response body 里的部分字段
3. 对于一个组件内部依赖其它组件信息或状态的情况，后端应该在这个组件的 API endpoint 里也提供
4. 不假定某个地方需要扩展，不加冗余信息，产品有需求再改，总有办法能在现有接口上承载起新需求（顶多可能会让接口变得奇怪）

下面说一下这部分我的观点（个人职场新人，非 CS 专业，目前也就做做 embedded infra ，这方面可能不专业）：

1. 前端原型里部分组件 anti-pattern 的迹象很明显，一个模块里揉合状态信息、配置信息和控制指令，我倾向做 decomposition 拆到该 endpoint 的子路径里做（我很难接受前端把这种模式通过 API 扩散给后端）
2. 跨组件的状态信息，前端这边去调用对应的其它 API 处理，我的组件接口只维护生命周期在我模块内的信息
3. 在后端仅读 payload 的数据结构上做扩展冗余，及 response 里加一些未来可能用上的信息，不会对前端解析处理增加太多负担（私有 C/S 场景也不必拮据带宽成本）
4. 我的模块 leader 限制 C/C++/Rust 实现，一致性和 forward compatibility 比提前出第一阶段 demo 重要，未来有新需求需要调整数据结构或者实现时，改起来熵太高（后端规模远大于前端 / 前端 JS 解 JSON ）

其它的一些想法：

1. 在设计和评审产品原型时，从时间和交互维度审视十分重要（这次其实原型就有问题）
2. 产品经理几乎完全决定了一个产品的命运，很多时候向前端开发推进，需要先让产品经理认识到这个设计有问题（直接告诉前端要多点工作量可能挨骂）
3. 理想主义在职场很难行得通，某种程度上我发展得的比我同事差（比较看 leader 和项目的 context 就是了，这点确实我做得不好）
4. 即使我的主张合理，说服了大家做对的事情往往得不到任何好处，分外的事情，让市场和用户差评教产品做事就够了（自由市场也可能首先打我的脸）
5. 和人交好很难，这件事看出同事应该是对我有不少意见，但是自己实在想不到哪里得罪了人家（感觉很多时候我已经比较注意了，比如有些会影响到大局的细节问题在评审时我想提一下，但觉得在那么多人的会上说可能不合适，毕竟我不是产品也不是设计，leader 也没开口，也是后面单独找产品旁敲侧击让他意识到有问题）

也想听听大家的建议（比如技术方面或为人处事方面）

嗯，再补充一些细节吧：

1. 产品经理能 vibe coding 把原型网页做出来（虽然很粗糙），我模块的原型有问题要改结果一个星期还没改好，于是定接口时同事拿有问题的原型跟我对峙（产品想学习我理解，不过既然项目赶时间，老老实实上个 Figma 或者什么的不好吗）
   1. 原型里显示一个可能包含几十万个文件的文件夹没有分页，不加排序、过滤和搜索的情况下，期望用户能一下子找到自己想要的文件
   2. 原型过于简化，将操作/状态隐含在数据对象内，比如用户想临时关闭日程功能，做法是把之前辛辛苦苦写好的日程都删掉
2. 同事写的 API 规范中，很多字段应该是谷歌翻译的（概念不合适且有不少拼写错误），以及他开始打算 HTTP 明文传输密码，后面其他人说不安全换成了传密码的 sha256 （不加 salt 和开始有什么区别...)

（应该还有不少，就不浪费社会资源吐槽了）