福源碼

㈠ 企業級快速開發平台哪家更好

這周我差不多花了兩個半天的時間進一步研究了下網上的低代碼開發平台，也就是原來我們經常說的快速開發平台。研究這個的一個主要原因就是我們看到在新的微服務，DevOps，ServerLess技術，前端新技術的發展趨勢下，低代碼開發在時隔多年後被再一次的提起。

在微服務和雲原生解決方案不斷發展的情況下，我們看到當前的雲服務已經從最傳統的彈性計算和存儲能力，提升到了我們常說的PaaS平台層，即提供更多的類似消息，緩存，資料庫，中間件，安全，大數據平台等平台層服務能力。

那麼我們接著能夠考慮的就是再平台層足夠強大後，我們的開發能否進一步更加簡化，能夠實現無代碼或少量代碼就能夠完成一個功能的開發和朝雲端的部署上線。比如我們現在看到的亞馬遜的公有雲提供的ServerLess就是一個典型的場景。你只需要寫少量的配置文件或函數方法，就能夠完成一個類似網頁爬蟲，信息搜索，圖片存儲等互聯網功能。

第一：傳統的快速開發平台

為了搞清楚低代碼開發，我們可以看下在原來我們經常提到的快速開發平台。對於原來我們談的快速開發平台，我想可以初步分為兩種典型的類型。

1. 面向業務人員：完全不需要開發經驗，不用接觸代碼。典型是類似各種BPM高度流程表單可定製產品。

2. 面向技術人員：提供快速開發平台和工具，比如代碼自動生成，功能大部分可配置+腳本編寫模式。

對於面向業務人員方式的平台往往就是一個高度靈活的空平台，所有的對象，數據，流程，規則，許可權等你都可以隨意的配置和定製。類似各類BPM產品，但是實際上可以看到這類產品無法開發規則業務復雜的系統。

對於面向技術人員的快速開發平台，類似我們常說的普元，JeeSite， JEPaaS，起步 科技 的PaaS平台等都屬於這種類型。但是這種類型的平台本身又細分為了兩種，一種是僅僅輔助開發和代碼生成，即所有的開發內容都生成代碼，脫離開發平台環境也能夠成功運行；還有一種就是強綁定，平台很大內容不生成代碼，對你黑盒，無法脫離環境運行。

我原來比較強調技術開發類平台是否提供源代碼，是否進行強綁定，但是最近思考了下這個反而不是重點，真正重要的還是這個平台對各類場景，各類業務需求下的通用模式抽象能力，這個將直接影響到平台本身的好壞。比如一個平台本身黑盒無法擴展，但是你的業務場景又很難配置出來，那麼整個平台的可用性就大大的打折扣。

其次，對於一個快速開發平台，我們可以有一個重要結論：

你對不同業務，不同場景下的通用性適配能力越強大，那麼你實際運行的黑盒代碼性能就越低。

也正是這個原因，我們看到很大快速開發平台代碼臃腫，性能低下，你開發的時候速度倒是快了。但是後續系統的性能完全跟不上，也無法擴展，這些都是要命的問題。

第二：從傳統快速開發到低代碼開發平台

為了進一步談我自己對低代碼開發平台的理解，我先引用下網上對低代碼開發的一些定義和說明。

低代碼開發平台是無需編碼（0代碼或無代碼）或通過少量代碼就可以快速生成應用程序的開發平台。它的強大之處在於，允許終端用戶使用易於理解的可視化工具開發自己的應用程序，而不是傳統的編寫代碼方式。構建業務流程、邏輯和數據模型等所需的功能，必要時還可以添加自己的代碼。完成業務邏輯、功能構建後，即可一鍵交付應用並進行更新，自動跟蹤所有更改並處理資料庫腳本和部署流程，實現在 IOS，Android，Web 等多個平台上的部署。

低代碼開發平台(LCDP)英文全稱為Low-Code Development Platform,一個顯著的特點是，更多的人可以參與到應用程序開發當中，不僅是具有專業編程能力的程序員，非技術背景的業務人員同樣可以構建應用；對於大型企業來講，低代碼開發平台還可以降低IT團隊培訓、技術部署的初始成本。

從這個定義上面我們可以找到一些關鍵點，簡單總結來說就是

1. 少量代碼或者無代碼，業務人員也能參與

2. 提供可視化，可配置的工具進行配置和建模

3. 可同時發布到多個平台或終端

4. 提供和雲端的持續集成和發布能力，可持續交付，即我們常說的DevOps

對於低代碼開發平台和快速開發平台區別，實際我想強調一個重點，我個人認為很重要，即：

低代碼開發需要實現從最早的以資料庫對象建模方式轉變為服務化建模方式。

傳統的快速開發平台不論是表單或流程涉及，更多的還是圍繞資料庫為核心進行，建立的對象可以生成資料庫。相關的表單操作也圍繞資料庫進行。

而在低代碼開發時代，我個人更加推薦一個轉變，就是基於對象服務化的分層開發模式。這個本身也是更加貼近我當前中台和微服務的構建思路。即你首先去構建你的對象並發布你的服務，然後再考慮如何基於這些發布的服務類構建上層的應用。即我們的開發過程橫向拆分為兩端。而中間基於服務進行松耦合連接。

