说到就近原则,想必大家都不陌生,在生活中我们经常使用。
午饭叫外货,可以根据店家距离选择,距离近的送货比较准时,甚至可以提前送到。
下班购物,更有可能选择回家路上的商场。这个就近原则,是物理距离上的近。
网页中的CSS样式文件,如果有多个样式约束,比如字体大小的控制。一个全局的样式文件,一个局部的样式文件,还有一个写在页面元素上的字体大小。那么哪个样式会起作用呢?当然是写在页面元素上的字体大小在起作用,还有一个前提要写对。
前几天新增的业务逻辑,又让我想到了就近原则。
新增的业务逻辑是这样的,新增两个开关,一个在用户设置里,一个在用户的好友设置里。开关打开的时候,某个页面元素展示。开关关闭的时候,那个页面元素不展示。
我把数据库的表结构调整了一下,便把任务分配给开发A。A编码了一半,跑过来问:“用户设置里新加的开关是控制全局的呢?还是控制...”
“用户设置里的开关是控制全局的”,突然觉得不对,如果控制全局的,那影响太大了,于是改口道:“不对,用户设置里的开关是针对陌生人搜索用的。用户的好友里的开关只针对这一个好友的。”
“好的”,A回去继续编码。A编码完,把这两个字段的控制范围作为备注加到了任务日志里。
没多久,便看见产品助理B一路小跑到A的座位旁,拉着A讨论着什么,声音太小,不知道说了啥,又引出了什么不确定因素吗?
这时,产品经理C从他们的座位旁走过。
B拦住C便问:“昨天讨论的用户设置里的开关是不是全局的?用户设置里的开关一有变更,用户好友里的设置也被改变了?”
“那个呀”,C停顿了一下,“用户设置里的开关,只对新加的好友起作用...”
“我认为应该是全局的,也对好友起作用!”,B很坚定地说。
“一关全关,一开全开?”,C一脸疑惑的样子。
“不是的,用户设置里的开关虽然改变,但用户好友的那个开关状态会保持。也就是说,用户设置里的开关开了,并且用户好友里的设置也开了,这个页面元素才展示。用户设置开关关了,好友里的开关保持不变,但页面元素不展示!”,B一口气说完她心里的逻辑。
“那样也行吧”,C开始妥协。B开始和A解释想要的效果。
“用户设置对好友是不可见的,对好友的设置是保存在用户的好友表的。而用户的好友信息是缓存在客户端的。要么没有关系,要么一改全改。用户的好友表里的开关状态想保持,不好保存呀?”,B还没有开始说,我便插了嘴。
“那就用老板说的策略吧”,B听了我的话后,立马改变策略。
“以前不是有这样的设置吗?”,C皱着眉头反问道。
“这种情况的设置还是第一个”,我和B异口同声。
“我开会不是说了这个规则吗?”,C还是满脸疑惑。
“你也就和我一个人说了吧?”,B抛给产品经理一个白眼。
“我们三个人有三个理解,加上你一共四个理解...”,我轻描淡写,我们的产品经理加老板什么时候才能不拍屁股决定一个业务逻辑呢。
“好吧,以后我要拿个大喇叭喊了”,老板笑着走开。
我们又各自干起各自的活来。、
UML图假设这个开关就叫做标签开关,用来设置自己的标签对于外部是否展示的。这个外部包含三个部分:
- 陌生人搜索到用户的时候,标签是否展示;
- 陌生人添加用户时,标签是否展示;
- 已经加过的好友,标签是否展示。
当然,用户的好友表,也有同样的一个标签开关,这和用户设置里的标签开关是不是冲突了呢?从表面上看是冲突的。用户设置里的标签开关有变更的时候,用户好友表的标签是否也需要变更呢?这也是A的疑惑。先来分析一下3种方案:
- 用户设置表的标签开关,与用户好友表的标签开关,保持同步;
- 用户设置表的标签开关,与用户好友表的标签开关,互不影响;
2.1 用户设置表的标签开关只针对陌生人;
2.2 用户设置表的标签开关只针对陌生人和新加好友;
第1种,用户设置表一有变更,就需要通知所有的好友,改动太大。
第2种情况,用户设置表的标签开关,只在陌生人检索到用户的时候,才根据开关判断是否展示标签,影响比较小。这种情况也是我一开始所想。
第3种情况,在第2种情况的基础上,再增加一种情况,被加好友时,把标签开关也同步过去,只针对这一个好友,影响也比较小。这种情况也是产品经理C想要的效果。
用户设置属于用户的隐私设置,对于好友是不可见的。用户好友里的设置,对好友是可见的。用户好友里的标签开关,一有变更,就通知到对方的好友表里,缓存在本地。而用户设置,则只针对陌生人和相加的好友。这便是功能上的就近原则。
除了功能上的就近原则。我还想起了项目中的配置文件,配置文件也是有优先级和远近距离的。如果有多处重复配置,那么哪个配置最后读取或优先级最高,则使用哪个配置文件,这也是就近原则。有时候我们修改了配置文件,但是没有效果,就是因为我们修改的配置文件不是最近的配置文件。
网友评论