摘要：源碼敬上按照一篇技術文章的慣例，先得定義名詞作出解釋信息管理系統信息管理系統百度百科，往大了說，除了圖書管理倉儲管理，電商資訊網站和大部分的后臺都屬于信息管理系統。

此文首發于知乎

Talk is cheap, show me the code.

手里有碼，心中不慌。源碼敬上 ihongs/HongsCORE

按照一篇技術文章的慣例，先得定義名詞、作出解釋：

信息管理系統：信息管理系統_百度百科，往大了說，除了圖書管理、倉儲管理，電商、資訊網站和大部分的 APP 后臺都屬于信息管理系統。但此文并不討論復雜的系統，只淺涉一點點基礎，也不牽扯到 OLTP/OLAP 之類概念，只討論一個玩笑般的話題：增刪改查。

自動化構建：我認為全自動的構建方式就是人向機器提出需求，機器直接給出完整方案，過程中機器可能會詢問并等你作出抉擇，但無需程序員干預細節；相對的，半自動化仍然需要人來確定枝枝蔓蔓的細節，但具體的數據流轉邏輯無需編寫代碼。

不過，這不是論文，這不是論文，這不是論文！

從上述定義來說，本文談到的系統只能算"近半自動化"，當超脫那些簡單但繁瑣的基礎邏輯后，仍然需要程序員去干預甚至覆蓋重建。我試圖讓這個系統不是一個秤砣啃不動砸不爛，好讓其可干預、可拆散、可重建。這不會生成邏輯代碼，只會產生結構類代碼，如果需要，可以過濾輸入輸出和覆蓋重寫邏輯，但不存在“修改”邏輯代碼這么個操作，因為沒有邏輯程序代碼產生——沒有這個必要。

數據與邏輯并不是天然分隔的，一個程序代碼之所以成為邏輯指令，只有當被執行的時候才表現出來那些動態的判斷和分支，但當它存儲在硬盤里，不管里面寫了多少動詞，是文本還是二進制，他跟一篇文章或一個圖片沒有本質上的區別。所以，編程面對的就是把上游數據進行合理的解釋，從一個數據結構轉換成另一個數據結構，這個轉換過程一般情況下由人來完成——碼農就是這個轉換的解釋器。

說到轉換，我就想到我們師徒四人換取通關文牒……抱歉抱歉，走錯片場了。

舉個例子，現在有個文牒、哦不、文檔查詢網站，首頁提供了一個搜索框，上面有關鍵詞、分類和標簽三項，當您輸入關鍵詞、選擇分類和標簽后點擊搜索，頁面會向服務器重新請求并跳轉，URL 從 http://xxx.com/document 變成 http://xxx.com/document?word=催化&type=化工&tags[]=高新科技&tags[]=前沿技術，到服務器后，尾巴上的參數轉換成 {word: "催化", type: "化工", tags: ["高新科技", "前沿技術"]}，再被轉換成 SQL 查詢語句 SELECT * FROM document WHERE word LIKE "%催化%" AND type = "化工" AND tags IN ("高新科技","前沿技術")。從 URL 的問號后的查詢串轉換為程序里的結構化數據，這個過程一般由服務容器或應用框架自動完成，這個過程是一對一的映射，基本不存在歧義，所以往往不用程序員手工編程處理；但是從請求數據轉換成查詢語句，就不太好”通用“了。type=化工 和 word=催化 有什么區別嗎？都是一個等于號挑著兩個串，誰知道前者對應的是 = 而后者就要變成 LIKE 呢？答案是程序員知道，因為產品經理讓他這么干的。他會寫代碼：if (request.word) sql += " AND word LIKE {request.word}"，這只是用偽代碼舉例，不用糾結看不看得懂，現實中出于分層、通用、規范甚至是裝逼，可能在數據與查詢之間再用一個額外的框架，框架又采用一種中間數據結構，然后由框架再轉成實際的查詢。

可以想象，程序員腦子里裝了一份底板，如果產品經理說什么需求那么他就會寫什么代碼？把前面這個”如果“拿掉，就可以用一個映射來描述 需求=>代碼。當一個老碼農閱碼無數后找出來幾種常用轉換歸類，那么，可以用結構化的方式描述底板：

{
  "一般字段": "`{字段名}` = "{取值}"",
  "關鍵詞類": "`{字段名}` LIKE "%{取值}%"",
  "多個值類": "`{字段名}` IN (JOIN(",",{取值}))"
}

如果進一步發掘共同點，還能總結出數字類型、日期類型，然后前端表單結構那邊讓一步，雙方約定好規則，比如加 _lt 后綴的表示小于、加 _gt 后綴的表示大于，或是在值的格式上做文章，定義為類似數學區間的形式 (min,max) [min,max]。

