如何理解編輯器思維與系統設計思想

這篇文章主要講解了“如何理解編輯器思維與系統設計思想”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解編輯器思維與系統設計思想”吧！

前言

與人類社會的歷史相比，計算機的歷史非常短暫，上世紀五、六十年代都能稱為遠古時期了。但計算機的歷史又很神奇，早期的思想往往都很超前、很先進。比如EJB技術雖然是1998年提出的，但它的設計很超前，諸如微服務等后面出現的技術都或多或少借鑒了它的思想。通過了解計算機技術的發展歷史，往往能從中找到很多有創意的想法，能幫我們解決當下的問題。所以，今天想來掰扯一下Emacs和Vim這兩款經久不衰的老古董軟件的歷史八卦，看看有沒有值得借鑒的地方。

Vim的八卦

Vim族譜

首先從Vim編輯器的起源說起，下圖Vim的族譜：

Vim的前身是ed編輯器：

• ed是UNIX系統上最古老的程序之一，從第一版本開始就入駐了，作者是Ken Thompson（UNIX作者之一）。它提供了面向行（Line）的基本編輯命令。

• ex是ed的超集，是Bill Joy（Sun公司創始人之一）在開發BSD時增強了ed，于是取名叫ex。但ex仍然是面向行的編輯器。

• Bill Joy后續又為ex提供了可視化界面（Viusal Interface），提供全屏編輯能力，因此命名為vi。

• 為了將vi移植到Amiga機器，Bram Moolenaar開發了Vi IMitation（Vi仿制品）。隨著功能的不斷增加，名字也升級為Vi IMproved（Vi改良版），即Vim。

ed編輯器

ed與VSCode、Sublime Text等現代編輯器有很大不同，如前文所說，它是一款行編輯器（此處已幫大家劃重點），即編輯的對象是一整行文本。

ed分命令模式與編輯模式。啟動ed后，默認進入命令模式，等待用戶輸入一條條命令。ed通過執行這些命令，最終達到編輯文件的目的。使用Mac電腦的同學可以試試在終端里執行ed。ed命令的格式是[尋址][命令]：

• 尋址：選中待操作的目標行。ed提供了三種尋址方法：行號：從1開始的整數；$代表最后一行。模式：選中與正則表達式匹配的行。默認從當前行開始，選中第一個匹配的行。如/re/。添加前綴g，則做全局匹配。如g/re/范圍：由兩個地址組成的尋址范圍，[地址],[地址]。如/BEGIN/,/END/

• 命令：用單個字符表示。以下是最常用的命令：p：展示，輸出目標行。i：插入，將內容插入到目標行的上一行。a：追加，將內容追加到目標行的下一行。c：更改，替換目標行的內容。d：刪除，刪除目標行。s：替換，用正則表達式替換匹配行內容。

其中i、a、c命令會使ed從命令模式進入編輯模式，在編輯模式中輸入一行.則返回命令模式。以下是ed編輯的幾個示例：

• 刪除所有空行：g/^$/d。用前綴g全局搜索正則表達式/^$/，并執行刪除命令。

• 輸出所有包含“re”的行：g/re/p。同樣全局搜索正則表達式/re/，并執行展示命令。因為該功能實在太常用了，所以還特地開發了一個命令“grep”。

編輯器思維

如前文所說，ed編輯器與現代編輯器很不同，它其實是一個編輯命令解釋器；但ed編輯器又與現代編輯器很相同，所有編輯器的本質都是在不斷執行“尋址”與“命令”，不同類型編輯器之間的差異只是編輯的對象不同：

• ed是文本行編輯器：編輯的對象是文本行。

• Microsoft Word是文檔編輯器：編輯的對象是章節、段落、詞句等文檔元素。

• Sketch是圖形編輯器：編輯的對象是點、線、面等圖形元素。

• IntelliJ IDEA包含Java代碼編輯器：編輯的對象是類、方法、語句等Java語義元素。

• jQuery是DOM編輯器：編輯的對象是DOM元素。先用CSS Selector尋址，選中要處理的DOM元素；再用連綴表達式執行一系列編輯動作。

• ……

由此可見，編輯器思維無處不在，只要符合“尋址+命令”模式都可稱作編輯器，因此萬物皆可編輯！編輯器思維或編輯的本質，用開發者更熟悉的話術來講就是CRUD：

若以后有人質疑開發同學只是在做簡單的增刪改查，請勇敢地告訴他們：其實我是在做一個垂直領域的編輯器！

