文章目录
  1. 1. 一个程序设计的例子
  2. 2. 一个优化办公环境的例子

在错误的设计上做修补,一错再错。

一个程序设计的例子

今天一个设计实例。A 程序提供一个内容管理服务,对外 API 是 get 和 set。B 程序跟 A 程序联调时,B 发现 A 的 set 接口不能解决所有问题。

A 的内容大概是每个 key 里有多项内容,之前的设置是每项内容为一条记录。如 keyA 里 3 条记录:

1
2
3
(keyA, item1) => count1
(keyA, item2) => count2
(keyA, item3) => count3

之前的 get 接口返回为:

1
keyA => (item1, count1;  item2, count2; item3, count3)

之前的 set 接口一次只能设置一个 key 的一个 item ,上边的 keyA 的内容需要调用 3 次 set 接口才能设置好。 这时 B 程序发现 set 接口只能满足给某个 key 添加一个 item 或者修改一个 item ,但是要是删除一个 item 就没法实现了。

今天同学们的设计思路或者是第一反应,一个是增加修改 item 名的接口,一个是增加删除接口。这些思路最终都能实现需求,但是实现的会不优雅。如果对整个需求及之前的设计有个整体把握,就能发现 set 的接口其实可以参照 get 接口。每次 B 程序提供某 key 的全量数据,A 程序直接覆盖全量数据。并且存储里也按这个思路来改。整个的实现及维护成本大大降低。

当然这里有个前提,就是这里的每个 key 的 item 数量是可以预估到不大的,并且总的 key 的数量都不多,存储上和网络通信上都是小意思。

在一个不够好的设计里去修补,与直接重构不够好的设计(并且重构成本不大,即使大,也可以采取小步多次的重构)的对比。前者更像在为一个错误的东西继续错误下去,且导致错误的繁殖成指数趋势。其实这里也是在引申嗅到代码的坏味道及时重构的原因与意义。

走得太远不要忘记为啥出发。

一个优化办公环境的例子

另外最近有个其他事情也是类似这种修补错误的东西,就是公司的会议室外墙玻璃上帖了不能拿下的贴纸。公司的会议室是稀缺资源,抢的挺多。加了贴纸之后,外边排队抢会议室的人老看不见里边会议室有没有人或者是否之前的那波人开完会走了,排队的人就一直络绎不绝的去推开办公室的门一探究竟。排队的人有急会就会好几个门都去推下看看,或者都被占着,就多推几轮。已经使用会议室的人就老被人推门打扰。双方都浪费了精力和注意力。

然后给出了一个方案,在会议室门旁边挂个牌子,牌子两面分别写“推门请进”、“会议中”。让进入会议室的人自觉去翻牌子,且让排队的人自觉看牌子。当时讨论这个方案的时候我就感觉不合适,装逼的话就是用户体验不好,等于让大家多维护个概念及事项,并且保证大家都有心情去遵守。可惜还是开始执行了。

果不其然,基本执行不起来。好几周了,大家开会还是不停的推与被推之中。首先排队的人,因为比较急,有时直接没注意到牌子,或者抱着侥幸心理,“可能是别人出来忘了重置牌子呢”,就推门一看。排到的人进去了,因为都等了好久了,谁还想这去翻牌子为“会议中”。即使没等很久,也基本想不到去弄那个,大家做产品的知道多一个按钮转化率低的事情吧。

我最高记录是一次开了1个小时左右的会被推了不下 20 次的门。不要问我为毛开那么久,因为在开设计评审会。还有个奇妙现象是,中途某位同学误推门之后把牌子修正了,结果后续的其他人照推不误。

这个事情其实就是在修补错误的东西,而没有找根本原因。

透明玻璃上加贴纸,直接按这个透明玻璃失去了意义,变成了砖墙一样。把会议室的默认属性变成了围墙里的秘密。但是真的需要那么多秘密会议室吗,不见得吧。我们不是特务机关啊,没有那么多见不得人的;我们不是大公司啊,没那么多偷懒扯皮会议啊;我们也不是苹果公司啊,没那么多商业机密啊……

目前我能想到的我们公司需要相对私密空间的会议就是面试、谈 Offer、发奖金什么的、接待合作伙伴之类的。可以看到这些需求其实不大的,我们一方面可以定几个小会议室做成这样,或者每个会议室都弄成加窗帘的方式,平时默认透明玻璃,方便大家查看,也寓意开放。等什么会议必须私密空间,再把窗帘放下来。

另外有人可能会说窗帘这个东西的升降也需要操作,估计大家降下来都懒的升上下。但这个毕竟是少数,每天找行政晚上去搞一遍或者旁边同学轮班巡查下就行了。另外如果有财力支持,可以弄成那种电动遥控的,这种我在《24 小时》里看到过小强杰克用过。

这些东西说不定能给大家个启发,我的一定不是最好的办法。

文章目录
  1. 1. 一个程序设计的例子
  2. 2. 一个优化办公环境的例子