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

此文首發(fā)于知乎

Talk is cheap, show me the code.

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

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

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

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

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

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

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

說到轉(zhuǎn)換，我就想到我們師徒四人換取通關(guān)文牒……抱歉抱歉，走錯片場了。

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

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

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

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

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

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

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

這個關(guān)系數(shù)據(jù)庫的描述文件見：默認(rèn)配置，內(nèi)部注釋含寫法；格式描述。

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

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

Lucene 非數(shù)據(jù)庫？此話怎講？阿里搞搜索的人說他們的業(yè)務(wù)部門希望他們的搜索系統(tǒng)像數(shù)據(jù)庫一樣即存即取，印象里他們還專門發(fā)文談到過?？铀麄兌疾冗^了，雖不知道如何跳過去的，但只要知道能過去就行了。所以 Lucene 不但是數(shù)據(jù)庫，還是很好的文檔數(shù)據(jù)庫；需要的話還可以是圖（譜）數(shù)據(jù)庫，Neo4j 底層即為 Lucene，我也有直接用 Lucene 開發(fā)過人脈關(guān)系引擎。

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

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

先把示例文件甩出來：默認(rèn)配置，內(nèi)部注釋含寫法；結(jié)構(gòu)描述。

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

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

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

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

這看起來像一個問卷調(diào)查設(shè)置界面，現(xiàn)工作的一部分恰好也是類似問卷的東西。但側(cè)重點導(dǎo)致了發(fā)力點也不相同。1、這里關(guān)聯(lián)是重要的一環(huán)，而問卷沒有這個需求；2、將結(jié)構(gòu)固定到文件以便微調(diào)，問卷也沒有這個顧慮；3、邏輯流程需要方便定制，并不得對系統(tǒng)整體產(chǎn)生干擾，問卷也沒有這個必要。不過確實可以用此構(gòu)建一個高度可定制的問卷/表單系統(tǒng)，而且有這個計劃。

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

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

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

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

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

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

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

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

現(xiàn)在穿越時空回到過去，定義有什么樣的結(jié)構(gòu)就該有什么的界面，那么從那個表單配置 XML 出發(fā)，通過研究歷史的界面和操作流程，進(jìn)行總結(jié)并將過程固定下來，形成映射關(guān)系，就自然可以產(chǎn)生操作界面了。

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

當(dāng)超越時間去看待問題，一切過程都是結(jié)構(gòu)。

TODO：沒人愿意看你的代碼，這里應(yīng)當(dāng)放一個演示視頻。

談一個技術(shù)上有爭議的事，為了實現(xiàn)這個系統(tǒng)，我打造了一個完整的應(yīng)用框架，完全不同于 Spring,Struts 這些業(yè)界流行的產(chǎn)品。參考了 PHP 的松散數(shù)據(jù)結(jié)構(gòu)，參考了 Spring 的反轉(zhuǎn)控制，參考了 Python Django 的校驗?zāi)Ｐ停ㄓ兴奈迥隂]用了，不知道現(xiàn)在套路變了沒）。而且大量使用集合框架，而很少去構(gòu)造私有結(jié)構(gòu)，這在部分程序員看來可能是過于松散，有些應(yīng)該做只讀隔離的卻沒有做封裝。但熟悉 Java 的都知道，反射其實能跳過很多限制，有些隔離封裝就是防君子不防小人。我沒有必要對此上工作的程序員像防賊一樣時刻惦記著，而只要一個約定即可：有些全局的東西你最好別去變更。

不管您認(rèn)不認(rèn)同，看在碼了這么多年的份上，請給我 GayHub 上可憐的星星數(shù) ++

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

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

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