任务开发检讨

我理想的情况是，

事前planing好API(req、res)，完成每只api估时，妥善把开发过程分配在每周

API 开发，采开完就交付，交棒FE串接，让PM达成在预期时间，可以测试预期功能

事实情况是

BE开发前置时间耗时过久(建立entity、开module、建立DB)、需求变更与讨论(异动DB schema level )、BE开发意外情况（技术研究(GoogleStorage)、需求意外地无法达成）、逻辑规划不完全等因素，导致

1. api 虽然准时交付、但是品质不佳、规格不清，提升FE的沟通成本(确认用法、错误回报)
2. 自身程序码杂乱不彰，易读性差、严谨度不够

针对以上情况，我采取措施

1. 以准时交付约定的API 为原则，完成度70%就可先上，至少让FE可以先接、先测
2. 阻碍夥伴开发的问题，优先解决
3. api 错误回报、需求变更，订定优先度，利用当周完成进度的 buffer time 进行处理
4. 需求变更部分，另外开卡纪录变更，也另外估时，便於回顾时检视是否可以优化部分

这次做得好的部分

1. api 都有如期交付
2. 任务优先度安排，以交付api 优先，错误处理、需求异动次之

这次做得差的部分

1. 重要文件缺乏完整性，让文件使用者不易理解、取得必要资讯
2. 交付api 品质不佳、程序码杂乱，需要再花时间修整

如果再来一次，我可以怎麽样做得更好（交付品质好API \ 去除不必要沟通成本）?

1. 优先产出 API DOC
   1. swagger 用来提供完整的 api 串接（url \ req \ res \ error Exception \ 参数使用方式 ）
   2. google doc 用来给FE report api bug 、error 、栏位异动告知，於上版後淘汰
2. api 逻辑plaining 时候，应该再更细致（api 资料流的flow \ 例外处理 \ 需要储存的栏位 ）
3. plaining 时候，应该包含 module 架构、预计会产生的 dto 、enum 、config ，盘查哪些可能後续有效能问题
4. 尽可能盘点所需之范例资源（要开权限的名单、资料汇出汇入格式、档案上传范例档案、需分析栏位）