若意識到自己在做的其實是一個編輯器，就能利用編輯器思維快速發現系統能力的短板。以商品管理系統為例，若商品管理只提供通過ID查詢商品的功能，就猶如ed編輯器只支持用行號來尋址一樣，使用就非常不方便，可以借鑒ed通過正則表達式的模式匹配尋址能力，提供通過商品名稱等信息來匹配商品、甚至通過商品照片來匹配相似商品的能力；類似的，創建商品能力也可以借鑒編輯器復制粘貼的能力，提供用相似商品快速新建商品的能力，甚至還可以提供從其他平臺搬家的能力。

ed的族譜

前文只介紹了ed交互式編輯的功能，其實ed還支持腳本化編輯，就是將輸入到終端的編輯命令保存成一個腳本文件，供后續反復運行。好處是可以用相同的編輯命令批量編輯任意多個文件。

上圖是ed編輯器的族譜，后續的衍生程序都是選擇并增量了ed的部分能力。比如：

• ex、vi、vim這條分支選擇了交互式路線。

• grep、fgrep、egrep選擇了模式匹配路線。

• sed、awk選擇了腳本化路線。

Emacs的八卦

從Vim陣營叛逃

我曾經是一名Vim重度用戶，因為在大學利用的操作系統是Debian Linux，無論是寫C代碼還是Java代碼，都是在Vim里一把梭。好處是閉卷筆試時可以直接默寫，而用Eclipse的同學基本是記不住JDK API的全名。:-p

畢業后進了一家外企，不得不開始使用Windows XP系統，某天在記事本里寫東西，發現自己會經常無意識地按一下Esc鍵。用過Vim的同學肯定知道，這是在切換模式。這我意識到：Vim這種多模式的設計非常反人類。Vim啟動時默認進入的不是編輯模式，當新手用戶什么都還沒學會時，他沒辦法把Vim當成普通的記事本來用。曾有一則關于Vim的笑話，說如何獲得一串隨機碼，答案是讓Vim新手嘗試退出Vim。

這種方式不符合我的口味，我嘗試去尋找新的編輯器——當什么都沒學會的時候，可以當成最普通的記事本來用；當需要高級功能時，再通過快捷鍵等方式呼喚出來。結果發現Emacs恰好符合這個要求，所以從2010年開始我就從Vim陣營叛逃到了Emacs陣營。我認為這個使用方式的差異是Vim與Emacs最本質的區別：Vim會強迫用戶從一開始就按照它的規則來做事情；而Emacs則相對不需要過多前置知識。網絡上曾流傳過一張編輯器的學習曲線，還蠻貼切的：

Emacs的起源

Vim的前身ed源自UNIX系統，而Emacs的前身TECO源自UNIX系統的前身——Multics系統。

上世紀70年代，GNU的創始人Richard Stallman在MIT的AI實驗室打工時，發明了TECO編輯器，運行在PDP-10機器上。與ed類似，TECO也是命令解釋器——接收并執行編輯命令——并且也采用單個字符作為命令名稱，比如“l”是移動一行，“5l”是移動5行。MIT那群大佬們想用TECO命令完成一些復雜的編輯工作，于是加入了分支判斷、循環等功能；但由于先天不足，TECO最開始設計的時候，沒有把命令設計成一套完備的編程語言，導致后續改進也很困難，比如命令名稱只能是單個字符，很快字符就不夠用了。

所謂基礎不牢地動山搖，大伙兒都認為需要用一套嚴謹完備的編程語言替代TECO的半成品腳本語言。于是有一位叫Bernie的教授在Multics系統上用MacLisp重寫了TECO，并命名為Emacs，還為它寫了詳細的手冊，教大家如何擴展這個編輯器來滿足自己的工作需要。結果，這個版本的Emacs取得巨大成功，連Bernie的秘書——一個號稱自己不懂編程的人——都在照著手冊，有模有樣地寫Lisp代碼來擴展編輯器功能。這件事兒在實驗室引起轟動后，Bernie為此做了一個總結：如果有一個應用——一個能幫你做點有用事情的程序——內嵌了Lisp，并且能通過Lisp程序擴充它的功能，對于學習編程而言，這是一種非常不錯的入門方式！那些自認為不會編程的人，這種方式會給他們編寫小但有用的程序的機會，讓他們在實踐中不斷成長，直到他們發現自己就是在編程。

Stallman他們覺得這個想法簡直屌炸天！同時他們想把這個好用的Emacs版本遷移到Multics系統之外的其他系統，但當時只有Multics系統上有完備的Lisp環境——既有編譯器又有解釋器——諸如UNIX等系統上都沒有。

