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