对于开发而言，编写代码只是一小部分工作，而这部分时间往往不会是最低效的环节。结合最近的跨部门合作经历，发现可以写一篇文章，总结一下如何实践低效率开发，主要是编码之外的。
热情但是不够周到的后端同学
这次合作下来，感觉后端同学真的是非常辛苦，加班的情况很多。考虑到高强度工作对人的种种压力，我可以理解在这个强度的工作下，一些地方会做的不够不周到。但是如果这些对前端来说很敏感的地方能做好，形成共识，形成SOP，对团队整体开发效率肯定是有很大帮助的。
由于前端开发往往需要依赖后端接口，因此后端如果不够给力，也会导致前端需要做很多额外的工作，比如自己mock数据。有一些数据接口定义上是比较结构化语义化，是比较好mock的。但有些数据确实很难mock，比如丢入echarts的一些数据，后端给的结构可能就是{Key:string;Items:{Key:string;Value:string}[]}，这种格式前端很难去mock。
不够周到的接口
现在基本上招聘前端的JD里都有提到，前端需要了解服务端开发，需要和后端共同制定接口。以及，需要有最少一门服务端语言的开发经验，这都是为了前后端可以进行良好的配合。
然而我不确定后端的JD，是否要求具备通过UI稿，了解并确定开发什么接口的能力。
在比较有默契的团队里，后端同学可以充分了解需求详情的，对UI稿也有一定理解能力，能在接口文档第一次给出时，就考虑到各种交互，不需要前端给出很多改进意见。
我也遇到过很多在这方面不够周到的行为：
接口文档不写注释
遇到过一些后端同学写接口文档不爱写注释，只有在前端的要求下才写。
当后端同学告诉前端同学接口文档完成时，应该拿出一个基本挑不出什么毛病的文档，不然又是后续的反复沟通，耗时耗力。
写注释会增加一些工作量，但这个工作量是必要的，是可以降低后续沟通成本的，以及让后续的迭代有迹可循，也能给前端同学更靠谱的职业印象。
接口文档不写枚举值
接口类型定义了string类型，但是前端同学并不知道要传递什么信息过去，接口文档也没有任何说明。这样的模棱两可，让前端同学不知所措。
接口缺字段
有些后端同学会去看一下设计稿，但是只定义了第一眼能看的到的字段。一些字段比如ID就不给前端了。但是ID对于编辑和批量操作，确实十分必要的。
查询条件缺参数也比较常见，以及一些查询条件UI稿规定需要用下拉框选择，后端也没有给出相关的枚举值。
缺接口
页面中存在批量开关、功能开关这些，这些按钮比较小，容易被忽略掉。但如果更上心一些，每个按钮其实都代表了一个action，往往需要格外关注。
挤牙膏式更新
当前端同学提出改进意见后，不能一次性更新接口文档。而是每天更新一个两个，导致每天都需要确定还剩余接口的进度。
充满自信，但不可靠的时间承诺
好啦！但是你还不能用！
“这个接口好了！”
看到后端发这句话，还是会有点欣喜吧？我马上去刷新页面开始联调，发现依然是报错。
再次询问，才得知。“这个接口我已经发了，还在跑流水噢”
我很无语哇。类似的情况我会这样表达“这个部分我已经更新了，正在跑流水，大概5分钟之后可以刷新~”
好啦！但是你还不能用！（版本2）
尽管我对“好啦”开始免疫，但还是去刷新了一下页面。发现接口的报错从404变成了一串长长的英文语句。接口确实是发布上去了，但是没办法用。因为后端同学没有对接口进行自测。
于是我只能再次沟通这个情况。
经过了N个小时之后，接近晚上12点，终于可以开始跑了。但接口的一些参数下，依然无法使用。
你以为的今天，其实是第二天的开始
通常大家说的今天搞完，应该是今天的晚上6-7点弄完吧，或者考虑到IT行业性质，晚上8-9点前也行。就算这个点大家还没下班，那如果是依赖你工作的同学需要你今天给到，也还需要时间开展后续的工作，应该也不是说晚上12点给。如果真的是晚上12点才能做完，那和第二天早上给也没太多区别。
没风险≠不用担心
每次进度同步例会开完，同步后基本DDL前没有风险。
但我还是有点担心。因为每次需要后端接口时，总是比预期晚。总担心接口给不到，结果逾期做不完了。周末早上起来，坐在电脑前，一遍遍的刷着飞书，等消息，或者主动去催促，以及反复刷着前端代码，看看还有哪些部分可以不依赖后端接口数据先做的。或者后端接口给出来1-2个之后，我还有哪些功能是可以局部调试的。感觉自己这几天和一个轮询函数一样，也很辛苦。虽然轮询函数很多时候在空等待，但也没办法关掉这个函数，只能继续占用资源。
手足无措的前端同学
提升人效的指标
公司对于研发的人效是有要求的，这个指标会落到一些同事的身上。
因此很可能就是你原先工作的好好地，需要对你的开发流程做改动。本来人虽然快累死了，但是还能按照过往的路径去开发联调发版上线。但是一下自己让你用新的技术，新的组件库，你发现还得去看新的操蛋的技术文档，为数不多的一点确定性和舒适圈都被打破，一下子，情绪崩溃了。
对于长期而言，使用新技术或封装良好的组件库，可以提升人效。但是短期而言，一切不利因素叠加下，就很容易崩溃。
接口变更后，被埋藏的bug
接口频繁变更，前端也得配合变更，就很容易导致一些数据前端遗漏了更新。可能改一改ts不报错了，自以为万事大吉，结果被后端同学发现操作失败是因为前端传参异常。非数据类型的错误其实不好找，前后端都不会给出任何报错，只是你发现这个接口似乎行为不太正常。
这个问题虽然“简单”，但也可以闹得很大。让前后端一起找bug，浪费开发时间。
各自为政的大前端部门
我所接触的大前端部门，虽然人数不少，但是每个人都铺在不同的项目上，没有更大程度的发挥出大前端部门的威力。问题如下：
- 不同项目的UI设计规范不够统一，导致每个项目都有一定的重复开发量
- 虽然有组件库，但因为UI设计的大幅变动，导致组件库无法满足新的设计需求，只能重做
最好的解决方案是UI规范的统一，是落实在具体的前端组件上的。不同项目如果要用到这个能力，就用统一的前端组件。前端项目变成拼积木一样，通过组合变成不同的页面，降低新开发量。
充满挑战的跨部门、跨地域合作
成倍增长的会议时长
假设你一个软件的开发周期是2个月，需要10个人力。那把人力增加到20个，就能1个月开发完成？《人月神话》这本经典著作很明确的告诉你，不太可能。因为沟通成本、培训成本，导致增加人力甚至有可能延长开发时间。
经过这一次跨部门、跨地域合作，我的感受更加清晰了。我们这次开发所有同事分散在北京、深圳的不同大厦内，纯线上协作。因为是初次协作，哪怕有协作工具的帮助，在很多方面也存在鸿沟。目标、预期、标准的定义对齐，还有工作进度的同步。
这些沟通成本会变成一个接一个的飞书会议，大量占据你的工作时间。
有时候我在想，一个60分钟的会议，只有5分钟的内容和我有关，但我也不是很敢下线。因为我对目前的情况其实不够了解，担心错过了什么比较重要的内容。所以只能让我剩余的55分钟都成为不错过重要信息的成本。这种情况并不少。
日益复杂的软件系统
另一个前端同学和这个部门已经合作2年多时间，哪怕对方不给接口文档，他也能完成前端开发，等联调。但听起来目前的这套系统，在多个环境有部署，会比较复杂。所以联调中也往往会遇到各种坑。
最简单的前后端联调就是前端直连后端ip或域名进行联调。但是目前的系统需要走火山的top网关，然后再header内传参，让流量分发到背后的某个集群内。因此前端需要安装浏览器插件做header的重写。以及存在很多潜在问题：
- 没有注册top网关，导致接口404
- 没有部署成功，接口实际不存在
- 前后端配置不正确，导致流量没有打到目标集群
以及一些接口文档，几十个字段的响应值，看得我一种压迫感就上来了。对后端来说也很难受，太耦合了。
结语，一点经验，一点不一样的体验
系统性的问题
在公司里，我还没认识几位同事是不努力的，是不好好干活的。但有时候，协作体验还是不够好，还是有很多优化空间。我也入行不算很久，没有十足的自信说自己十几年经验，可以明确的说有什么办法指导团队进行高效开发，只是在我的角色，确实也发现了问题。
失败的反义词是成功，但失败的反例并不一定代表成功，失败的反例也许是另一种失败。
所以，我取名，如何在工作中实践低效率开发，这是我感受最实际的。
想起来一些书，或者文章，会提到一个有点高端的说法“没有银弹”。有些事情，是世界性难题，而我所遇到的，只是这个难题在我工作中的呈现。团队管理，软件设计，人员管理，排期管理，或者各种吧，总之问题还是蛮系统性的。但是任何一个环节的改善，都有可能对这个系统进行优化，运行的更轻松。
身处泥潭，做出不同的选择
相同的处境，也可以做出不同的选择。遇到问题，不等待救世主的出现，而是主动解决。
比如制定并执行更清晰可检查的工作标准，在团队内推动共识。比如：
后端工作标准
接口文档交付标准
- 接口制定已参考实际UI稿，数量上不缺不重。
- 根据UI稿实际查询能力，设计接口查询条件
- 设计接口时，已考虑满足按钮、开关等交互
- 设计接口时，能够满足新增与编辑表单的能力。如果有编辑功能，需要考虑如何将被编辑的参数传递给前端。
- 针对编辑功能
- 考虑对接人员默契程度，补齐接口注释、枚举值。
- 对接口文档质量有较大把握后，邀请前端验收，没有过多需要修改的问题。
- 对于参数构造相当复杂的接口，可以在前端主导下，提前构造好实际请求参数给前端，避免后续沟通成本。
联调前接口ready标准
- 联调之前，首先通过Postman进行自测，在传递最基础参数的情况下，确保能够跑通。（最基础参数比如page、pageSize这种）如果时间紧张，在完成基础自测后，通知前端“接口已完成基本自测，上线至boe”。
- 如果有充足的时间，多传入几组参数自测。
接口变更标准
- 接口文档变更，为避免误解，通知前端“xx接口的文档已更新，更新在xx平台上”
- 接口发布，为避免误解，需要提示比如“接口我已经修改完，刚才在发布了，大概等5分钟就好”，“接口已经发布上去了，现在可以刷新看看”
- 如果有多处接口需要更新，在当日一次性完成更新后同步，避免多次同步产生的其他问题。
- 当晚9点前能完成的接口变更，当天通知前端，前端根据情况及时联调。11点后的变更第二天早上通知。
（由于篇幅限制与个人角色局限性，比较难制定更满足后端需求的前端工作标准。）
多一点感同身受，多一点理解
我之前一直不理解，每天工作到晚上10-11点是什么感觉。毕竟在我眼里看来，大家支持的不都是1-2个平台么，怎么会要那么多时间呢。不过经过这次跨部门合作，我又理解了很多事情。
看似相同的事情，其实可以因为很多变量，导致工期差很多。
- 新支持的项目，因为需要了解上下文，所以很难一下子就大施拳脚，初期效率会很低。
- 有专业UI规范的项目，在标准组件库之上还需要做很多改造，往往需要3-5倍的开发周期。
- 跨部门合作的项目因为要把信息同步给很多人，所以会议会更多更长。排到晚上10点也是不奇怪。
- 职责范围的差异，如果你的前置依赖都做好了给你，不需要去催促去对齐，也省事很多。
所以我现在很理解我的一些同事，为啥会陷入无止境加班的泥潭。事情很多一方面，工作流程的优化没有精力推动也是一方面，以及还有一些其他原因。
我目前所在的部门，由我完全负责前端开发与交互设计，所以我很清楚怎样的UI设计对我来说是既省时省力，也能对得起观众。总之，我算是弄出来了开发体验友好与用户体验友好平衡的界面。所以可以腾出很多时间来做后端开发和学习。以至于之前也有小伙伴评论我，说全栈之后事情会越来越多之类的，对我来说，倒也还好，不同部门真的差别很大哇。
其他的碎碎念
不同部门的工作感受的差异真大，如果有机会跨部门合作，哪怕会发生很多更辛苦的事情，还是值得的。都可以丰富我们的工作履历与共情能力。经历了其他同事的事情，对他们遇到的问题与困难，有了更深刻的理解，这是好事。
还有一些同事负责多个部门的人力与开发进度协调与管理，这个岗位对人能力的提升也很大，也有很多事情是可以去做，去推动的。因为接触的部门多，对于一些技术方案的通用性提升，以及复杂性的认知，都会好很多。