這里還有一個小插曲，Java之父James Gosling當年還寫了一個能跨平臺的Emacs版本，叫Gosmacs。本來社區想來一起完善這個版本，結果Gosling把它賣給了一家商業公司，同時它底層的Lisp不是一個真實完備的Lisp，而是一個叫Mocklisp的假Lisp，只是語法上和Lisp長得像而已。所以社區最終放棄了這個選項，決定從頭開始做一個全新的Emacs，也就是GNU Emacs。Stallman先用C語言開發一個跨平臺的Lisp解釋器——Emacs Lisp，再用Lisp實現編輯邏輯。這樣既能在所有平臺上用統一的Lisp方言來寫Emacs擴展，又能兼顧性能。

GNU Emacs有一段時間發展比較之后，因為Stallman自己一個人忙不過來，所以社區又創建了一個分支叫XEmacs，增強了字體抗鋸齒等功能。后來GNU Emacs的維護又變得積極了，把很多XEmacs的特性合并回GNU Emacs，所以現在XEmacs差不多是廢棄狀態，主流版本還是GNU Emacs。

系統設計

編輯器圣戰

程序員的世界里充滿了鄙視鏈，有編輯器鄙視鏈、編程語言鄙視鏈、操作系統鄙視鏈……為什么這些圣戰永遠打不完，到底是像《格列夫游記》里小人國因爭論剝雞蛋先打破大頭還是小頭而發動了戰爭，還是真的魚和熊掌不可兼得？

前文提到，Vim喜歡強迫用戶按照它的套路來做事。Vim從ed繼承了行編輯器的特性，底層模型是基于“行”的，所以會強行要求所有被編輯的對象適配成它的底層模型。你用Vim寫Java代碼，你編輯的是文本行；你用Vim寫一篇博客，你編輯的是文本行；你用Vim寫一篇論文，你編輯的還是文本行；無論你編輯的是類、函數、段落、目錄還是任何其他內容，都要先在腦海中翻譯成對應的dd、yy等面向行的編輯命令。

Emacs則是允許用戶先把Emacs改造成目標對象的個性化編輯器，能認識目標模型，比如段落、章節、目錄等。用一句時髦的話講就是Emacs有行業Know-How。同樣的例子：用Emacs寫Java代碼，你編輯的是類、方法、語句……；你用Emacs寫一篇博客，你編輯的是段落、句子……；你用Emacs寫一篇論文，你編輯的是目錄、章節、正文、索引……。

兩種設計方法

造成上述差異的原因是背后兩種不同的設計方法，分別稱作自頂向下（Top Down）與自底向上（Bottom Up）：

方法自頂向下自底向上描述將大任務逐級拆分到顆粒度合適——足夠小、又能做些實際的事情——的小任務完善底層編程語言等——讓底層基建不斷逼近業務領域——來適應任務優點難度較低，目標明確，迭代快速功能完整，適應性強缺點與當前需求耦合過緊，應對變化能力稍弱難度較高，進展較慢

用Vim編輯屬于自頂向下方法——將編輯任務持續拆分，最終拆解到面向行的編輯命令；就像Java日常開發，會逐級拆分，最終拆解到JDK的API。用Emacs編輯屬于自底向上方法——先完善底層Emacs Lisp語言，逐步抽象出面向業務的領域特定語言，最終用DSL完成編輯任務；例如要編輯Markdown文檔，就會提供諸如移動到下一個段落、下一個列表項、表格下一個單元等面向Markdown領域的特定編輯操作。

這兩種設計方法的差異并不意味著只是換個順序寫代碼，而是系統抽象過程的差異，最終體現在系統擴展性的差異上。我個人把系統的可擴展分成4個等級：

• 硬編碼：系統運行時，數據和行為都已寫死，不能變化。

• 可配置：系統運行時，數據可動態變化，但行為固定不變。

• 可控制：系統運行時，數據可動態變化，并且由多種預定義的行為可供動態選擇。

• 可編程：系統運行時，數據可動態變化，同時行為可在運行過程中動態新增，即用戶可重新系統行為。

自頂向下的極端是硬編碼，會過早地把功能限制在當前的需求里，后來的需求只能盡量逼近初始模型；自底向上的極端是可編程，容易過渡設計，為未來不可能變化的場景提供靈活性，甚至會變成一門通用的編程語言。

兩種設計方法沒有絕對的對錯，都有各自適用的場景，單一地采用任何一種方法都會有問題，需要根據實際情況在快速實現和系統擴展性之間做權衡。也正因為沒有對錯之分，所以編輯器的圣戰永遠也打不完。

感謝各位的閱讀，以上就是“如何理解編輯器思維與系統設計思想”的內容了，經過本文的學習后，相信大家對如何理解編輯器思維與系統設計思想這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！