在超市结帐的时候，收银员都会给我们打一张小票。有时候同样的商品我们会买两三件，打印在小票上面，有时候只有1行记录，数量是3（“听装百事可乐 x3”），但也有时候有3行记录，数量都是1（“听装百事可乐 x1” 重复3行）。这个现象很有意思，為什麼不统一呢？而且据我观察，后一种情况明显更多。分明是前一种做法更节省纸张，为什么更少采用呢？
我曾经设想，是因为收银的机器性能太差，内存很少，只能维护简单的数组结构，不能维护集合，也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现，这个说法站不住脚——现代的收银机性能足够很好了，甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢？就在我百思不得其解之际，一个偶然的机会解开了我的疑惑。
当时，我们要开发一套收货管理系统。为了节省纸张，也为了追求“程序的美”，我决定选择了“单行多件记录”的做法，也就是“听装百事可乐 x3”，因为硬件的性能是绰绰有余的。程序开发完成之后，测试完全没有问题，一切非常顺利。但是实际应用之后，仓库的同事却对这点非常不满意，强烈要求每一行只对应一件货物，多件同样货物就必须有多条记录。好嘛，正好有机会看看原因何在了。
到实地一看，我瞬间就明白了多件商品归到一行记录有什么问题。首先，大家已经习惯了拿一件货扫描一次，对应的清单上就需要打印一行记录，以确认扫描完成。当然，用别的方式提示也可以，比如屏幕闪动，或者发出声音，只是这样的做法还不多，大家不太习惯。其次，扫描生成的清单，还会被下一道工序的员工使用——因为世界没有完全IT化，很多时候传递信息的单据还必须是纸质单据。对着清单处理货物的人当然希望每点一件货，就直接从清单上划掉一行；如果这一行对应着超过一件商品，他就只能在旁边写“正”字来计数，效率自然大大降低。如果货物没有归类放好，效率还会更低（如果你仔细观察饭店服务员的上菜过程，也会发现这点，只是很少有人会把某个菜点多份，所以不明显）。
这点发现对我的触动很大。大概因为我长期以来做的都是“纯”软件产品，所以虽然也要考虑划分边界，区隔责任，设计架构，但这些都是“软”的，没有什么“硬”的约束：一项功能、一种责任放在这里还是那里，固然有架构的考虑，但如果实在要修改，通常也不会有太大的问题，所以即便只从逻辑和美的角度来考虑也没有什么问题。最典型的消息传递，既可以用“推”也可以用“拉”，一般场景下都不会有大的区别。但是，现实世界里的很多问题就不是这样简单了。限于设备和场景，某些时候就只能“拉”不能“推”。比如某些移动设备会受到功耗的限制，所以“推”当然好于“拉”。如在这样的“硬”限制面前，如果我们只把自己关在办公室里闭门造车，即便程序写得再好，架构再漂亮，都不算真正解决了问题。
不要以为只有软件受到环境的“硬”约束的情况，有时候，环境也会受到软件的“硬”约束。如果你留意过产品的说明书，往往会发现很多产品提供的都是多语言说明书，本来说明的文字不需要太多篇幅，每种语言的版本都印上去，说明书的成本就高了很多倍。而实际上，产品的目的市场（目的语言）几乎是确定的，那为什么还需要浪费成本去做多语言说明书呢？
直到在工厂实地参观了生产线，我才真正明白原因在哪：软件是可以自由分隔和组合的，生产线却做不到。依照现实情况，大多数加工厂的所用生产管理系统只能支持“单一原料表、单一工序，生产单一产品”。如果销往不同目的市场的产品，本体相同，只有说明书不同，生产管理系统并不能把“放入说明书”的环节作为变量独立出来，塞到生产流程的“模板”中，实现“本体生产工艺相同，包装所用说明书不同”。即便生产系统能支持，生产流水线也无法这样安排，因为整条流水线的工位组合是固定的。没错，先进的生产管理系统和生产线可以支持这种“模板+变量”的模式，但实现它的成本太高了。
所以，如果不用多语言说明书，只能为不同的市场配备不同的生产流程（硬拷贝），这样其中某个工艺需要变化，则所有的生产流程都需要变化，牵一发而动全身，代价太高。所以只能退而求其次，干脆多花点成本，把唯一的变量——说明书——印成多语言的，虽然看起来浪费，却是最经济最省事的做法。
这类问题看来很简单，我仍然认为值得花篇幅来谈，是因为我发现，随着互联网尤其是移动互联网的发展，软件越来越多地参与到生活的方方面面，也越来越多地会受到现实的“硬”约束。在以前，软件开发更像一门独立的学问（一门玄学），所以用户都必须学习如何“使用软件”，软件开发人员则享有随意“改来改去”，以及挑剔和教育用户的权力。但如今，软件既然是“软”的，就应当像水那样，没有固定的形态，却可以渗入现实世界的各个角落——很多时候，决定软件价值的不再是高深的技术，复杂的架构，而是能不能融洽地与现实相处。身为软件开发人员，我们需要反复问自己到底要解决什么问题，究竟会受到什么限制，然后提出直指问题核心的解决方案。在这方面，我也遇到过让我印象深刻的例子。
在快递包裹的收货工位，收货员需要做的是称量包裹的重量，并扫描上面的条码。电子秤和扫描枪都已经连接到电脑，正常流程下光标会自动移动，不需要人工干预。但有时出现异常情况，还是需要取消、回退、确认等操作。按照常见的解决思路，一个键盘或者至少小键盘是必须的。结果不但多配了一台设备，操作员还需要转移双手操作多个设备。后来一位行业经验丰富的产品经理给了个很巧妙的解决方案：把常见的取消、回退、确认等操作各约定为一段编码，以条码打印出来贴在操作台上，操作员手不用离开扫描枪，就可以完成所有工作：扫这个条码，是取消；扫那个条码，是回退；扫另外一个条码，就是确认……
我必须承认，虽然我之前也做了很多年软件开发，解决过不少问题，但面对这个问题，我想到的方案都是“怎么简化键盘操作”。直到见到扫码方案的那一刻，我才豁然开朗——原来，软件还可以这么做！
那么，软件以后应该都可以这么做了罢。
From Life Sailor, post 软件开发的硬约束
家长应当和儿童，尤其是低龄儿童谈论“空气动力学”吗？ 我的答案曾经是非常肯定的：不应当。不要说儿童，就是成年人也不见得理解这些抽象的概念，与儿童谈论这些名词，只会让人望而生畏。身为父母，我们应当做的是，以孩子能理解的、感兴趣的方式谈论相关的具体问题，但绝对不要提这些大词。 不过世界的奇妙就在于，父母对教育并没有绝对的权威，总是需要根据实际情况来修正自己的观点。在“空气动力学”的问题上，我就吃到了教训。 那是一个下午，家里小朋友在iPad上看完他最喜欢的Blippi（这个节目我之前介绍过，对80后父母来说，Blippi可以理解为“带你见识各种新鲜玩意的董浩叔叔”），忽然抬起头来问我：“爸爸，你知道什么是aerodynamics吗？” “什么？你问我知不知道什么是aerodynamics？”我的下巴都要掉下来了。“空气动力学”这种词还是上中学时，身为军迷的我们在《航空知识》上知道的。再往后英语好一些，能看原版科普视频了，才知道“空气动力学”的原文就是aerodynamics。可是，我家这个还没上小学的家伙，竟然就能真诚地瞪大眼睛，一本正经地问我“知不知道什么是aerodynamics”。 (more…)
我本来是不应该认识孟老师的。 2001年，我在寝室夜谈里第一次听到孟老师的名字。当时有同学说“公共选修课的《法学概论》讲得真好，那个老师叫孟繁超”，开始我不怎么在意，慢慢才发现这么说的人还不少。那个年月网上的资料正丰富，出版管制也不那么严格，刚进大学不久的我正自由自在地看得过瘾，心想“大学里的法学概论讲再好，能讲些什么，还不是教科书上老一套”，所以这种课，不听也罢。 但生活就在这么奇妙。那年冬天，有天中午我吃过饭正准备午睡，忽然有人敲门问“计算机系有位叫余晟的同学在这里吗？” 大中午的谁会来找我？我正好奇这个问题，门一推开就有同学喊“孟老师，孟老师来了”。 那是我第一次见到孟老师，中年人，国字脸，身材高大，打扮很精神，披在身后的深色大衣让我一下子想起电影里的斗篷。他笑眯眯地说“你是余晟？听同学说你搞电脑很厉害，我家的电脑坏了，想请你去看看。” (more…)
中国人大概都对历史有一些特别的偏好。对我们普通人来说，历史首先是文化的象征，一个人“懂历史”，基本等于这个人“有文化”；历史也是民族自豪感的来源，哪怕考古上仍然存在争议，但是“五千年文明”的说法是普通人都耳熟能详的。 不过等我长大之后才发现，这种偏好大概还有更深层次的原因，那就是历史看起来有种道德的意味，因为我们从小就熟悉“以史为鉴”的智慧，也熟悉各种“历史的选择”：每当我们对现实感到失望、困惑的时候，我们经常去历史——而不是先贤的智慧中——中寻找解答。找到曾经发生的类似的故事，就可以预言未来的结局。 于是乎，失望也好、困惑也罢，总归会有光明的未来，历史总会给我们支撑的信念。 我曾经很相信，熟谙历史是种智慧，而且是深层次的智慧。但是看得越多、经历得越多，我就越觉得，这很难称之为“智慧”。 为什么？ (more…)
“无人出租车要来了”。以百度“萝卜快跑”为代表的无人出租车，眼看就要在国内多个城市成规模运营。 熟悉IT的人都知道，IT的独特优势就在于“大规模扩展时边际成本极低”。在软件时代，微软开发的Windows，多卖一份的成本只是多刻录一张光盘而已。在无人驾驶时代，从10辆车到10万辆车的成本，也遵循同样的规律。换句话说，一旦模式“跑通”了，就可以迅速大规模铺开。无人出租车的大规模应用，也是“指日可待”了。 只不过，新技术这一次似乎没有那么激动人心，反而引起了很多争议——无人驾驶出租车大规模推广，会不会影响广大出租车、网约车车主的收入甚至生计？如果是，这样的技术进步，真的是我们所需要、所期待的吗？对于这个问题，不同的人有相差迥异的答案。 按照我的观察，许多人对此是相当乐观的。理由在于，“技术的每一次飞跃发展，虽然有阵痛，最终都创造了更多的新岗位”。既如此，无人出租车短期“看似”抢了许多人的饭碗，但也只是短期的“阵痛”而已。看看历史，纺织机的发明，蒸汽机的改良，汽车的诞生，无不证明了“阵痛说”的正确性。 坦白说，这种观点我是怀疑的。 (more…)
因为小朋友放暑假，近期带小朋友回国待了几个礼拜。最深的感受就是标题所说的：松弛一点，愉快一点。 我第一次突出意识到这点，是在上海下飞机乘地铁。当时我们乘的直梯就要关门，远远看见有个年轻小伙子跑过来，我连忙按住开门按钮，并招呼他”别着急，慢慢来“，等他进了轿厢才关门。本来我以为大家起码会打个招呼，露个笑脸，因为我已经习惯如此，但完全出乎我意料的是，他进来之后对我们完全视若不见，自顾自掏出手机，盯着看得入迷。 我继而发现，不管是在电梯里，站台上，还是车厢里，虽然四下里都是广播”请扶好站稳，抓好扶手，不要看手机“，但是似乎人人都盯着自己的手机。年轻人在打手机游戏，年纪大一点的在滑各种小视频，还有不少人在聊天软件里打字如飞……对着屏幕的表情都很生动，可是一旦抬起头来，似乎马上又换了个人。 后来又有一次，我乘地铁的时候，因为比较拥挤，一个小伙子倒退时踩了我一脚，他大概意识到了，很快把脚挪开，脸上闪过一丝不安，马上又恢复正常，我也没有计较。不幸的是，过了十来分钟，他又踩了我一脚，同样是先有一点不安，很快又恢复正常。 这次我忍不了了，于是我开口告诉他：“小伙子，你已经踩了我两脚了。” (more…)
前几天，国内朋友发来一条消息，原来是乌克兰F-16坠落，飞行员丧生的新闻。我本来以为他要讨论此事的真假和原委，他真正的问题却完全出乎我的意料： 新闻里说，飞行员叫阿列克谢·“月鱼”·梅斯，对应原文是Alexei “Moonfish” Mes，为什么会有人把“月鱼”写在自己的名字里，而且还打引号。 之前看新闻，乌克兰还有一个著名的飞行员叫安德烈·“果汁”·皮尔希科夫（Andrii “Juice” Pishchykov），怎么“果汁”也是正式的名字？ 未必Moonfish和Juice之类，还有什么特别的含义吗？…… 这堆问题看的我有点想笑，因为自己以前也很苦恼外国人的名字，只有在国外长期生活，才逐渐搞清楚这其中的名堂。所以，除了解答朋友的问题，我也把自己的解释写下来，搞清楚两个最不容易理解的点，就不会对外国人名有那么多问题了。 (more…)
View Comments
跨界思维很难呀
余老师的又一篇好文。
同样的问题，我想过，考虑过原因，也得出了类似的答案，但是不曾抬头从更高的层面来看这个问题。
谢谢余老师。 顺祝新春快乐
p.s. 一个typo (不需要人工敢于)
过奖过奖，这个问题就是好玩而已。新年快乐，我们泰国见。
这里实际上讲的是“优化”。通常意义上软件开发的优化是讲算法的优化和架构的优化，前者针对每次运行，后者针对维护成本，两者都是为了经济性的提高。但是要真正达到软件最高的经济性，软件的使用也是需要优化的，因为这第三者完全是独立于前二者的。就跟最优的算法是在复现最经济的逻辑一样，最优的使用设计需要复现最经济的操作流程。两者其实都还共用Big-O分析呢。
就是这个意思。以前软件开发好像是自成一体，用户不会用是用户不懂，不学习；是时候把这个错误的趋势扭转过来了。
余老师，好文章。“不需要人工敢于”最后两个字应该是干预。祝新年快乐！
已经更正了，多谢指出
余大，这几年很少在CSDN看到你了啊。这里有个问题问下，中文有处细节大意是：“扫描生成的清单会被下一环节的员工使用，扫描一件就从库存划掉一件，所以同类商品扫描时多行处理效率会高些”。我的问题是为什么不一次性扫描完成后再交给下一环节的员工从库存划去，这样的话同类货品扫描不是可以用单行来处理吗？
不是从库存中划掉，是从清单上划掉。本质是把实物和清单项目对应起来的过程。
程序员天天在虚拟世界中，天长日久，不免忘了物理世界的限制
您好，请问您在CSDN上有文章吗？
没有的 :)
谢谢余老师提到的一些细节，还是豁然开朗的。
另：
我个人认为，这里面讲的似乎应该是开发对需求理解的问题吧，我更倾向于认为做需求的时候没有很好的去理解和思考。
要看你怎么定义“需求”。我觉得用“设计解决方案”更准确一些。