即：微服務 + 服務 + 前端應用。

不是簡單的我們傳統應用拆分小了，而且我們的前端應用模塊，後端能力模塊也全部微服務化，形成我們當前說的平台+中台+前端應用的分層模式。這種模式如果再和我們當前的DevOps和容器化技術結合，那麼整個開發完成的應用就更加容易持續發布和交付，也更加容易在後續繼續彈性資源擴展和調度。

目前國內做得最好的電商企業就是天貓和京東了，電子商務行業市場仍然處在「有利可圖」的局面，很多創業者通過定製開發電商網店系統來得一塊蛋糕。電子商務商城網站開發技術日益成熟，部分擁有專業級商城網站開發技術的外包公司可以在短時間內幫助電商企業定製一個完善功能的網店系統，下面跟隨數商雲我來了解下網店系統開發什麼？

商城網站搭建就是網上商城系統開發，是一個可以快速創建商城網站的系統。電商平台開發公司數商雲在電商網站開發行業擁有豐富的經驗，開發的網店系統擁有傻瓜性的操作特性，可以幫助用戶順利通過輕松的方式快速搭建自己的獨立網上電子商務平台。

就目前國內較為主流的網店系統開發語言來說，使用PHP、JSP和ASP語言開發的網店系統占據了80%以上，並且隨著電子商務發展呈現出良好趨勢，國內的電商網店系統開發商如雨後春筍一般涌現。然而要說電子商務系統開發業界擁有比較好口碑的商城系統就不能少了數商雲開發的電商系統擁有最豐富功能的網店系統，以及海量的網站商城開發模板和豐富的內頁設計以供企業選擇，是一個真正意義上的免開發、免設計的商城系統開發軟體，可以滿足許多企業和個人創業者對商城網站或者是網店功能的開發需求。

數商雲電商網站平台開發公司致力幫助企業商家和個人創業者花小量的投資，快速搭建專業的全網營銷型電子商務商城和APP商城，電商平台解決方案以最快的速度達成產品的銷售渠道和企業品牌的強化，幫助電商企業在創業過程實現多樣化渠道營銷同步。

下面這個是用odoo開發的，算是迷你sap財務，多機構，對賬簿，任意核算項目，開源可擴展

JABDP是一款基於引擎模式的web快速開發平台，並採用新穎的低代碼的在線開發部署模式，使開發變得更加簡單、純粹，減少web開發中80%的代碼量，革命性的提高了開發的效率。常用的功能，例如表單列表的增刪改查，只需簡單的自定義和配置就能自動生成。復雜的業務功能，只需要會基本的sql語句和javascript語法，就能進行快速開發，滿足其個性化的業務需求，設計出各種復雜的企業web應用。既能快速提高開發效率，幫助公司節省人力成本，同時又有效解決企業級項目中常遇到的改需求的問題，不失靈活性。JABDP開發平台適合用於大部分的企業級web應用的開發，尤其適合企業信息管理系（MIS）、企業資源計劃系統（ERP）、客戶關系管理系統（CRM），業務支撐系統（BSS）等。並且就一些經典的項目案例提取整合出各種類型的項目模板，共享給開發者參考，開發者可以在原有的項目基礎上進行修改定製，以打造其個性化的企業信息化平台。JABDP平台有如下特點：

真的是幸福的煩惱呀，根據我們情報資料庫監控顯示，國內快速開發平台廠商已經多達112家，並且還在擴增當中！

根據筆者的觀察，雖然都叫快速開發平台/低代碼開發平台，但各家的設計理念和業務擅長相差是很大的：

1、擅長數據填報分析：這類快速開發平台大多採用類excel技術，擅長表單和報表，例如魔方網表、活字格、簡道雲、雲表、狐表....很有趣哈，大多數名字後面都帶一個「表」字；

2、擅長復雜業務流程：這類快速開發平台大多基於BPM流程管理平台衍生，對流程引擎的打磨較為專業，java領域的廣州天翎、.NET領域的上海易正是我比較看好的代表；

3、擅長網站/APP/小程序定製：起步牛刀雲、廣州迪西克、深圳世雲IVX的產品可以體驗一下。

更多低代碼平台選型話題歡迎多多交流~

可以用我們公司開發的企業管理平台，郵件管理，客戶管理，工廠管理，產品管理，報價管理，訂單管理，采購管理，驗貨管理，出運管理，付款管理，發票管理，庫存管理，審批管理，投訴管理，請假管理，報銷管理，車輛管理，人事管理，資產管理，業績考核，等等功能都是現成的，還支持快速的二次開發，有興趣可以聯系我。

這個是開源的，可以看看

Jeecg-Boot 是一款基於SpringBoot+代碼生成器的快速開發平台！採用前後端分離架構：SpringBoot，Ant-Design-Vue，Mybatis，Shiro，JWT。強大的代碼生成器讓前端和後台代碼一鍵生成，不需要寫任何代碼，保持jeecg一貫的強大，絕對是全棧開發福音！！ JeecgBoot在提高UI能力的同時，降低了前後分離的開發成本，JeecgBoot還獨創在線開發模式（No代碼概念），一系列在線智能開發：在線配置表單、在線配置報表等等

