在我的職業生涯中，擔任過許多不同的角色，從開發人員到執行長，以及介於兩者之間的幾乎所有職位，但是我一直在不斷進步。
對我來說，這不僅是一種樂趣，而且最重要的是，它對於繼續理解和掌握我們所處的超技術和超快速發展的環境至關重要。
我知道這是一個有爭議的話題，但我認為首席技術官、工程經理，甚至首席開發人員應該知道如何編碼，而且必須編碼，無論是專業還是個人專案。
在這 20 多年的或多或少密集的軟體程式設計過程中，我有機會使用各種各樣的開發工具和IDE。
最近，我逐漸放棄了最複雜的工具，轉而追求輕便和高效。
讓我來介紹一下我的歷程。
21 世紀的我
我在 21 世紀初進入了專業開發市場。
當時網際網路泡沫已經破滅，但 Web 開發仍在蓬勃發展。
90 年代開發的“面向 Web”的語言（即除 C、C++ 之外的所有語言）（JavaScript、Python、PHP、Java 等）正在不斷改進，開發工具也緊跟這一趨勢。
這是Eclipse IDE（2001 年釋出）、Visual Studio（1997 年）以及其他已基本消失的 IDE的鼎盛時期。
這也是一段徒勞地抵制專有環境（如 SunOS、HP-UX 和 AIX）中更專業化工具的時期。
當時，我必須在眾多的選擇之間做出選擇，但又不能對其中任何一個產生特別的依賴。
2010–2020
2010 年，我發現自己擔任一家擁有 3,000 名員工的公司的資訊長，而這家公司本身又隸屬於一個擁有 140,000 名員工的大型集團。
我的職責轉向管理，但幸運的是我設法保持與技術總體和程式碼具體的密切聯絡。
這也是我發現 IntelliJ——它是Java 專家的首選 IDE 的時期。
2017 年，我與他人共同創辦了一家初創公司，其使命是開發一個透過合同自動化來管理醫護替代人員的平臺（可稱為一種醫護界的 Uber）。
擔任這家公司 CTO 後，我又回到了密集編碼模式，以前這家公司只有我和合夥人，我必須設計整個系統，開發 MVP 以及後續步驟。
IntelliJ 仍然是我的主要工作工具，不再用於 Java，而是用於 Scala（它知道如何很好地處理）和 GoLang（它也知道如何很好地處理）。
“智慧”自動完成功能開始看起來令人信服，並且該工具的範圍不斷擴大（資料庫管理、從程式碼進行 SQL 查詢、針對資料庫模式的程式碼一致性檢查、HTTP 查詢管理以測試 API 等）。
隨著 2020 年的臨近，所有這些功能所暗示的工具繁瑣性開始讓我感到厭煩。
我們為初創公司招募的一些開發人員更喜歡使用已經成熟的VSCode 。
我們於 2020 年出售了自己的初創公司，然後我成立了自己的諮詢/開發公司，主要參與曾接洽的兩個專案。
第一個專案是幫助一家醫學影像軟體公司重新整理和更新產品目錄。第二個專案是設計、開發和部署孟加拉國農業普查所需的所有軟體和基礎設施。
再一次，我發現自己處於必須“親自動手”的境地，這次主要使用 Rust 和 Golang（還有很多 Kubernetes yaml 檔案……）。
VSCode 仍然是我首選的工具，但與 IntelliJ 一樣，我使用它的時間越長，就越能意識到它的小延遲、速度減慢和錯誤。
我突然想到，我職業生涯開始時有機會使用的那些老好工具（例如VIM）可能需要發展了，而且可能可以實現相同的生產力水平，而不必擔心使用越來越像 Eclipse 及其所有外掛的 VSCode。
期間，我參加了一個開發者大會，會上主講人對NeoVIM做了一個非常有說服力的 demo （應該是定製化的），最終讓我信服了。
因此，我開始花費大量時間嘗試正確配置 NeoVIM，並意識到這幾乎是一項全國性運動（Youtube上面有成千上萬個影片，裡面的人默默拍攝自己配置 NeoVIM 的影片，而且我敢肯定 Twitch 上也有相同主題的影片）。
現在
如今，我是一名“服務部門經理”，這是我在現任僱主處設立的職位型別之一，旨在解決產品停滯、團隊重新活躍和所有權執行的問題。
基本上，我管理一個負責產品（在本例中是雲提供商的 IAM）的團隊，從設計到執行，當然也包括軟體開發。
我的職責是管理一個小型（但多技能）的團隊完成所有這些階段。
再次，我的時間被分配到管理、產品定義、基礎設施管理以及開發之間。
2021 年底，我偶然發現了Helix （我當時正在尋找 NeoVIM 的 Rust 版本）。
Helix 是一種“內建電池”的 NeoVIM，即兼具兩全其美的優點：終端模式（模態）編輯器的輕便性和效率，而沒有 NeoVIM 所需的配置和外掛的混亂。
雖然這是一個相對較新的專案，但它發展迅速，現在已經完全成熟，可以用於日常使用，無論是用於編碼、編寫文件、管理我的筆記和待辦事項、製作我的美人魚圖表等……
它可以透過 LSP 協議（由 Microsoft 透過 VSCode 推廣）輕鬆擴充套件，因此您會發現與任何更重的 IDE 相同的自動完成、診斷和操作建議功能。
它還沒有定義外掛系統，這有點違背了它的初衷。但在社群的壓力下，它的建立者最終讓步了，並且它正在不斷發展。
那麼，為什麼要使用基於終端的模態編輯器？
在Cursor和其他支援 AI 的 IDE 變得越來越複雜的時代，這種選擇可能看起來違反直覺，甚至適得其反。
這確實與工具競賽相反，但隨著時間的推移（以及隨之而來的智慧，必定會有一些優勢），我意識到這些工具最終會在我的大腦和我的程式碼之間產生“噪音”。
這些工具的目的是透過自動執行某些任務和隱藏某些複雜性（例如，編譯選項的粗糙度或用於啟動除錯或單元測試會話的引數）來提高開發人員的工作效率。
這最終會導致開發人員和他實際互動的工具（主要是編譯器）之間的距離。這一距離引發了幾個問題：
-
首先，如果沒有自己喜歡的 IDE，開發人員將無法再開發或編譯他的程式（之後編寫 CI 指令碼並不容易）。
-
其次，但這只是個人觀點，我發現它們不利於程式碼結構的心理表徵。您只需單擊一下即可從函式簽名導航到其呼叫，再單擊一次即可瀏覽樹形結構（這可能非常令人困惑），最終您無需付出記住程式碼結構所需的記憶努力。然而，這種心理表徵對於持續改進程式碼至關重要。開發人員不僅僅是在 IDE 前思考（這可能甚至微不足道）。
當你使用 Helix（或 NeoVIM）等編輯器時，會感覺自己“更接近”程式碼。例如，Helix 沒有樹狀的程式碼或檔案結構表示，而是具有超高效和快速的搜尋系統。
如果你對檔案和程式碼結構有充分的瞭解，這種“缺乏”實際上會變得更加高效。
另一個同樣重要的方面是習慣使用者的工作速度。
瀏覽程式碼，選擇一個單詞、一個函式、一個函式的一部分，同時編輯它們——所有這一切都在一瞬間完成，無需離開鍵盤去拿滑鼠或觸控板。
對於純文字編輯，模態編輯器對於那些花最少的努力去學習如何使用它們的人來說是無與倫比的，即使程式碼庫有幾十萬行。
但 Helix 不僅僅是一個文字編輯器：它能夠透過 LSP 協議使用外部工具，提供與更重的 IDE 幾乎相同級別的資訊和自動化：直接訪問功能文件、自動完成、功能簽名描述、程式碼結構索引（誰呼叫誰、誰被誰使用、誰實現了什麼等）。
結語
模態的、基於終端的編輯器迫使您專注於程式碼，而不會受到干擾。如今，它們的效率令人難以置信，而且越來越全面。
然而，沒有人工智慧或 Copilot，你就得動腦筋了。也許這就是它沒有針對如此廣泛的受眾的原因 😉
譯者：聆聽音樂的羊
作者：Bastien Vigneron參考：https://medium.com/codex/why-ive-abandoned-ides-8967d12ecde7
相關閱讀：