关于最近经常加班的自我反思
背景
今天晚上8点左右，老大突然问我，你怎么还没走？我也楞了一下，我怎么还没走，回来之后决定复盘一下。
经过
早上9点我就来了，梳理了一下上周的工作内容，想给这周计划理一下，突然发现我并不知道去哪看排期，没有一个确切的清晰的文档，所以我花了一部分时间去找合适的项目进度管理文档工具，整了一个模板。
等到10点15分人才齐活儿开周会，才拍定原本预定的大版本前面还有一个小版本。考虑到小版本接口差不多了，上完马上就是大版本，后台可以先了解一下大版本，避免我做到这里没接口可用，所以通知到后台，结果后台说要再拉一个评审会，这就拖到下午了。一上午就写了个周计划开了个会，好消息是下次进度管理就有模板了，更清晰了。
下午根据上午分工，给同事讲解了实现思路和利益相关方，因为小版本是急活儿，我本来分的是unity相关的业务，担心同事做不完，也怕她代码写的急而忽略质量，所以我决定分担已经有设计思路的一部分。下午的评审会其实核心是后端对于其他项目组已有功能是否能在我们项目进行复现的评估，前端这边其实无非就是调能调用的接口和UI实现，唯一难的可能还是实现unity的底层封装这块，最后会开了1个多小时，来了几波不同项目组的又走了几波，结论是产品那边与AI那边底层支撑的负责人再进行确认。
我开始实现限时免费，发现切图没有区分双语，而且设计稿78px给我300倍的780多k的一个文件，想了一下懒得找他改了，沟通又得绕一圈。我自己P了一下，又压缩了一下，算是能用了。
实现代码过程中因为强迫症，发现代码中有些地方用的Diamond但是有些地方从后台拿的数据又叫JE，优惠券前端定义叫Coupons但是服务又叫MSS，这样新人进来很容易看不懂，业务理解混乱，很多地方的命名全部都不统一，实在恶心，又花了1h重构这部分，并且抽象了一个底层余额的组件和查询方法，对之前代码稍微做了优化，以后所有余额的样式和判断都可以集中控制。
终于有空做限时免费了，写了一个还不错的底层组件，单独控制限时免费的判断逻辑和样式，位置支持定制，不管什么场景都可以直接用这个组件，写完这就晚饭了
写完接接口发现上周@后台接的字段，忙得忘记接了。
根据原型做AIGC限免，发现后台接口没这个字段，找后台问原因说他的上级只告诉他做商品的限时，技能不算商品。于是又找产品确认，最终砍了。
实现了两种场景下的限免，调整了一下UI。做测试和样式调整，补了一个时间时区转换函数。这就晚上9点了，想把后面的写完发现接口又没字段。
总结
周末总结制定下周计划
项目进度管理文档，相应功能@利益相关方
涉及多方的评审，核心其实是底层是否支持，中间层和应用层无非工作量和工作时长评估了
评审前其实各方都应该提前熟悉一下需求文档和原型，列出自己的利益相关点并会上逐一提问，不然临时的思考不够冷静、全面和准确
队友靠谱会省掉很多事情。组内需要做技术分享，统一技术栈、工具和业务认知，每天下班前留30分钟互相讲解当天工作和业务，避免彼此不熟悉导致出问题只有当事人能改。
UI如果有空最好是能制订一套交付规范
强迫症得改，最好是在写新代码的时候就想好思路，抽象好底层再写，避免后续的优化
后端，尤其是底层后端，改了什么字段或者写了什么东西，必须@产品实现信息的同步
因为限时免费的需求是上周四左右提出的，当时并没有梳理场景和接口，所以最后部分接口没字段，还是前期评审想少了，流程没有串起来，需要时序图对于各个场景的数据流做梳理再做的