軟體開發的硬約束

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

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

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

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

（題圖來自 aggrandizesolutions.com）

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

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

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

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

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

在快遞包裹的收貨工位，收貨員需要做的是稱量包裹的重量，並掃描上面的條碼。電子秤和掃描槍都已經連線到電腦，正常流程下游標會自動移動，不需要人工干預。但有時出現異常情況，還是需要取消、回退、確認等操作。按照常見的解決思路，一個鍵盤或者至少小鍵盤是必須的。結果不但多配了一臺裝置，操作員還需要轉移雙手操作多個裝置。後來一位行業經驗豐富的產品經理給了個很巧妙的解決方案：把常見的取消、回退、確認等操作各約定為一段編碼，以條碼列印出來貼在操作檯上，操作員手不用離開掃描槍，就可以完成所有工作：掃這個條碼，是取消；掃那個條碼，是回退；掃另外一個條碼，就是確認……

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

那麼，軟體以後應該都可以這麼做了罷。