Login
记因 API 第一次挨同事骂
19 October 2025 at 15:17
unbinilium:
背景：leader 最近接手了个嵌入式上的管理后台项目，架构比较古早 Static Web <-> Nginx <-> CGI (C, via Unix Socket) <-> Backend Application (C) <-> Modules 。同事抢了前端部分的工作，我分到了和储存系统相关的后端模块。评审完原型后就开工了，我写好自己模块前端部分 API 的草案后，请前端的同事先帮我 review 一下，结果被怒批了一顿。
从对方比较尖锐的评价里我大概总结出以下几点：
对方观点：
- 我不会做项目，完成任务优先级第一
- 我不是产品经理，不要替产品经理操心
- 我是学生思维，抓不到项目重点，写出来的东西不专业他看不懂（用不惯企微文档，加上有些术语想不到中文的名字， 草案就先用 md 写了英文的）
- 我协作不到位，我写这部分前端接口没提前通知他（事实上一起开会时我不仅说了，还把规划写在白板上了）
对方理由：
- 他也写了这部分 API ，比我的简单很多；我的命名不符合他的规范（这点在 review 前就提醒了，我的出发点是先确定数据结构上有没有分歧，之后命名样式一定会按照他的要求改好）
- 他自称写过很多爬虫，也写过前端（他本职做 AI 算法的，211 硕）
- 不能反映到前端原型的字段上就别加，不要自作聪明以为其他人没想到
- 一年前上司曾批评过我过度设计，效率低
事后也虚心看了下他写的 API ，这里仅以我的视角总结一下他的思路（因保密协议就不贴代码了）：
- 前端页面下一个子组件对应到一个 endpoint ，不再分级，组件全部信息放在一个相同的 JSON schema 里就好
- 根据请求类型，后端自动去 request payload 里找需要的字段用或选择性更新 response body 里的部分字段
- 对于一个组件内部依赖其它组件信息或状态的情况，后端应该在这个组件的 API endpoint 里也提供
- 不假定某个地方需要扩展，不加冗余信息，产品有需求再改，总有办法能在现有接口上承载起新需求（顶多可能会让接口变得奇怪）
下面说一下这部分我的观点（个人职场新人，非 CS 专业，目前也就做做 embedded infra ，这方面可能不专业）：
- 前端原型里部分组件 anti-pattern 的迹象很明显，一个模块里揉合状态信息、配置信息和控制指令，我倾向做 decomposition 拆到该 endpoint 的子路径里做（我很难接受前端把这种模式通过 API 扩散给后端）
- 跨组件的状态信息，前端这边去调用对应的其它 API 处理，我的组件接口只维护生命周期在我模块内的信息
- 在后端仅读 payload 的数据结构上做扩展冗余，及 response 里加一些未来可能用上的信息，不会对前端解析处理增加太多负担（私有 C/S 场景也不必拮据带宽成本）
- 我的模块 leader 限制 C/C++/Rust 实现，一致性和 forward compatibility 比提前出第一阶段 demo 重要，未来有新需求需要调整数据结构或者实现时，改起来熵太高（后端规模远大于前端 / 前端 JS 解 JSON ）
其它的一些想法：
- 在设计和评审产品原型时，从时间和交互维度审视十分重要（这次其实原型就有问题）
- 产品经理几乎完全决定了一个产品的命运，很多时候向前端开发推进，需要先让产品经理认识到这个设计有问题（直接告诉前端要多点工作量可能挨骂）
- 理想主义在职场很难行得通，某种程度上我发展得的比我同事差（比较看 leader 和项目的 context 就是了，这点确实我做得不好）
- 即使我的主张合理，说服了大家做对的事情往往得不到任何好处，分外的事情，让市场和用户差评教产品做事就够了（自由市场也可能首先打我的脸）
- 和人交好很难，这件事看出同事应该是对我有不少意见，但是自己实在想不到哪里得罪了人家（感觉很多时候我已经比较注意了，比如有些会影响到大局的细节问题在评审时我想提一下，但觉得在那么多人的会上说可能不合适，毕竟我不是产品也不是设计，leader 也没开口，也是后面单独找产品旁敲侧击让他意识到有问题）
也想听听大家的建议（比如技术方面或为人处事方面）
嗯，再补充一些细节吧：
-
产品经理能 vibe coding 把原型网页做出来（虽然很粗糙），我模块的原型有问题要改结果一个星期还没改好，于是定接口时同事拿有问题的原型跟我对峙（产品想学习我理解，不过既然项目赶时间，老老实实上个 Figma 或者什么的不好吗）
- 原型里显示一个可能包含几十万个文件的文件夹没有分页，不加排序、过滤和搜索的情况下，期望用户能一下子找到自己想要的文件
- 原型过于简化，将操作/状态隐含在数据对象内，比如用户想临时关闭日程功能，做法是把之前辛辛苦苦写好的日程都删掉
- 同事写的 API 规范中，很多字段应该是谷歌翻译的（概念不合适且有不少拼写错误），以及他开始打算 HTTP 明文传输密码，后面其他人说不安全换成了传密码的 sha256 （不加 salt 和开始有什么区别...)
（应该还有不少，就不浪费社会资源吐槽了）
