IDE、編輯器的迷思

在開發程式時，你會選擇什麼工具來撰寫程式？IDE或是編輯器？如果選擇IDE，那會使用哪個IDE？用Eclipse或IntelliJ IDEA的話，會讓你覺得比用NetBeans的人高級嗎？你會覺得用Vim的人是神還是神經病？你是基於習慣、產能、慣例約定來選擇工具，或者只是基於某種爽度或態度，而做出選擇？

IDE、編輯器之爭

在Java的世界中開發程式，採用IDE會是相對明智的抉擇，因為語言上要處理的細節太多，而IDE可以協助解決許多的麻煩，然而已記不得看過多少次了，每當有人說是使用NetBeans，總會看到「使用NetBeans的不多見囉」之類評論隨之而來，感覺用NetBeans的開發者，在Eclipse或IntelliJ IDEA的使用者面前，相對就是矮了一截，想要談論IDE高下？那是Eclipse或IntelliJ IDEA的戰爭，NetBeans閃邊吧！

另一個常見的戰火則來自於編輯器與IDE，可以戰的理由太多，像是使用編輯器才能掌握底層細節、運用IDE才能讓產能最大化、編輯器學習曲線較高、使用IDE會讓手離開鍵盤、IDE在外部工具的整合度高、編輯器搭配外掛（plugin）也能做到IDE的功能、編輯器的自動完成（auto complete）支援太差、只是要簡單改個程式，為什麼要打開肥大的IDE？

理由甚至可以是：這門程式語言根本就不需要IDE，強者都是用文字編輯器的！

就連編輯器彼此之間也有戰爭，Emacs和vim之間就不用說了，就目前的時間點來看，新興的Sublime Text與ATOM之間，似乎也點燃了戰火，兩者內建語法提示、自動完成、套件管理、樹狀檔案瀏覽器等功能不可上下，ATOM開放原始碼且自由使用，不過Sublime Text比較輕快，這時Emacs和Vim的慣用者也說話了，他們根本不需要Sublime Text或ATOM，另一邊則不甘示弱，有Sublime Text與ATOM，還會需要Emacs或Vim嗎？

某個使用者出來說話了：「根本不知道你們在吵什麼，記事本才是我的最愛」！

先縮小戰線吧！

記事本？這傢伙憑什麼出來參與戰事？《The Pragmatic programmer》中〈Power Editing〉就提到，用記事本寫程式的傢伙令人吃驚地多，這也反映出戰火的引爆點，其實正是從編輯程式碼開始，開發者永遠關心一件事，那就是如何能更便利地編輯程式碼。

實際上，在Windows環境中，若只是要寫個小程式進行測試，或者檢視檔案中某個程式碼片段、順手改個名稱，實在不用打開肥大的IDE，開啟記事本確實會是選擇之一，當然，可以的話，設定為NotePad++開啟會更好，就現代電腦的效能來看，開啟速度跟記事本也不會感覺出差異，單就輸入這個目的而言，也沒有任何的學習成本，不可否認地，速度與學習成本都是編輯程式碼時便利性的考量。

進一步地，為了能減少程式碼編輯上的輸入錯誤，開發者開始希望有關鍵字醒目提示（Highlight）、自動完成等功能，有趣的是，在IDE與編輯器的爭戰中，很多時候焦點總糾結在有沒有醒目提示、自動完成這些功能。

對於將自身定位為IDE的工具來說，醒目提示、自動完成是個基本特性，然而對於編輯器來說，醒目提示、自動完成會是特別強調出來的功能，有些編輯器本身內建，有些編輯器則可透過外掛來達成。

許多情況下，開發者也不會只開啟一個檔案來編輯，因此，檢視或搜尋檔案的便利性就很重要，IDE通常會提供專案檢視或檔案檢視的窗格，並可以分頁方式開啟檔案，好一點的編輯器基本上都支援分頁與多欄檢視，檔案瀏覽的話通常透過外掛，例如NotePad++可以加掛Explorer內嵌檔案瀏覽器，Vim的話可以外掛NERDTree，近來由於Sublime Text中CtrlP可模糊查詢檔案的功能大受開發者歡迎，Vim上也不示弱地推出了個CtrlP的外掛。