這還不夠，結構描述我們還可以搬進去更多東西，比如 docuemnt 表跟 author 表之間什么關系。說到關系……串場了串場了……對于關系，可以查閱 ERM (實體關系模型) 相關的資料，并不需要技術背景就能看明白。簡單來說，我們可以將文檔（資源、實體）之間的關系歸納為一對一、一對多、多對多，加上依賴方向，再衍生出幾種不同的圖例。反過去向下追究，到物理模型，就只有一種關系，可以用 UML 的類圖表示為依賴，只需要一個箭頭符號來指向被依賴方。

好久不畫了、軟件也沒裝，度娘搜來的 ERM 圖例和 UML 類圖太丑，略

起初，我的系統建立在關系數據庫之上，這也是常見的教科書式的手段。數據庫的表結構本身含有一定的描述，比如字段名、字段類型、取值約束等。但這顯然還不夠，于是定義了一個 xml 來描述表和表之間的關系；這部分其實也能從數據庫本身取得，但獲取方式在各數據庫產商中并不像一般 SQL 那樣有一致的規范，而想要統一就得進行封裝，內部再來處理差異部分。這偏離了目標，因此僅在完成 MySQL 的結構提取后就終止了，改為自行描述關聯關系。這樣做順便得到一個好處，很多時候可以不需要 JOIN 就能完成關聯查詢，甚至跨庫跨數據庫類型的關聯的——盡管可能效率不夠高。

這個關系數據庫的描述文件見：默認配置，內部注釋含寫法；格式描述。

https://pic4.zhimg.com/v2-f57...

后來，NoSQL 興起，有 Redis、MongoDB、CouchDB 等諸多選擇，可惜這一次這些大廠似乎誰也沒說服誰，無法形成統一的標準。如果定義一個資源對象就是一個文檔（參考簡歷的結構），因此選擇文檔類數據庫就再合適不過了。Redis 等鍵值庫肯定不行了，棄之；我還希望這個庫能嵌入我的系統，這樣就可以像 Sqlite 那樣一同打包、一并啟動。于是 Lucene 成了不二的選擇。

Lucene 非數據庫？此話怎講？阿里搞搜索的人說他們的業務部門希望他們的搜索系統像數據庫一樣即存即取，印象里他們還專門發文談到過。坑他們都踩過了，雖不知道如何跳過去的，但只要知道能過去就行了。所以 Lucene 不但是數據庫，還是很好的文檔數據庫；需要的話還可以是圖（譜）數據庫，Neo4j 底層即為 Lucene，我也有直接用 Lucene 開發過人脈關系引擎。

打斷一下，現在你要搜 Lucene 首先進入的是 Solr 的站點，Lucene 已經成了 Solr 的一個附件。為什么不選擇封裝得更完備的 Solr？除了上面說的需要嵌入的原因，還因為將要談到的描述結構 Solr 就那么干了。大爺我手里也有槍，不稀罕您那大炮仗。

文檔數據庫是沒有固定結構的，怎么存怎么取你說了算。這很麻煩，但對此處的需求來說，這太棒了。就意味著，只要做一個結構解釋器，再也不必為如何生成和變更表結構傷腦筋了。

先把示例文件甩出來：默認配置，內部注釋含寫法；結構描述。

https://pic1.zhimg.com/v2-53c...

至此，碼農腦子里那份底板已經摳出來最簡單但也是最常用的部分了，碼農們在這一瞬間得到了解脫。放心，失不了業；搞成平臺除外，但也不必擔心，真那樣的話只會刺激市場釋放更多需求，然后碼農們搞得風生水起，“升值加薪，當上總經理，贏取白富美”……打住打住，“你有權保持沉默，但是你沒權扯淡啊”。

然后呢？讓產品經理去寫配置？倒也是，這 XML 看上去也沒比 PRD 難在哪嘛。但送佛還是要送上西天D，拿鍵盤敲代碼（盡管不是邏輯代碼）這種蠢事讓我們碼農干就行了，還是要搞個圖形界面好讓人指點江山呀。

https://pic1.zhimg.com/v2-ed0...

這看起來像一個問卷調查設置界面，現工作的一部分恰好也是類似問卷的東西。但側重點導致了發力點也不相同。1、這里關聯是重要的一環，而問卷沒有這個需求；2、將結構固定到文件以便微調，問卷也沒有這個顧慮；3、邏輯流程需要方便定制，并不得對系統整體產生干擾，問卷也沒有這個必要。不過確實可以用此構建一個高度可定制的問卷/表單系統，而且有這個計劃。

https://pic4.zhimg.com/v2-189...

https://pic1.zhimg.com/v2-655...

