前情提要
最近换了 Manager, 发现他还是有很多地方可以学习的. 于是准备写个帖子记录一下, 同时也提醒自己之后遇到相似的情况该怎么处理.
关于文档建设
之前的 Manager 我觉得最大的问题就是只看重文档的数量, 并没有说明文档的意义. 大部分情况下, 虽然冠冕堂皇的话就是写了文档方便其他人查阅减少新人 Onboard 的难度, 同时也能防止组内出现 Single Point Failure. 但实际上, 文档的作用就是在外组人提出问题时, 有个 WIKI Link 能甩过去减少大家的时间. 新 Manager 的做法就很有条理性, 比如他会要求在每个特定的领域提高文档. 比如, 如果有新的 feature work, 那么 pm design spec 要有一个文档, dev design spec 要有一个文档, 同时还要建立 Dashboard Telemetry 的文档, 并且对应的 Alert 也需要有 Battle Card 来方便 OCE 具体查询相应的问题. 这算是一个技巧, 文档首先要确保每一个部分能 cover, 其次在进行扩充.
- PM Spec
- Dev Spec
- Telemtry Dashboard Spec
- Alert Battle Card
所以之后组里的文档就会按照这个来进行规整, 而不是按照之前的乱写一通, 或者是新旧混杂.
关于项目安排
首先新的 Manager 会希望我们能够把所有的情况都能考虑到, 并且能以文档的形式保存下来, 并且 Involve 更多的 Team, 他的看法是这样能够有足够多的眼睛来审查可能出现的问题. 同时, 他会要求所有的 TimeLine 和 Cost Estimation 需要在和他沟通之后才能给出去, 即使是和 PM 讨论过程中, PM 会询问某些特定的 Feature 该怎么取舍, 希望得到 Dev 的确认时. Manager 更希望 PM 给出尽可能多的 Options, 然后我们根据 Options 来进行 Cost Estimation 然后选择更优解, 而不是 Dev 和 PM 先行沟通, 然后确定执行方案, 最后由 EM 给出时间.
关于 API Design 的几点建议
- 对于有时效性的数据, 在返回数据的同时, 最好能够带上版本号. 实际上我们的系统中有两种数据类型, 一种是 Log 类数据, 比如订单, 当你完成之后, 就不会进行修改, 比如 过去半年你的订单详情, 这种类型的数据是不会改变的, 所以没有必要返回版本号. 还有一种数据类型是计算的, 比如说过去一年你的团队内的合作时间. 为什么改变呢, 首先我们对数据的计算过程本身可能存在 Bug, 当 Bug 修复之后, 生成的数据可能会改变. 同时在过去的一年中, 你团队中也会存在人员变动, 可能是离入职, 也可能是失去了某些 Licenses. 像这种数据也就是我们系统中主要存在的, 考虑到用户可能会出现前后两次访问不同版本数据的问题, 我们比较好的返回版本信息, 前端可能不使用, 但是当我们需要给用户展示错误信息或者用户有疑惑的时候, 我们也能快速的定位是版本变化, 而不是出现了 bug.
- 使用 Status 来反应出现的问题, 而不是 boolean 值. 这其实是一个 Coding Style 的问题, 我们因为 Legacy 的原因, 有很多的错误或者说状态是通过 boolean 值来表示的, 比如 AreXXXAvailble, IsExceedMaxValue 等等, 这样就造成了一个问题, 就是永无止境的添加 boolean 值来实现某一个特定的 Error Case. 所以新的方式就是使用 Status 一个 String Type 的值 (也可以是 Enum Value) 来说明具体遇到了什么原因.
目前就这些, 等接下来再补充吧.