勤哲就挺好，別看它簡單易用，但是功能極其強大，它可以幫助企業管理者自主構建信息系統，很不錯

分享個開源項目的技術棧

推薦個git上開源的快速開發項目，項目採用微服務為基礎的腳手架，包括流程、表單、列表、圖

表、應用等多個界面化的配置引擎。

項目介紹：

項目標簽

低代碼、微服務、支持SaaS、私有化部署、DevOps、

開源項目地址

體驗地址：http://frame.bctools.cn/#/login

登陸可以通過微信掃碼登陸，對於配置數據，請各位技術同學手下留情。

部署文檔
https://gitee.com/software-minister/jvs-docker-compose/blob/master/readme.md
**物理拓撲：

技術文檔地址（微信登陸可查看）：

技術棧說明：

系統部分截圖：

登陸頁面

配置化首頁

系統基礎信息設置

框架基礎功能

應用創建

列表配置

流程配置

表單配置

圖表配置

邏輯配置

㈡ 如何查找網頁的源代碼

一、安裝和界面

Instant Source是專為IE開發的插件，所以，安裝後你在開始菜單找不到啟動它的程序。它整合在IE中，如果在你的IE瀏覽器工具欄上沒有發現它的圖標，可以通過「查看→工具欄→自定義」添加。

點擊IE瀏覽器工具欄上的Instant Source圖標，如圖1所示，Instant Source會在IE窗口的下面露出它的真面目，Instant Source幾乎所有的功能，都要通過整合在IE中的這個窗口才能完成。
二、查看源代碼

Instant Source提供了多種源代碼的查看方式，它可以查看整個頁面的源代碼，也可以查看選定文本的源代碼，甚至還可以查看滑鼠所指網頁元素的源代碼。點擊工具欄上的「顯示」按鈕，如圖2所示，在菜單上選擇「滑鼠所指元素」，這樣，在IE中，滑鼠所指網頁元素的源代碼就實時地顯示在Instant Source窗口中了。
三、編輯源代碼

首先需要說明的是，Instant Source對網頁源代碼的編輯，只適合於本地的HTML網頁文件。

在IE中打開一個本地網頁文件，在圖2中選擇「整個頁面（原始）」，這時，你會發現，在Instant Source工具欄上的「應用」按鈕已變為可用狀態，現在，你就可以在Instant Source窗口中編輯該網頁的源代碼了。編輯完成後，點擊「應用」，Instant Source會自動保存該網頁並在IE中實時顯示。這一功能，對於那些習慣於使用源代碼編輯網頁的朋友，無疑是一大福音。

四、保存外部對象

在IE中打開「新浪網」首面，在Instant Source工具欄上點擊「對象」，打開「頁面對象」對話框，你看到了什麼？沒錯，「新浪網」首頁中鏈接到的所有外部對象，包括圖像、Flash電影、js腳本、樣式表以及鏈接到的其它網頁文件都一覽無余
選定一個對象，點擊對話框上的「查看」，可以在默認的瀏覽器中打開該對象；點擊「保存」，可以在本地保存該對象，當然了，點擊「保存全部」，可以保存所有對象；點擊「復制URL」，可以把選定對象的絕對地址復制到剪貼板。不是有很多朋友老問我，怎樣才能保存網頁上的Flash動畫嗎，今天把這個軟體介紹給你，希望再不要問我這樣的問題。

在Instant Source的窗口中，我們可以復制選定的源代碼，也可以點擊工具欄上的「查找」，在網頁源代碼中查找你需要的內容。總之，Instant Source是一款對網頁製作愛好者非常實用的工具，對於其它網民，你也可以利用它查找並保存網頁上的資源。

㈢ 虛擬貨幣的開源代碼時什麼意思

你說的那是加密數字貨幣，源代碼子在開源的網站可以查詢。也可以去比特幣基金會的官方網站去查詢比特幣的源代碼。

網路虛擬貨幣大致可以分為
第一類是大家熟悉的游戲幣。在單機游戲時代，主角靠打倒敵人、進賭館贏錢等方式積累貨幣，用這些購買草葯和裝備，但只能在自己的游戲機里使用。那時，玩家之間沒有「市場」。自從互聯網建立起門戶和社區、實現游戲聯網以來，虛擬貨幣便有了「金融市場」，玩家之間可以交易游戲幣。
第二類是門戶網站或者即時通訊工具服務商發行的專用貨幣，用於購買本網站內的服務。使用最廣泛的當屬騰訊公司的Q 幣，可用來購買會員資格、QQ秀等增值服務。
第三類互聯網上的虛擬貨幣，如比特幣（BTC）、福源幣（FTC）、萊特貨幣（LTC）等，比特幣是一種由開源的P2P軟體產生的電子貨幣，也有人將比特幣意譯為「比特金」，是一種網路虛擬貨幣。主要用於互聯網金融投資，也可以作為新式貨幣直接用於生活中使用。

㈣ 國內外低代碼開發平台發展情況

