軟件開發的硬約束

在超市結帳的時候，收銀員都會給我們打一張小票。有時候同樣的商品我們會買兩三件，打印在小票上面，有時候只有 1 行記錄，數量是3，但也有時候有 3 行記錄，數量都是1。這個現象很有意思，為什麼不統一呢？而且據我觀察，后一種情況明顯更多。分明是前一種做法更節省紙張，為什么更少采用呢？

我曾經設想，是因為收銀的機器性能太差，內存很少，只能維護簡單的數組結構，不能維護集合，也不能每添加一樣商品就去重新掃描一次數組做修改。 但是繼續觀察就會發現，這個說法站不住腳——現代的收銀機性能足夠很好了，甚至手機的性能都在突飛猛進。那么這么做的原因到底在哪里呢？就在我百思不得其 解之際，一個偶然的機會解開了我的疑惑。

當時，我們要開發一套收貨管理系統。為了節省紙張，也為了追求“程序的美”，我決定選擇了“單行多件記錄”的做法，也就是“1 行記錄，數量為3”，因為硬件的性能是綽綽有余的。程序開發完成之后，測試完全沒有問題，一切非常順利。但是實際應用之后，倉庫的同事卻對這點非常不滿 意，強烈要求每一行只對應一件貨物，多件同樣貨物就必須有多條記錄。好嘛，正好有機會看看原因何在了。

到實地一看，我瞬間就明白了，多件商品歸到一行記錄有什么問題。首先，大家已經習慣了拿一件貨掃描一次，對應的清單上就需要打印一行記錄，以確 認掃描完成。當然我們可以說，用別的方式提示也可以，比如屏幕閃動，或者發出聲音。但是，掃描生成的清單，還會被下一道工序的員工使用。對著清單處理貨物 時，他當然希望每點一件貨，就直接從清單上劃掉一行；如果這一行對應著超過一件商品，他就只能在旁邊寫“正”字來計數，效率自然大大降低（如果你仔細觀察 飯店服務員的上菜過程，也會發現這點，只是很少有人會把某個菜點兩份）。

這點發現對我的觸動很大。大概因為我長期以來做的都是“純”軟件產品，所以雖然也要考慮劃分邊界，區隔責任，設計架構，但這些都是“軟”的，沒 有什么“硬”的約束：一項功能、一種責任放在這里還是那里，固然有架構的考慮，但如果實在要修改，通常也不會有太大的問題，所以即便只從邏輯和美的角度來 考慮也沒有什么問題。最典型的消息傳遞，既可以用“推”也可以用“拉”，一般場景下都不會有大的區別。但是，現實世界里的很多問題就不是這樣簡單了。限于 設備和場景，某些時候就只能“拉”不能“推”。比如某些移動設備會受到功耗的限制，所以“推”當然好于“拉”。如在這樣的“硬”限制面前，如果我們只把自 己關在辦公室里閉門造車，即便程序寫得再好，架構再漂亮，都不算真正解決了問題。

不要以為只有軟件受到環境的“硬”約束的情況，有時候，環境也會受到軟件的“硬”約束。如果你留意過產品的說明書，往往會發現很多產品提供的都 是多語言說明書，本來說明的文字不需要太多篇幅，每種語言的版本都印上去，說明書的成本就高了很多倍。而實際上，產品的目的市場（目的語言）幾乎是確定 的，那為什么還需要浪費成本去做多語言說明書呢？

直到在工廠實地參觀了生產線，我才真正明白原因在哪：軟件是可以自由分隔和組合的，生產線卻做不到。依照現實情況，大多數加工廠的所用生產管理 系統只能支持“單一原料表、單一工序，生產單一產品”。如果銷往不同目的市場的產品，本體相同，只有說明書不同，生產管理系統并不能把“放入說明書”的環 節作為變量獨立出來，塞到生產流程的“模板”中，實現“本體生產工藝相同，包裝所用說明書不同”。即便生產系統能支持，生產流水線也無法這樣安排，因為整 條流水線的工位組合是固定的。沒錯，先進的生產管理系統和生產線可以支持這種“模板+變量”的模式，但實現它的成本太高了。

所以，如果不用多語言說明書，只能為不同的市場配備不同的生產流程（硬拷貝），這樣其中某個工藝需要變化，則所有的生產流程都需要變化，牽一發 而動全身，代價太高。所以只能退而求其次，干脆多花點成本，把唯一的變量——說明書——印成多語言的，雖然看起來浪費，卻是最經濟最省事的做法。

這類問題看來很簡單，我仍然認為值得花篇幅來談，是因為我發現，隨著互聯網尤其是移動互聯網的發展，軟件越來越多地參與到生活的方方面面，也越 來越多地會受到現實的“硬”約束。在以前，軟件開發更像一門獨立的學問，所以大家都必須學習如何“使用軟件”，軟件開發人員則享有隨意“改來改去”的權 力。但如今，軟件既然是“軟”的，就應當像水那樣，沒有固定的形態，卻可以滲入現實世界的各個角落——很多時候，決定軟件價值的不再是高深的技術，復雜的 架構，而是能不能融洽地與現實相處。身為軟件開發人員，我們需要反復問自己到底要解決什么問題，究竟會受到什么限制，然后提出直指問題核心的解決方案。在 這方面，我也遇到過讓我印象深刻的例子。

在快遞包裹的收貨工位，收貨員需要做的是稱量包裹的重量，并掃描上面的條碼。電子秤和掃描槍都已經連接到電腦，正常流程下光標會自動移動，不需 要人工敢于。但有時出現異常情況，還是需要取消、回退、確認等操作。按照常見的解決思路，一個鍵盤或者至少小鍵盤是必須的。結果不但多配了一臺設備，操作 員還需要轉移雙手操作多個設備。后來我所在團隊的成員給了個很巧妙的解決方案：把常見的取消、回退、確認等操作約定為一段操作碼，以條碼打印出來貼在操作 臺上，操作員手不用離開掃描槍，就可以完成所有工作：掃這個條碼，是取消；掃那個條碼，是回退；掃另外一個條碼，就是確認……

我必須承認，雖然我之前也做了很多年軟件開發，解決過不少問題，但面對這個問題，我想到的方案都是“怎么簡化鍵盤操作”。直到見到掃碼方案的那一刻，我才豁然開朗——原來，軟件還可以這么做！

那么，軟件以后應該都可以這么做了罷。