https://pic2.zhimg.com/v2-8e0...

除提供內部管理界面和接口，也可以對外公開接口和提供最基本的頁面，且與管理部分既有聯系又有隔離，開放部分默認限制僅能編輯屬于自己創建的內容。這些都可以通過定制人為干預。

https://pic2.zhimg.com/v2-696...

https://pic2.zhimg.com/v2-903...

第一幅圖的設置完成后，后面的界面就自動產生了。這個依據是什么呢？產品經理、助理們會畫出一個個原型圖，程序員看了后想象數據該如何存儲，然后倒騰腦海里那一堆代碼底板，最終變成邏輯和頁面。這要說回十幾年以前，沒有產品經理，沒有 UI、UE，幾個程序員在白板上比劃兩下就擼起袖子開干了；至于界面，頂多再拉個美工做幾個水晶按鈕，現實中相近的東西長什么樣，軟件就盡量做成什么樣。

這個話題深入下去可以談到“自頂而下”和“自底而上”兩種設計方式。簡單來說，一個是從表面看問題，最后確定一下如何將狀態持久化；一個是從底層看問題，先確定數據如何存儲然后向上逐層擴展直至界面。實際的情況多是兩者相結合的，“自頂而下設計，自底而上實現”。

現在穿越時空回到過去，定義有什么樣的結構就該有什么的界面，那么從那個表單配置 XML 出發，通過研究歷史的界面和操作流程，進行總結并將過程固定下來，形成映射關系，就自然可以產生操作界面了。

具體點來說，總結發現一個普通的 UI 流轉過程可以抽象為 加載、打開、發送 3 種類型，采用事件驅動，并在流程上規定“誰打開、誰負責”，讓各大組件間可以用最通用、最簡單方式交換狀態。但與面向前端程序員的接口不同，UI 是面向人的，而人的思想和喜好具有很大的不確定性，因此，并未對 UI 部分提供更多的輔助設置。一個注定要被重新編寫的東西，你做的越多那么定制的人改起來就越累，一點多余也不做，就是最好的選擇。

當超越時間去看待問題，一切過程都是結構。

TODO：沒人愿意看你的代碼，這里應當放一個演示視頻。

談一個技術上有爭議的事，為了實現這個系統，我打造了一個完整的應用框架，完全不同于 Spring,Struts 這些業界流行的產品。參考了 PHP 的松散數據結構，參考了 Spring 的反轉控制，參考了 Python Django 的校驗模型（有四五年沒用了，不知道現在套路變了沒）。而且大量使用集合框架，而很少去構造私有結構，這在部分程序員看來可能是過于松散，有些應該做只讀隔離的卻沒有做封裝。但熟悉 Java 的都知道，反射其實能跳過很多限制，有些隔離封裝就是防君子不防小人。我沒有必要對此上工作的程序員像防賊一樣時刻惦記著，而只要一個約定即可：有些全局的東西你最好別去變更。

不管您認不認同，看在碼了這么多年的份上，請給我 GayHub 上可憐的星星數 ++

再補充一個，知乎上有談到人工智能生成代碼的話題。AI 很火，2018 年火得一塌糊涂，我所在公司的一個兄弟單位也在搞，一下子好像 AI 要統治世界。那么，這里面最讓各路人員不爽的當然是碼農兄弟們了，讓你們做個軟件磨磨唧唧的，如果機器能寫代碼了，那就不需要雇傭程序員了，再也不會跟他們因討論識別手機殼換主題顏色的問題干仗了。可是，如果某個系統的產出是程序代碼，那么他首先的用戶不應該是碼農嗎？如果您的系統是為了解決某些普遍的問題，能生成代碼為什么不直接執行解決問題呢？如果需要生成代碼，那只有一種可能就是那個生成的代碼不夠完善沒法直接應用于終端，需要碼農去微調。

一二十年前的一些 UML 工具箱就能生成代碼，人類似乎太健忘了。5 年前我還在魔都干著互聯網廣告的勾當（所以沒準幾年前您在各網站上瞎點時咱們就產生間接聯系了），也寫過一個小的報告系統，中間會生成報表代碼，原因正是上面說到的，跟各不同報表需求部門扯不清楚，短時間內沒法總結出普適的規則，所以生成腳本代碼，以便在接到特殊邏輯后快速微調。

所以，雖然我認同 AI 的發展方向，并因不能全身進入而為自己的未來感到擔憂；但是，我不認同用 AI 生產代碼是個好主意。承載代碼的是編程語言，而語言就是溝通的橋梁。AI 與 AI 之間可能在未來會產生屬于他們自己的溝通規則，但那不應當是適合人類閱讀的程序邏輯代碼。