❏ 站外平台:

软件开发的硬约束

作者: 乱象,印迹

| 2015-02-19 22:17   评论: 21 收藏: 2 分享: 29    

在超市结帐的时候,收银员都会给我们打一张小票。有时候同样的商品我们会买两三件,打印在小票上面,有时候只有1行记录,数量是3(“听装百事可乐 x3”),但也有时候有3行记录,数量都是1(“听装百事可乐 x1” 重复3行)。这个现象很有意思,為什麼不统一呢?而且据我观察,后一种情况明显更多。分明是前一种做法更节省纸张,为什么更少采用呢?

我曾经设想,是因为收银的机器性能太差,内存很少,只能维护简单的数组结构,不能维护集合,也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现,这个说法站不住脚——现代的收银机性能足够很好了,甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢?就在我百思不得其解之际,一个偶然的机会解开了我的疑惑。

当时,我们要开发一套收货管理系统。为了节省纸张,也为了追求“程序的美”,我决定选择了“单行多件记录”的做法,也就是“1行记录,数量为3”,因为硬件的性能是绰绰有余的。程序开发完成之后,测试完全没有问题,一切非常顺利。但是实际应用之后,仓库的同事却对这点非常不满意,强烈要求每一行只对应一件货物,多件同样货物就必须有多条记录。好嘛,正好有机会看看原因何在了。

到实地一看,我瞬间就明白了,多件商品归到一行记录有什么问题。首先,大家已经习惯了拿一件货扫描一次,对应的清单上就需要打印一行记录,以确认扫描完成。当然我们可以说,用别的方式提示也可以,比如屏幕闪动,或者发出声音。但是,扫描生成的清单,还会被下一道工序的员工使用。对着清单处理货物时,他当然希望每点一件货,就直接从清单上划掉一行;如果这一行对应着超过一件商品,他就只能在旁边写“正”字来计数,效率自然大大降低(如果你仔细观察饭店服务员的上菜过程,也会发现这点,只是很少有人会把某个菜点两份)。

(题图来自 aggrandizesolutions.com)

这点发现对我的触动很大。大概因为我长期以来做的都是“纯”软件产品,所以虽然也要考虑划分边界,区隔责任,设计架构,但这些都是“软”的,没有什么“硬”的约束:一项功能、一种责任放在这里还是那里,固然有架构的考虑,但如果实在要修改,通常也不会有太大的问题,所以即便只从逻辑和美的角度来考虑也没有什么问题。最典型的消息传递,既可以用“推”也可以用“拉”,一般场景下都不会有大的区别。但是,现实世界里的很多问题就不是这样简单了。限于设备和场景,某些时候就只能“拉”不能“推”。比如某些移动设备会受到功耗的限制,所以“推”当然好于“拉”。如在这样的“硬”限制面前,如果我们只把自己关在办公室里闭门造车,即便程序写得再好,架构再漂亮,都不算真正解决了问题。

不要以为只有软件受到环境的“硬”约束的情况,有时候,环境也会受到软件的“硬”约束。如果你留意过产品的说明书,往往会发现很多产品提供的都是多语言说明书,本来说明的文字不需要太多篇幅,每种语言的版本都印上去,说明书的成本就高了很多倍。而实际上,产品的目的市场(目的语言)几乎是确定的,那为什么还需要浪费成本去做多语言说明书呢?

直到在工厂实地参观了生产线,我才真正明白原因在哪:软件是可以自由分隔和组合的,生产线却做不到。依照现实情况,大多数加工厂的所用生产管理系统只能支持“单一原料表、单一工序,生产单一产品”。如果销往不同目的市场的产品,本体相同,只有说明书不同,生产管理系统并不能把“放入说明书”的环节作为变量独立出来,塞到生产流程的“模板”中,实现“本体生产工艺相同,包装所用说明书不同”。即便生产系统能支持,生产流水线也无法这样安排,因为整条流水线的工位组合是固定的。没错,先进的生产管理系统和生产线可以支持这种“模板+变量”的模式,但实现它的成本太高了。

所以,如果不用多语言说明书,只能为不同的市场配备不同的生产流程(硬拷贝),这样其中某个工艺需要变化,则所有的生产流程都需要变化,牵一发而动全身,代价太高。所以只能退而求其次,干脆多花点成本,把唯一的变量——说明书——印成多语言的,虽然看起来浪费,却是最经济最省事的做法。