本文會分析：

國外：Mendix Outsystems

國內：牛刀 APICloud iVX 搭搭雲 氚雲 簡道雲 雲表 宜搭雲等幾傢具有代表性的公司

其實，低代碼概念由來已久，其實就是「追求少的代碼量，完成最多的開發工作」，不管是開發代碼的工具還是代碼本身都在追求「低代碼」。這裡面比較難的是如何把握「功能靈活性」和「操作學習簡易性」的平衡。

評價「低代碼」的標准：能做什麼？效率如何？（拋開這兩點，都是扯淡）

一、能做什麼？：主要看邏輯是如何實現的？（特別是工具側的邏輯實現能力，用代碼實現的不算，因為都可以）靈活性如何？

（1）流程圖方式：例如：Outsystems是通過流程圖的方式來生成邏輯代碼部分，他們內部叫做「MicroWave」「NanoWave」，用來分別控制前端和後台的邏輯。這種方式採用公司較多，操作企業對於大型應用還是挺難的，畫圖這個事對於大應用來講也不好操作。

（2）事件觸發式：例如：iVX（國內的公司），用觸發式的事件面板來控制所有交互邏輯。開發起來還是體驗不錯的，只有他們一家公司這么做。

二、效率如何？

這個就要看整個產品設計理念，開放程度，組件抽象，開發配套，對復雜前後台支持程度。整體來說，綜合能力算上，Mendix 、Outsystems 、iVX這三家開發效率最高，如果是算細分領域，例如，就開發一個表單，或開發一個工作流系統，那搭搭雲、氚雲做的都不錯。

下面我們看國內外的「低代碼」發展情況

一、國外情況

近兩年，隨著各種技術整體發展（例如，5G，我不相信有技術是可以完全獨立存在和發展的，特別是新技術），不管程序員如何努力，瓶頸卻變成了程序員本身。對各種應用的需求越來越大，但是程序員總量有限，培養難度大，應用開發周期長，應用維護成本高，這個矛盾成為了技術和市場發展的主要矛盾，「低代碼」概念就是為了解決這個核心問題而生的。「風口」也慢慢指向了「低代碼」這一塊兒。

國外的幾家低代碼公司：Salesforce，Mendix，Outsystems，Appian，Joget

（1）進入時間和領域：

這些公司大都成立10年以上，有些都快20年了，這些企業基本上都是從企業應用開發開始做，重點在：表單生成和處理、工作流生成和管理、辦公協作這幾個領域。還有的是從更專業的企業領域進入「低代碼」的，例如財務領域、HR領域、CRM領域等。

結論：低代碼短時間是出不來的，要大量的積累和研發，特別是和企業的磨合非常重要。

（2）已經比較成熟：

Salesforce Appian Joget這三家都已經上市，另外兩家都是估值10億美元以上的獨角獸公司。

（3）服務和價格：

都非常貴！主要服務大公司500強為主，一個license月都要幾千美元。

二、國內情況

國內比較講究「風口」，這個風口是2019年才吹過來的，所以有挺多新興創業團隊加入「低代碼」陣營，也有一些「老牌的」團隊轉向這個市場。其實主要看他們以前是做什麼的？這個對大家理解團隊和能力會很有幫助。

按成立時間

老牌團隊（10年以上的）：牛刀（以前做前端開源框架WeX5），APICloud（以前做App開發打包工具和API模塊市場，嚴格意義上不算低代碼工具，算是開發流程管理工具，還涉及到產品、設計、代碼管理、項目管理等領域，我就不細說了），iVX（之前做H5、WebApp開發工具的），活字格（利用微軟的Excel開發體系，進行二次工具化）

新進團隊：「各種」雲，但主流都是「表單」「工作流」「協作」這三種出生為主，太新的團隊，我覺得做不了這個，因為「低代碼」還是研究比較底層技術的領域，太短時間積累不出來。

另外按功能分類：

（1）靈活性從高到低 （很多**雲，是細分領域開發的，靈活性較差就不放進來了）

iVX ***** 活字格 *** 牛刀 *** 氚雲 **

（2）對工作流支持從高到低

搭搭雲 **** ClickPaaS *** 氚雲 *** iVX *** 宜搭雲 **

（3）對表單支持從高到低（這個上面幾家都不錯，可能是低代碼的基礎，我就不比較了）

另外，我發現iVX是低代碼中比較特殊的，因為，實際上它的開發過程基本上是「0代碼」環境的。開發效率和維護也比較容易，而且前身版本是iH5，口碑還不錯，大家可以重點關注一下。

宜搭雲，是阿里雲親生的，現在雖然剛起步，但是至少說明有巨頭已經開始關注這個賽道了，大家也可以持續關注一下。

總體來說，「低代碼」發展方向還是非常看好的，畢竟是解放生產力的，但是要做好難度比較大，而且需要長時間的積累。

㈤ 什麼代碼編輯器比較好用

著名的代碼編輯器：Microsoft Visual Studio Code、Github Atom、Sublime text、Adobe Brackets

最推薦的一種：Atom

推薦理由：

鏈接：如何評價 GitHub 發布的文本編輯器 Atom？

