在開發程式時,你會選擇什麼工具來撰寫程式?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!

專欄作者

熱門新聞

Advertisement