软件开发的硬约束，原文链接
在超市结帐的时候，收银员都会给我们打一张小票。有时候同样的商品我们会买两三件，打印在小票上面，有时候只有1行记录，数量是3，但也有时候有3行记录，数量都是1。这个现象很有意思，也引起了我的兴趣。据我观察，后一种情况明显更多。分明是前一种做法更节省纸张，为什么更少采用呢？
我曾经设想，是因为收银的机器性能太差，内存很少，只能维护简单的数组结构，不能维护集合，也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现，这个说法站不住脚——现代的收银机性能足够很好了，甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢？就在我百思不得其解之际，一个偶然的机会解开了我的疑惑。
当时，我们要开发一套收货管理系统。为了节省纸张，也为了追求程序的美感，我直接选择了“单行多件记录”的做法，因为硬件的性能是绰绰有余的。程序开发完成之后，测试完全没有问题，一切非常顺利。但是实际应用之后，仓库的同事却对这个特性非常不满意，强烈要求每一行只对应一件货物，多件同样货物就应当有多条记录。“好嘛，正好有机会看看原因何在了”。
到实地一看我才明白，多件商品归到一行记录有什么问题。首先，大家已经习惯了拿一件货扫描一次，对应的清单上就需要打印一行记录，才确认已经扫描完成。当然，我们可以说，如果用别的方式提示，比如屏幕闪动，或者扬声器发声，也能起到确认提示的作用。但是，扫描生成的清单，还会被下一道工序的员工使用。当他对着清单处理货物时，他当然希望每点一件货，就直接从清单上划掉一行；如果这一行对应着超过一件商品，他就只能在旁边写“正”字来计数，效率自然大大降低。
这点发现对我的触动很大。大概因为我长期以来做的都是“纯”软件产品，所以虽然也有边界的划分，责任的区隔，架构的设计，但这些都是“软”的。一项功能、一种责任放在这里还是那里，固然有架构的考虑，但如果实在要修改，通常也不会有太大的问题。比如消息传递，既可以用“推”也可以用“拉”，往往没有“硬”的约束。但是，现实世界里的很多问题就不是这样简单了。限于设备和场景，某些时侯只能“拉”不能“推”。如果真的遇到了“硬”的限制，如果我们只把自己关在办公室里闭门造车，即便程序写得再好，架构再漂亮，都没法真正解决问题。
不要以为只有软件受到环境的“硬”约束的情况，有时候，环境也会受到软件的“硬”约束。如果你留意过产品的说明书，往往会发现很多产品提供的都是多语言说明书，本来不需要太多的篇幅，每种语言都需要对应一份，说明书的成本就高了很多。而实际上，产品的目的市场(目的语言)几乎是确定的，那为什么还需要浪费成本去做多语言说明书呢？
直到在工厂实地参观了生产线，我才真正明白原因在哪：软件是可以自由分隔、自由组合的，生产线却做不到。依照现实情况，大多数加工厂的所用生产管理系统只能支持“单一原料表、单一工序，生产单一产品”。如果销往不同目的市场的产品，本体相同，只有说明书不同，生产管理系统是不能把包装环节独立出来，塞到各个相同的生产流程中，实现“本体生产工艺相同，包装所用说明书不同”的目的的。如果不用多语言说明书，只能为不同的市场配备不同的生产流程(硬拷贝)，这样其中某个工艺需要变化，则所有的生产流程都需要变化，牵一发而动全身，代价太高。所以只能退而求其次，干脆多花点成本，把唯一的变量——说明书——印成多语言的，一了百了的好。
本来这类问题很简单，我之所以要花这么大篇幅来谈，是因为我发现，随着互联网尤其是移动互联网的发展，软件越来越多地渗透到生活的方方面面，也越来越多地会受到现实的“硬”约束。很多时候，决定软件价值的不再是高深的技术，复杂的架构，而是能不能融洽地与现实相处。相应的，身为软件开发人员，我们不能延续纯软件那种“改来改去”的随意，而需要反复问自己到底要解决什么问题，究竟会受到什么限制，然后提出直指问题核心的解决方案。在这方面，我也遇到过让我印象深刻的例子。
在快递包裹的收货工位，收货员需要做的是称量包裹的重量，并扫描上面的条码。电子秤和扫描枪都已经连接到电脑，正常流程下光标会自动移动，不需要人工敢于。但有时出现异常情况，还是需要取消、回退、确认等操作。按照常见的解决思路，一个键盘或者至少小键盘是必须的。结果不但多配了一台设备，操作员还需要转移双手操作多个设备。后来我所在团队的成员给了个很巧妙的解决方案：把常见的取消、回退、确认等操作约定为一段操作码，以条码打印出来贴在操作台上，操作员手不用离开扫描枪，就可以完成所有工作：扫这个条码，是取消；扫那个条码，是回退；扫另外一个条码，就是确认……
我必须承认虽然我之前也做了很多年软件开发，解决过不少问题，但面对这个问题，我想到的方案都离不开键盘。直到见到这个方案的那一刻，我才恍然大悟——原来，软件还可以这么做！
那么，软件以后都可以这么做了罢。