unbinilium

@iseki 很准确的定位，谁写中间件是核心矛盾，也确实没有第三方来做。

另外一方面是我希望通过产品精细化原型定义来消除部分和前端之间的建模误差，这一步虽得到认可，但是进度缓慢，开发受到阻碍。

所以着急的话大概率还是得麻烦领导决策。

技术方面的话主要是觉得我在这方面缺乏体系，寻建议不是为了定夺谁好谁坏，想看看其他人在这方面有没有书籍或项目推荐。

@GuangXiN 嗯，我实际情况感觉是更适合混合模式做，初期决定先试试贴近页面的方案

@zacard 啊，我的问题，忘说了… 英文版对方没看，当时 review 的是我这边重新在他企业微信文档里补充的中文版，命名样式没来得及改成他定的规范，提前也说是主要看结构，样式尽快改好（我工作日常 linux ，企微跑在 qemu 里面确实不太好用）

拼写语法这些都是小问题，我从没提过，这里提一嘴是因为讨论时对方先批评了我，以及后面我理解他的文档十分费解。

@a33291 嗯，是有一点。当时临时 review 双方应该也是没想好，对面找我问题，我应该是没把我这边的设计思路用语言很好地传达给对方，表达能力还是太重要了。

@rabbbit 嗯，我确实复杂化了。

不过我上面还有一层意思是，冗余设计覆盖到了我能想到的产品那边的未来需求：比如之后储存组件需求变化，大概率后端不需要任何调整（ e.g. 加个进度条，增删合并分区，安全弹出之类的），只是前端来调整对后端接口的使用就好。

不过反思了下我这种冗余设计确实不妥，相当于把 OS 的接口间接暴露给前端了，还是应该先等原型改完再定。

@fregie 这点其实我也是认同对方的，这样双方都轻松一些，后面开会对的时候明确好责任就好，有时候把事情简单化更难。

@rabbbit 是的，这是第一个分歧点，我比较 RESTful ，endpoint 想做成 `/{组件}/{功能}`

第二个分歧点在 payload 部分，比如一个划定时间段的日程组件（`.../schedule`），对方倾向平铺 `{"monday":[{...},...],"tuesday":[...],...}`, 我是倾向规则化 `{"weekly":[{...},...],"exceptions":[...],...}`

以上两个分歧延伸到了其他接口上，再举个例子就是磁盘管理组件：

- 显示当前可用的磁盘、每个磁盘的状态
- 用户对磁盘的配置（配额、清理策略等）
- 用户执行的操作等（挂载、格式化等）

由于上面几点在原型里比较模糊，产品迟迟没有给出确定的需求，我就自己打了个草稿：

- 按功能把 endpoint 分了两级
- response body 按磁盘->分区做了结构化的组合，然后加了一些冗余字段
- 比如状态机区分：错误/格式化中/未挂载/正常/同步中/索引中
- 状态机的冗余属性：格式化中状态下代表格式化进度（类型不变）
- revision：用于将状态机与用户行为同步，比如用户请求格式化，重命名等（ POST 非幂等）
- 其他冗余字段如当前分区格式等...

可能对比现有的原型确实复杂了点，之前确实也没这方面的项目经验

@CivAx 谢谢，我等 workday 先电话过去问问再决定要不要麻烦您吧。方便的话也可先加个好友 V2VDaGF0IElEOiBVbmJpbmlsaXVt

@Lintech 试了移动香港，visa/amex 两张外币卡都不让 Pickup ，去年首发、期间买配件 Pickup 都没问题，只能先问问客服了

@MacsedProtoss 不太像，据观察 19-20 号从昨天到今天可用的时间窗一直在减少，目前 20-21 还有大量的时间窗能 Pickup ，昨晚和今天我都试了好几次，确认过被拒绝后原来的时间窗还是能 Pickup 的