Gitbook Auto Published

SUMMARY.md

@@ -5,6 +5,7 @@
   - [产品设计](design/product.md)
   - [系统架构](design/architecture.md)
   - [系统实践](design/system.md)
+  - [忽略细节，就是屎](design/shit.md)
 - [项目](project/README.md)
   - [结构](project/structure.md)
     - [HAPI](project/source/hapi.md)

design/shit.md

@@ -0,0 +1,43 @@
+# 忽略细节，就是屎
+
+比如登录表单，输入密码后按回车键一点反应都没有，必须点击登录按钮才能登录。
+
+## 开发忽略细节，代码一坨屎；设计忽略细节，产品一坨屎。
+
+举个稍微复杂点的例子，`消息列表`这个功能模块。
+
+假设有两个需求：
+
+1. 允许用户下拉操作刷新（手动）
+2. 每隔15s后台请求刷新（自动）
+
+如果处理不当，会出现漏消息、消息重复等情况。
+
+所有开发环节出现的屎，都能追溯到设计环节。从设计环节就需要考虑好如何规避这些问题的发生。
+
+实践：
+
+### 0. 消息表说明
+
+在数据库设计章节提到了避免使用自增id。
+
+所以就不能将消息id作为参数传递去查询，而采用时间戳的方式。
+
+### 1. 参数带入时间戳
+
+时间戳的选取：
+
+1. 本次请求发起的时间 -> 下次请求可能会重复本次请求处理期间的消息
+2. 本次请求结束的时间 -> 下次请求可能会丢失本次请求处理期间的消息
+3. 最后一条消息记录的时间 -> 完美衔接，最佳选择
+
+### 2. 阻止请求
+
+如用户狂点导致的频繁刷新，或者用户手动刷新和自动刷新同时进行，都会导致获得到重复消息数据。
+
+先进先出。前一条请求处理完成前，阻止下一条请求。
+
+### 3. 时间戳的有效性
+
+1. 如果返回的结果有数据，时间戳应当被更新替换掉
+2. 如果返回的结果没有数据，下次请求依然使用该时间戳