作者：韋易笑

用過不少編輯器：UltraEdit / EditPlus / (G) Vim / GEdit / NotePad++ / TextMate / ProgrammerPad / Sublime 。確實是工作上用他們寫過代碼的。而 VSC / Emacs 只是體驗了一下基本使用方法，算不上真用。用下來的結論是：Atom 比 Vim 更 Vim，比 Emacs 更 Emacs，同樣，比 Sublime 更 Sublime。

Atom 唯一的槽點就是「卡」，不過那是去年的情況了，1.0後性能數次大提升，比起sublime/vsc之類雖不算流暢，但同時編輯20個數千行的文件沒有壓力。如今讓人感覺慢的地方主要是啟動loading（也大大短於eclipse, idea），使用時並沒察覺它比其他編輯器慢再哪。而文本編輯器的快慢，更重要的是「讓你工作更快更有效率」。下面說說為何 Atom比其他更有效率：

兼容VIM模式

這無疑團結了一大班 Vim過來的用戶，Sublime雖然也有VIM模式，但是Sublime在 mac下面的vim模式有bug，我習慣用 hjkl來移動游標，sublime再mac下hjkl移動有問題，且我習慣CTRL_[來返回NORMAL，手指不離開主鍵盤區，而sublime的vim模式只支持ESC返回，加上其作者經常神秘消失，最穩定的2.x版本已三年沒有更新，這些問題一直得不到修正。

由於Atom的定製程度直追 Vim/Emacs，它的vim模式能夠使用插件來實現，而不像sublime必須builtin，Atom的VIM模式除了官方實現外還有很多用戶實現，各有所長，你不喜歡可以換，Sublime就傻逼了，覺得builtin的不行，你就沒辦法了，而且作者不更新你也沒辦法。

Atom里的Vim模式並不是強制的，你可以用也可以不用，這樣入門用戶也不會覺得困難，但是如果你用慣Vim的話，使用Vim模式可以取得更好的效率，我覺得Vim/Atom-VimMode能夠提升效率的地方有以下三方面：

1. 手指不離開主鍵盤區：

所有功能皆能在主鍵盤區完成，不用去按方向鍵，不用把手挪去按Home/End，更不用動滑鼠。就像詠春中強調中線理論，認為一切動作圍繞中軸線開展，守護自己中軸線的同時攻擊別人的中軸線。Vim/Atom-VimMode中，雙手不但從不離開主鍵盤，並且八根手指隨時守護再HOME位（ASDF, JKL;）有動作就移動，然後馬上歸位。

2. 細粒度微操作：

星際/dota玩的好，微操基本功，微操又快又精確，Vim/Atom-VimMode一樣，比如：

if (xxxx) {}

很多人編碼時習慣「成對編碼」，寫了申請資源的代碼，先把釋放資源寫了，寫了左括弧，先把右括弧給補充完，當你寫完第二行代碼時，需要用到「再1-2行中間插入一行」，此時你的游標停留在第二行，傳統編輯器你需要：按上箭頭移動游標到第一行 -> 按END鍵去到第一行末尾 -> 按回車插入一行，mac下的END鍵還需要用CMD+右來組合出來，而Vim/Atom-VimMode中，你只需要shift+o即可，手指完全不離開主鍵盤區，不用像傳統編輯器那樣，右手先移動到箭頭區又移動到HOME的小鍵盤區，再移動回主鍵盤區這么麻煩，類似還有：

使用o直接再下一行插入，避免 END/回車

使用I再行首插入，避免移動半天游標。

向前/後移動一個單詞到單詞頭、尾。

快速更改當前單詞，用/來快速搜索移動游標。

dd+p來快速移動代碼塊，取代shift+方向鍵半天。

shift-j 來兩行合並成一行，代替 HOME, back 若干次。

。。。

你再編輯代碼的時候，90%的情況可以直接一步完成，這就叫細粒度微操，而且整個過程手都不需要離開主鍵盤，不像傳統編輯器那樣，若干笨重的操作組合再一起，操作不夠細步驟多的同時手還要再：主鍵盤區，方向鍵區，擴展鍵區 來回移動，效率奇低。而Vim/Atom-VimMode下，手指隨時守護在home區（ASDF JKL；），所有微操都是圍繞HOME區進行，不會移動到任何主鍵盤以外的區域，更別說用滑鼠、觸摸板。

3. 批量操作：

比如要給下面代碼每行後面加一個分號：

var x = 1var y = 2var z = 3console.log('result is ' + (x + y + z).toString())

一般做法是：移動游標到行末->END->分號->移動游標到下一行，Vim裡面不需要移動游標到行末，只需循環敲入：「A;<ESC>j」 即可，本來操作就少很多。這還不是最少操作，更少操作是利用Vim裡面的句號「.」功能重復上一次操作，即第一行「A;」補充了一個分號後，第二行只需要按一下"."即可重復，於是最後操作變為：

第一行：A;<ESC>

後面所有行：J.

超級爽快的操作，這樣的操作還很多，你還可以單條命令對一萬行代碼重復上述步驟，或者把c代碼拷貝到go裡面先一句話把所有分號給刪除了。Vim下面的名言：絕不重復。

總之如果你熟悉 VIM模式，用 Atom能感到完全自由的方式，隨心所欲的書寫代碼，而不是被書寫這件事情費腦筋，解放大腦完全用於思考而不用於打字。但是同時對不習慣VIM的人照樣友好，或者對想使用VIM的便利卻又痛恨VIM這個軟體的簡陋的人帶來了福音。

脊椎記憶

「同樣動作重復300次，肌肉就會有記憶，而一個動作重復600次，脊椎就會有記憶」
-- 李小龍

編輯器就是關於脊柱記憶的東西，所以多投入一些時間去了解你使用的編輯器，掌握他們的各種快捷操作和高級功能是一個能讓你事半功倍的好主意。

格鬥游戲玩的好的人有很多，下等高手靠熟練，中等高手靠反應，上等高手靠意識。更熟練的掌握你的編輯器，讓更多日常工作固化成記憶記錄再你的脊椎上，使用的時候，脊椎這枚協處理器就能完成代碼編寫，一個操作，剛一想到，脊椎就自動執行出來了，小腦騰出空間來組織判斷，大腦騰出空間來思考更重要的東西，就像你走路，你不用思考邁腿那麼自然，別人一拳過來，你潛意識一動，一連串動作就出去了，一隻飛蛾飛過來，你潛意識的閉上眼睛保護眼部，這就是脊椎記憶，如果還要經過大腦繞一圈，反應慢不說，大腦這顆cpu都用在這些瑣事上了，思考的時間自然少了不少。

所以從內到外的了解你的編輯器，並且熟練掌握他們，是對你提高工作效率的最佳投資，Atom的全平台支持，開放源代碼，深度可定製等三個特點，比起其他閉源的，平台支持不全的，擴展少的編輯器來說能讓你有不同層面的了解機會，同時為你提供足夠的空間。

深度可定製系統

Vim/Emacs的精髓在於：「可以調教」，本來不順手的東西，只要容易調教，假以時日，都會慢慢變得越來越順手，越來越「懂你」，越來越「貼心」，以至於後面大家都離不開它了。而 Atom 也同樣是一款容易被你調教的編輯器。先前給vim寫過插件，給sublime寫過插件，如今給Atom寫過插件，橫向對比下來，幾個結論：

插件能做事情多少：Atom > Vim >> sublime

插件開發學習門檻：Vim > Atom > sublime

插件開發文檔豐富：Atom > sublime >> Vim

Atom 的定製化程度遠遠高過sublime之類（不用實際看法，看看雙方開發文檔即可），直追 Vim / Emacs，sublime的大部分定製無外乎改改json，插件能做的事情相當有限。

Atom 的定製化系統主要有三方面：

1. 細致：

設計之初就考慮的事情，方方面面都能定製，見官方文檔，以及插件：vim-mode，minimap （稍微了解下這兩個類似的功能再 Atom 和 sublime的實現就能知道 sublime被甩了多少條街了）。可以細粒度的控制編輯器內所有行為，小到移動一下游標，刪除當前一個字元，大到打開一個面板，比如 「core:more-up」 可以向上移動一行游標，「window:focus-pane-on-left」 可以把焦點設置到左邊的面板，atom內核和大量第一方第三方packages 都是以命令的方式把基礎功能提供出來，你可以隨意互相調用或者設置熱鍵。

除去命令外的API層面，幾乎每個部件每個像素點都可控，比如這樣的插件你永遠無法再 Vim / Emacs / Sublime 下面見得到：activate-power-mode。

2. 直觀：

由於使用 javascript/coffee進行開發，但 javascript/coffee是屬於即便你沒寫過他們，讀都能讀得懂，VimScript就不一樣了，雖然也能做相同的事情，但實話實說，晦澀難寫，比如我要取得當前文件的路徑和文件名，在 VimScript裡面需要這么寫：

let l:path = expand('%:p:h')let l:name = expand('%:t:r') 或者 let l:name = expand('%<')

而在 Atom 里我們用atom自己的功能直接取出路徑來，然後進行切割：

var fullpath =atom.workspace.getActiveTextEditor().getPath();var filename = path.basename(fullpath);var filepath = path.dirname(fullpath);

就問大家一下？哪段代碼更友好直觀？你一眼就知道在做什麼？你更願意用按照哪段代碼進行插件開發？是上面的VimScript？還是下面的 javascript ？

結論是很清晰的，Atom的 javascript開發插件更簡單直觀，即便沒文檔，看別人怎麼寫的自己也會了，同時靈活性大大高於VmScript，各種事件處理回調，javascript天生擅長做這些事情，還有第二行，第三行，我們用到了 node.js 的 path模塊，進行文件路徑切割。這樣的寫法，再VimScript 裡面基本是無法想像的。

Vim是強大，但是畢竟是30年前的東西了，即便最熟練的 Vimer 也都承認 VimScript 的晦澀難懂，阻礙了很多人為其開發插件。而給Atom開發插件，只需要掌握javascript，掌握 javascript的人很多，學習了javascript你也可以用在很多地方。不像VimScript那樣只能用在Vim裡面，而正因為其晦澀，Vim新版本開始支持內嵌 python的寫法：

python << EOF
import random
print random.randint(0,10)EOF

VimScript中 Python等動態的支持正是說明其開發維護者也承認 VimScript本身的古老，對比現代編程語言已經有些格格不入了，缺乏強大的描述能力，難以構建復雜的功能模塊，才會去支持Python內嵌這樣的寫法。可大量的工作還是需要再Python之外完成，同時，並非所有平台自帶的Vim都支持python，除了mac外，所有debian / ubuntu 發行版自帶的Vim都不支持 Python。導致你想寫一個通用的擴展還得判斷下是否 has('python') 沒有的話老老實實用 VimScript 去實現它，這不是折磨人么？

Sublime裡面可以用原生 Python 寫擴展，比 VimScript爽，但是 sublime 的插件能做的事情還不及VimScript的一半，所以怎麼能指望他們能寫出高端的功能來呢？

3. 強大：

Atom的內核 Electron （原來的 Atom-shell）可以理解成：Chromium + Node.JS，而整個Atom的界面，你可以理解成就是一顆 HTML 的 DOM 樹結構，這意味著你可以這樣：

var div = document.createElement("div"); div.innerText = "abc"; atom.workspace.addBottomPanel(div);

就可以簡單的在 atom 裡面增加一個顯示對象，這意味著再給div加個 html的 onclick就可以實現GUI交互，界面上的對象隨便寫點html代碼就可以控制效果，意味著你可以使用 jQuery 來為atom增加新面板，意味著你只需要寫一個簡單的 .css 文件就可以把 Atom 整個編輯器的外觀給修改了。這在 Vim/Emacs 中是幾乎不可想像的事情，sublime基本就別提了。

大量的前端開發技術和 Node.JS 基礎模塊供你任意使用，正是由於近年 Chromium / node.js 系列技術的成熟，和 Atom / Visual Studio Code 這類基於前端技術的客戶端軟體的成功，讓我看到了客戶端（桌面+移動）軟體開發的新方向。

做VIM/Emacs不能做的事情

Vim/Emacs過去給人的映像是：幾乎能做任何事情，確實如此，但畢竟是二三十年前的東西了，而他們一直堅挺到現在一方面是操作便利，更重要的是這么長時間還沒有出現一款又開源又具備同樣操作便利性和可擴展性的編輯器，所以Vimer, Emacser 們最樂意展示給別人看的就是他們又安裝了什麼插件，急於展示可以把 Vim / Emacs 裝扮成了一個多像 IDE 的東西，而今天這個「可以做任何事情」的高度可定製特性已經被Atom所吸收並完全超越，就像 Atom 的開發blog：「 Introcing Atom」 上說的一樣，對易用性和可展性 「決不妥協」 ：

We think we can do better. Our goal is a zero-compromise combination of hackability and usability: an editor that will be welcoming to an elementary school student on their first day learning to code, but also a tool they won't outgrow as they develop into seasoned hackers.

拋開易用性的這個 Atom 的明顯優勢不說，前面其實已說了不少 Atom 比 Vim/Emacs 更靈活強大的地方，可能有些人還有疑惑，不是說 Emacs 「沒有不能做的事情」 么？你看 Atom的面板裡面可以嵌入一個 Terminal，Vim/Emacs一樣可以嵌入啊，為何還說 Atom 比它強啊？

沒錯，Vim用久了會產生心理舒適區，多模式編輯使人神清氣爽，命令化文本處理讓你賞心悅目，但是受限於本身機制用久了會容易痛苦掙扎：雖然vim的各種擴展似乎什麼事情都能做，但每個擴展卻只能做到70分，總有那麼30%的地方做不到位。所以用的時間長了，上半身爽的要死，下半身痛不欲生。。。。

Vim/Emacs即便大部分擴展功能也都可以稱為「能用」，可幾十年的歷史包袱太沉，很多事情對他們來講就是禁區，比如詭異的標簽功能，容易誤操作的buffer/窗口切換，缺乏非同步機制，編譯時間長只有傻等著，無法跟Atom一樣邊讀代碼，邊運行程序看結果，對照輸出結果和源代碼找問題，連實現個內嵌終端都用了若干年，還實現的那麼別扭。。。。。。。。。

這類硬傷有許多，再舉個最簡單的例子，minimap，就是 sublime那種大家喜歡的文檔縮略圖，這個現代編輯器必備的功能，誰能用 Vim/Emacs 實現一下看看？Atom 可以衍生出 Visual Studio Code 這樣漂亮的編輯器，Vim/Emacs能衍生么？Atom可以隨便用各種先進的前端技術，不當可以嵌 Terminal我甚至可以再 Atom 嵌入一個 js版本的 DOSBOX 玩老游戲《命令與征服》：

https://archive.org/details/softwarelibrary_msdos_games

Play DOS games online

當然這樣並沒有任何卯用，但是如果在 Atom裡面內嵌一個瀏覽器，方便的實時預覽html/css的效果呢？或者 Atom 裡面內嵌一個 Markdown Previewer ，實時查看 Markdown 的效果呢？請問 Vim/Emacs 里怎麼實現法？

Atom插件演示：markdown實時預覽，左邊寫右邊即時更新，100%兼容github的markdown語法

短短兩年的時間，這么多優秀的插件，只想說，如今 Atom 作為 Vim/Emacs 的繼承者和超越者出現了，所以社區對 Atom 的反應也是熱烈的，看看下面一組數據，截止今天（2016年3月15日），Atom共有擴展插件 3500+ 個，發布不到兩年的時間，這是什麼概念呢？

• Sublime的插件（Stats - Package Control）大概 3500+個，但是sublime發布了5年的時間。
  

• Emacs 的插件大概有2900個，可Emacs發布到今天已經過去 25+年的時間。
  

• Vim 的各種插件雖然有9000個，但是Vi/Vim系列的歷史長達 30+年，是atom的15倍。

這就叫社區的活躍度的區別，為什麼短短兩年那麼多開發者先後給atom貢獻了各種高質量的擴展，為什麼大家對atom的熱情那麼高？為何好多人接觸了atom一段時間後都深深的愛上了它？這是有原因的。

再談性能優化

很多人錯誤的覺得 Atom慢是因為使用了 JavaScript/Coffee 等 Web 技術，所以先天慢，其實這是個誤區，即便使用 Web 技術它也還能快很多，同時再慢可以往C++層的 Electron 挪啊，這也是這幾個版本優化的一些方向，基於 Atom 開發的 Visual Studio Code 可以那麼流暢， Atom 性能優化空間還很大，了不起多參考下自己的兒子，同樣開源的 vscode怎麼做的。

同時 Atom編輯器1.0版本以來性能得到了很大的提升，主要是兩個方面，一方面是js層的各種渲染優化，控制項優化，延遲繪制，延遲載入，只繪制當前需要的東西等，另外一方面是將一些核心數據結構移動到 Electron 的 C++層，如今1.54版本性能較去年版本已經有了本質區別，運行時載入是慢些（但也比eclipse快很多），實際使用並沒覺得不如別的編輯器，況且，js層的優化和C層的優化未來還有很大的空間可以進步。

不過我不太喜歡 vscode 使用 Typed Script 進行開發，用點標准技術不行么，Atom使用 JavaScript/Coffee 寫的多爽，如今 Atom 正在准備慢慢的切換到 JavaScript 的新標准 ES6 上。其次 vscode 快是快在「做的事情少」，主要是可擴展性方面的努力遠不及 Atom，插件機制相對弱智，所以 vscode 的社區如今還不是特別活躍，擴展也少，發布一年多隻有差不多300+個擴展，遠不如 Atom 的情況，如果 vscode 還是按照現有結構開發下去，可能永遠不會擁有 Atom的靈活度，這樣再未來就無法擁有各種豐富多彩的插件。

再說開源免費

UltraEdit 單用戶版本價格： 79 美刀

UltraEdit 伺服器版價格： 229 美刀（多人登錄同一台伺服器的桌面使用），企業版更貴

EditPlus 單用戶版價格： 35 美刀，而且還只有windows版本，

Sublime 單用戶版價格：70 美刀

TextMate 單用戶版價格：48 歐元，而且還只有mac版本。

這些都是錢啊，可能你會說可以免費試用或者破解啊，是的個人可以，但正常來說sublime這些試用指不能拿來搞生產不能拿來工作的，個人你用用可以，但國外人家守規矩，不會亂用，這意味著失去一大批為其開發擴展的國外開發者，同時站在公司考慮IT方案的角度，免費試用和破解將來都是潛在的麻煩，現在上百人的公司微軟都會來收windows的錢了，版權問題越來越嚴肅，你得把這筆潛在費用考慮進去，同時這些閉源的或者單平台的東西，並不值得再上面花費過多精力和投資。

拋開擴展性問題和價格問題，我們再來看各個熱門的免費編輯器的試用情況：

Notepad++：免費，開源，只能運行於windows

PSPad：免費，不開源，只能運行再 Windows

Gedit：免費，開源，只能跑再 GNome下，Ubuntu用用，Windows/mac版本簡直是殘缺的。

Programmer's Notepad : 免費開源，只能跑 Windows

Notepad2：免費bu不開源，只能跑 Windows

更關鍵的是：閉源的東西個人作者可能失去興趣不再更新，商業公司的話，你需要一個功能，就只能無限期的等待他們發慈悲加入進去。而免費開源的很多其他編輯器除去平台兼容性問題外，更重要的時擴展性差。

而同時滿足：免費+開放+強擴展性的編輯器如今就只出現過三個：Vim / Emacs / Atom。他們是真正屬於使用者的編輯器，他們能變成使用者希望變成的樣子。這些曾經出現過得收費的或者免費的編輯器，憑借著一兩個自身獨有的 「賣點」，再某些時間段內都曾經流行過，可就像流星一樣一閃而過，如今他們都統統完成了自己的歷史使命，新的一頁可以翻開了。終端環境的話確實 Vim / Emacs 繼續下去，但桌面環境的話，Atom將會繼續向前，走出新的一步。