談對程序的理解

04-06

最近對計算機原理比較感興趣，複習的過程中，一些思考落腳到「程序」這個概念，索性聊聊我對它的理解。

我覺得可以用一個公式來概括程序是什麼：

f(用戶輸入數據，網路數據，I/O數據，外設數據[,...]) = 某個需求或問題的結果

這個函數f就是程序。猶如人類發明的千千萬萬個工具一樣，程序也是工具的其中一種。它的某些特點像紙一樣，人們把數據(信息)輸入給紙，然後紙存儲這些數據，以解決數據存儲的問題。人們不需要再通過費時費力的大腦記憶，也不需要口口相傳，而且能保證數據準確性的情況下，完美解決這個問題。

程序是什麼？程序是為了解決人們碰到的各式各樣的需求或問題，而形成的各式各樣的超級函數，或者說是數學模型。輸入的是各種數據，輸出的是邏輯運算後的結果。而這個結果，就是人們需要的。比如語雀的編輯器程序，我不斷地敲擊鍵盤輸入鍵值，由鍵值組合成不同數據，由語雀加以呈現和保存。我把腦海中的所思所想，透過鍵值的不同組合，輸入給了語雀，語雀幫我完整記錄了我的這些思考。

程序的組合會形成業務功能，業務功能的組合形成業務軟體。現代社會中各式各樣讓人眼花繚亂的軟體(淘寶購物功能、王者農藥遊戲、蝦米音樂)，就是這樣搭建組合起來的。

拋開解釋器、編譯器等不說，程序的下游是什麼？這小到一個個語句、數據類型、流程式控制制、函數、類背後是什麼？是一個個cpu指令和內存地址，再往下說是晶體管。因為它們數量極多，又在時鐘脈衝和電流的控制下，操練著比大閱兵方隊還整齊的步伐完成一個個指令要求的數據的排列組合，速度快的令人窒息，於是才會在「二元對立狀態」下完成著數據無窮無盡的邏輯處理。

單獨拎出來cpu指令和內存地址來度量，我覺得毫無意義。正如人體是由億萬個細胞組成，如果為了體檢，把細胞的狀態都測試一遍，這種做法顯然是不可取的。體檢報告上會把人體分為血壓、脈搏、心功能、眼耳鼻喉等，劃分功能區域進行度量。程序也一樣，拆分成一個個小的基線(如單元測試等)去度量，顯然好操作多了。

這篇文章暫時先不說程序度量，後續會繼續說這塊的理解。我先以一個用戶的視角，來看待程序這個工具。我發現，人類對於工具的態度，猶如對待自己的心理需求(可參考馬斯洛的心理需求層次理論)一樣，同樣具備五種層次。即可用需要、舒適需要、協同需要、安全需要、自我實現(DIY)需要。

拿程序作為最典型工具來講這五個層次。

可用需要：一個程序代表能給出一個需求或問題的結果。不管這個超級函數中隱藏了什麼數據結構和演算法，用戶不關心。程序標榜的說是能解決某個問題是吧，我輸入一定的數據，你得給我準確的結果。這其中又包含對功能完備性、運行穩定性和體驗流暢性有一定的需求。不能我輸入一定的可理解範圍內的數據，程序無法給出結果，像當下某些傻傻的AI設備那樣，「今天的天氣如何？」——「杭州.晴.14-27度」，「天咋樣？」——「不好意思，你的問題我無法理解」。或者我輸入一些變態的數據，直接crash。當然完備性和穩定性滿足後，也要體驗流暢，不能我輸入了數據已經半天了，界面處於假死狀態。

舒適需要：一個程序滿足了可用，接下來用戶的需求會提升到舒適的層面。UI要美觀啊，交互要易用啊，這樣用著才舒服嘛。不然每次打開這個程序，看到那亂糟糟的界面，窩心的交互，本來一個任務手工搞的話3步完事，用程序得30步操作，是誰都受不了。用工具本來是想在心情愉悅下，精確且偷懶地完成任務。工具的出現是為人所用，誰也不想沒事在工具上耗費不必要的麻煩(當然ZF部門推出的軟體，從來都是很大可能止步在可用階段的，P民聲弱怒不可言而已)。

協同需要：一個程序滿足了可用和舒適，基本滿足了一個人對工具的所有期望。但是「獨樂樂，不如眾樂樂」，大家一起合作並體驗工具的便捷，豈不美哉！這樣通過工具，可用把大任務拆分為小任務，大家協同合作一起完成大任務。小任務的並行處理，就需要程序有數據共享性、平台移植性和跨平台性。於是單機版的程序，演化成了網路版。不管是傳統軟體，還是目前方興未艾的互聯網軟體，都把程序簡化成了C/S架構。這樣做的好處之一是C端可以儘可能地重交互、輕邏輯和跨平台，讓用戶盡情折騰吧，輸入什麼數據C端程序都可以不管，直接扔給S端處理。不管邏輯意味著可以減少很多運算，進而提升響應的效率，讓體驗更加流暢。扔給S端處理數據的好處是有一個統籌中心安排事務，讓事務能按序並行處理而不衝突。

當然有人說，我也見過沒有多人協同的網路版程序。即C-S是一對一關係。如果是這種程序，我覺得它本身有兩點考慮：一是重交互、輕邏輯和跨平台，讓客戶端儘可能的不佔用用戶機資源；二是數據共享，讓用戶隨處可用。

安全需求：一旦程序滿足了多人協同需要，一個很現實的問題就會擺在面前，那就是如何保證數據安全。並不是所有數據都喜歡在網路上「裸奔」。於是程序的網路功能模塊升級為加密模式，讓C到S的數據傳輸在網路的各個環節(即網路鏈路)上即使被非法截獲，也無法破譯出來。人類啊，為了不同目的而互相戒備，使原本簡單的工具在攻與防的螺旋進化中變得越來越複雜越來越不可理解，徒增內耗的成本而無益於工具本身作用的變革和進化，都是閑的。

自我實現(DIY)需求：一個程序滿足了上述四條，足以組織一大群人完成一個艱巨的任務。但是，每個人對工具的理解不同，從而千篇一律的UI、交互和功能，根本是眾口難調。日久生厭，會讓舒適需求變的岌岌可危。這時候程序的功能可定製性會變得越來越迫切。如果程序的架構合理，功能和UI耦合度低的話，會很容易滿足這種最高級別的需求。提供一個開放API，較易用的DSL，或者是傻瓜式的配置，讓這些閑著沒事、精力無處釋放、愛「瞎折騰」的人們DIY去吧，折騰出一個個小程序、擴展、插件、通用的個性化配置，或者是基於API的子應用。這個時候的程序，儼然是一艘航母，載著千奇百怪的功能性飛行器，駛向更耀眼的未來。所以程序的最高境界，不是一組人把所有的功能都做完做盡，來了需求立即支持，再說也不可能保證都窮舉到。而是打造出一個生態，一個載體，讓愛折騰的人們貢獻智慧和力量，才能愈發趨於完美和易用，達到工具史詩的最美篇章。不過這真的很難，有時候官方團隊和民間的看法不一，理解不同，或者是架構層面的局限，導致一個個程序在本該綻放的時候隕落(網頁三劍客之流)，實在令人惋惜。

好了，理解了程序的五個層級需求，再去看一個程序該在什麼階段實現什麼需求，就是很清晰明了的事情了。而所謂的程序質量，就有針對性的度量維度了。文中有很多偏口語化、不準確的理解，歡迎大家指正和討論。