这类问题看来很简单,我仍然认为值得花篇幅来谈,是因为我发现,随着互联网尤其是移动互联网的发展,软件越来越多地参与到生活的方方面面,也越来越多地会受到现实的“硬”约束。在以前,软件开发更像一门独立的学问(一门玄学),所以用户都必须学习如何“使用软件”,软件开发人员则享有随意“改来改去”,以及挑剔和教育用户的权力。但如今,软件既然是“软”的,就应当像水那样,没有固定的形态,却可以渗入现实世界的各个角落——很多时候,决定软件价值的不再是高深的技术,复杂的架构,而是能不能融洽地与现实相处。身为软件开发人员,我们需要反复问自己到底要解决什么问题,究竟会受到什么限制,然后提出直指问题核心的解决方案。在这方面,我也遇到过让我印象深刻的例子。

在快递包裹的收货工位,收货员需要做的是称量包裹的重量,并扫描上面的条码。电子秤和扫描枪都已经连接到电脑,正常流程下光标会自动移动,不需要人工干预。但有时出现异常情况,还是需要取消、回退、确认等操作。按照常见的解决思路,一个键盘或者至少小键盘是必须的。结果不但多配了一台设备,操作员还需要转移双手操作多个设备。后来一位行业经验丰富的产品经理给了个很巧妙的解决方案:把常见的取消、回退、确认等操作各约定为一段编码,以条码打印出来贴在操作台上,操作员手不用离开扫描枪,就可以完成所有工作:扫这个条码,是取消;扫那个条码,是回退;扫另外一个条码,就是确认……

我必须承认,虽然我之前也做了很多年软件开发,解决过不少问题,但面对这个问题,我想到的方案都是“怎么简化键盘操作”。直到见到扫码方案的那一刻,我才豁然开朗——原来,软件还可以这么做!

那么,软件以后应该都可以这么做了罢。



最新评论

来自 - 云南昆明 的 Mozilla/Mac 用户 2015-02-22 02:03 3 回复
最后那个扫码的例子真心要点个赞
微博评论 2015-02-21 15:03 1 回复
想起来前段时间做查询,要我说用下拉框做日期选择,某某要用个文本域让用户输入"yyyymmdd"格式的日期,并说:“他硬要输入‘我是傻逼‘也没办法,软件使用都是需要学习的。”开发者有权教导用户如何使用软件,但更好当然是用户的使用更贴心舒适
mailbill 2015-02-20 11:02 1 回复
软件只有真正从实际出发才能更好发挥作用!
微博评论 2015-02-20 07:33 1 回复
好。
微博评论 2015-02-20 07:03 29 回复
难道不是因为小票是即时打印的而不能修改已打印那部分内容?
微博评论 2015-02-20 01:33 1 回复
Re
微博评论 2015-02-20 00:33 1 回复
妥协的艺术
微博评论 2015-02-20 00:03 1 回复
好文
微博评论 2015-02-20 00:03 1 回复
软件只有真正从实际出发才能更好发挥作用!
微博评论 2015-02-20 00:03 1 回复
很明显不是这个原因。。。
微博评论 2015-02-19 23:33 2 回复
good[doge]
微博评论 2015-02-19 23:01 2 回复
z//@游荡的坎德人: 有理…
微博评论 2015-02-19 23:01 2 回复
谢个思路,值得学习!
微博评论 2015-02-19 23:01 2 回复
好文,mark
微博评论 2015-02-19 22:33 2 回复
这种东西需要每一个程序猿和产品经理都背一遍。 还好,这个道理在我编写第一个工业软件的时候,就已经学到了。跟工业系统比起来,商业系统实在是太......简单了。
微博评论 2015-02-19 22:33 2 回复
有理…
微博评论 2015-02-19 22:33 2 回复
看完就被触动到啦
微博评论 2015-02-19 22:33 2 回复
微博评论 2015-02-19 22:33 2 回复
[思考]值得思考一下
微博评论 2015-02-19 22:33 2 回复
量子计算……*2[思考][笑cry]
微博评论 2015-02-19 22:33 2 回复
[思考]

返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。