技术文档
阅读理解
下图来自某平台的技术对接文档，请重点看一下红线的含义。
刷新token的场景说明：
请大家理解一下，红线处的场景到底想表达什么？
文档中说的在 access_token 过期 1h 之内 是指token过期前1h之内？还是token过期后1h之内？
我们团队同学开始的理解是：token过期后1h之内。
（从正常人的阅读感受来说确实是这样的）
实际情况
但是我在接手这部分逻辑的时候感觉不对。
因为我当时并没有读这个对接文档，而是站在正常刷新token的角度去考虑：
如果让我来设计服务端无感刷新token，我的设计思路是：在token过期前1小时支持通过refresh_token来刷新token。
尤其是当我看到这段之前的代码逻辑时，感觉非常不科学。
（为了方便理解，用伪代码给大家演示）
if 过期时间 > 当前时间 - 1小时 { 返回cache中的token }else{ 刷新token的方法 }
比如：过期时间是4点，当前时间是4点半，正常来讲token过期了的；但是按照上面的逻辑：当前时间 - 1小时。4点半就变成了3点半，满足返回cache中token的条件。
显然这种处理方式是不对的，违反常识。
沟通
经过一番沟通确定之后，果然，文档中说的在 access_token 过期 1h 之内是指token过期前1h之内。
哎，这种文档真是坑人啊。
总结
写文档和写注释一定要想清楚，别坑队友。写的模棱两可还不如不写。
对接三方沟通非常重要，当有疑问的时候马上去沟通，不要迟疑。
需求拆解
背景
最近做的工作都没有明确的需求，都是参考之前的代码逻辑，实现新渠道商的对接，导致踩了不少坑。
碰到这种没有明确需求的工作怎么推进呢？
我的踩坑总结
- 需求拆解，尽量把需求拆的足够细，以方便评估时间，挖掘出深层次的需求
- 明确责任边界，比如碰到和本次需求没有直接关系，但是影响自己开发的bug，一定要及时沟通，尽量让bug的责任人去处理；而不是自己大包大揽都干了。
- 及时反馈进度，当做这种需求时，领导大概率也是没想清楚的，所以不知道真正的工作量，更没有一个明确的完成时间的deadline，这种情况下及时沟通进度非常重要。尤其是当意识到可能在规定时间内无法完成，一定要提前告知。