實際上，當焦點集中在程式碼編輯的便利性時，IDE上具有的編輯功能，編輯器往往都能透過外掛或編寫程式的方式來達到相對的能力，而隨著程式碼各種編輯需求的增加，逐步打造最適合自己的編輯器，也是最能夠瞭解自身開發環境需求的一個過程！

那麼，為什麼需要IDE？

事實上，若需要外部工具支援，像Vim這類經典編輯器，也有著Use Vim like an IDE之類的文件，教導開發者如何將Vim逐步打造成IDE，而正如〈所需即所獲：像IDE一樣使用vim〉（https://goo.gl/HN1qS2）中說到的：「只有你想不到的功能，沒有實現不了的外掛」！

那麼IDE存在的價值呢？別忘了，IDE是整合開發環境（Integrated Development Environment）的英文名稱縮寫，也就是將開發過程需要的工具整合在一起的環境，實際上，當開發者從編輯器開始，逐步打造出一個屬於自己的開發環境時，就是在建立一個完全客製化的IDE了！

只不過，並不是所有的人，都有能力或有時間從無到有，客製出自己的整合開發環境，即使是資深的開發者，在初接觸一門語言的生態系時，也很難能立即捕捉到開發環境的需求且自行打造，因此，才會有現成的IDE品牌存在的價值。

這類現成的IDE，會在眾多開發者需求與心智模型間盡力取得最大交集，讓使用它們的開發者能立即感受到需求被滿足，節省了從無到有建立開發環境的成本，在開發者跨足生態系之時，若能選擇一個適當的IDE，也能加速其對生態系的認識與瞭解。

這可以程式框架的選用來做比喻，如果選用的程式框架適切需求，那麼就會獲得極大的產能助益，然而，如果對框架的運行原理一無所知，就冒然使用，那麼脫離了框架提供的功能，就會什麼也做不了而覺得處處受限，就像個傻瓜一樣。

而這種形容，往往也套用在對語言底層一無所知、不使用IDE就無法寫程式的傻瓜開發者。

選用某個現成的IDE品牌，確實就相當於選擇一個框架，因此，選用IDE，除了考量該IDE捕捉的需求與心智模型是否符合開發之外，就跟選用程式框架一樣，也得考量是否願意接受IDE的約束，對團隊而言，如果每個人都由編輯器開始，從無到有打造出自己的開發環境，或者每個人各依所好，各自選用偏好的IDE品牌，那麼想要共同合作開發專案，將會是困難重重！

你的開發環境需求是什麼？

最近我為了在Raspberry Pi的Docker容器中，建立一個虛擬的Java開發環境想了許多策略，整體來說，就是因為不理解開發環境需求而令人沮喪的一個過程，最後我拋開了使用既有IDE的方式，選擇從Vim開始慢慢建構環境，才逐步摸清了自己的開發環境需求。

可以的話，每個開發者都可以試著從使用一門編輯器開始，逐步打造出符合自己需求的開發環境，為了能逐步打造，編輯器的選擇上必須要是可安裝外掛，若可以自行撰寫程式來控制編輯器行為的話更好，更重要的是，這門編輯器能夠支援多種平臺，如此在不同的平臺中編寫程式時，就有機會建立一致的開發環境，這是可完全瞭解到自身編輯程式時的各種需求，打造出最適用自身開發環境的一個過程，無論適用的理由是基於產能、習慣，或者單純只是種爽度或態度上的考量。

自行打造的開發環境，並不一定要與工作有關，工作上的IDE也許是種約束，或許令人覺得不舒服，那麼為自己的寵物專案打造個專屬環境也不錯；如果某個品牌IDE直接就適切了需求，那就用吧！

就算在他人眼中，那是個非主流或非業界慣用IDE也無妨；如果在使用Vim的過程中，還是習慣用一下滑鼠，那就用吧！gvim也是個不錯選擇！Vim中使用方向鍵如果是種習慣的話，並沒有人規定你一定要用hjkl！