作者 ｜ Beyang Liu
譯者 ｜ 王莉敏
策劃 ｜ Tina
開發人員開發了很多有價值的軟件，但涉及到自己的工作時卻成了 “鞋匠的孩子沒鞋穿”。
我們生活在開發工具的黃金時代。軟件正在吞噬著世界。現在，每個公司都是軟件公司。每個軟件公司都需要開發人員和開發工具。由構建開發工具的公司組成的生態圈正在蓬勃發展。
每一個編寫代碼的公司都已發現（或正在發現）軟件開發真的很棘手。世界需要更多的軟件，但這并不是雇傭更多的開發人員就能解決的問題。開發軟件并不能輕易地實現規模化或并行化。順序依賴和不可預見的復雜性使我們嚴重低估時間節點和預算，進而導致糟糕的商業產出甚至是嚴重的生存危機。
為了解決大規模軟件開發中的效率問題，越來越多的公司正在自建和購買開發工具。不只是 Google、Facebook、Microsoft 和 Amazon，其他公司也在為此投入大量資金。
為了滿足這種日益增長的需求，由構建開發工具的企業組成的新型行業正在飛速發展。像 GitHub、GitLab 和 HashiCorp 這樣的平臺已被大眾所知，其所在的領域正逐步進入大眾視野。
1
歷史趨勢，重大機遇
過去這十年，開發工具市場發展速度之快令人難以想象。當我和奎因（Quinn）在 2013 年創辦 Sourcegraph 時，我們很快發現“開發工具”這個詞根本就入不了投資者的法眼。投資者承認開發工具很有價值，但是認為其中的大多數只是單打選手的工具（例如，JetBrains、Sublime Text），而這并不能獲得足夠的收益，另外一些是為滿足大型科技公司特定需求的內部工具（例如 Google Code Search），還有一些是開源項目，這些項目沒有人買單，只能通過出售服務和提供支持來賺錢。投資者告訴我們，只有一家十億美元的公司賣給了開發者——Red Hat，但這只是個特例。
開發人員開發了很多有價值的軟件，賣給了其他伙伴——銷售人員、市場營銷人員、設計師等。但涉及到自己的工作時，卻成了 “鞋匠的孩子沒鞋穿”。TechCrunch 中的一篇文章感嘆道：“研發開發工具的創業公司能找到投資者嗎？”
但是，在過去七年中，情況發生了一些變化。這種變化體現在估值上：GitHub 被微軟以 75 億美元收購，GitLab 估值 60 億美元，HashiCorp 估值 50 億美元，JetBrains 估值 70 億美元，這份清單還在繼續。
但是，盡管這帶有一串零的數字吸引了人們的眼球并成為新聞的頭條，但他們也只是推動軟件構建方式巨大變革潛在因素的副產品。以下是一些潛在因素：
· 大型科技公司：大型科技公司和技術驅動的創業公司之間的競爭已經蔓延到各個行業，這導致每個公司都優先發展軟件，并將其作為核心競爭力。
· 海量代碼（Big Code）：全世界的代碼量正在飛速增長，越來越多的公司已經達到了一個臨界點，以前這個臨界點只有最大的科技公司才會遇到。
· 企業級 OSS：“云”作為一個建立在開源軟件（Linux 和 Kubernetes）之上的軟件平臺，與舊的軟件平臺相比，后者是垂直集成的專有生態系統（例如，Windows+.NET+Visual Studio）。
未來發展充滿不確定性，但有一點確定的是：幾乎每一個有價值或者快速成長的公司都在開發軟件，而且大多數都意識到他們需要優秀的開發工具來在競爭中保持優勢。
這是一個激動人心的消息。傳統意義上來說，“科技”是經濟中一個獨特的分支，只有有限的幾家大型科技公司具有高效開發大規模軟件的能力。現在，各個行業的公司都明白，代碼已經成為公司 DNA 的核心組成部分。這意味著代碼和軟件的影響力擴大了。不再只有“技術公司”才能提供軟件產品或技術服務——參與經濟運行的各個公司都在學習如何憑借自己的力量研發優秀的軟件。
隨著越來越多的經濟組織嘗試開發軟件，這個進程仍在加速。很大程度上，因為代碼的原因，對未來的幻想——治療癌癥、救命藥、大規模個性化交通工具、火箭飛船等等將更快地成為現實。長期以來，軟件一直被認為是技術進步的助推器。而開發工具是技術進步的二階助推器（助推器的助推器）。這是一個巨大的機會。
如何更好地抓住這個機會？
2
大型公司，開源軟件公司，創業公司
你可以在以下三個地方進行開發工具的研發。（可能還有更多，但為了簡潔起見，我們將重點介紹這些。）
首先是大型非開發工具公司。許多從事軟件開發的大公司都在內部工具的研發上投入重金。大型公司內部有很多優秀的開發工具，很多這些工具促進了外部類似工具的誕生。Blaze 是 Google 的構建系統，它促使了其他構建系統的誕生，比如 Pants 和 Facebook 的 Buck，后來它自己被開源為 Bazel。大公司也提供了豐厚的、穩定的工資福利。缺點是你工作的直接影響力很可能會被局限于一個組織內部。你的作品有一天可能會變成開源項目，但沒有人能保證這一點，而且這需要花費幾年的時間去獲得法律允許和官方機構的批準。當然，就算這個工具得到廣泛使用，你也不會直接獲得經濟上的回報。
其次是開源項目。開源項目的工作經歷可以使你獲得更多的認可，并且項目不存在和甲方討價還價的煩惱。如果你的主要目標是用戶使用量，開源項目具有很強的吸引力。許多廣泛使用的開發工具（Git、Linux、Emacs、Vim 等）都是開源項目。當然，缺點就是缺少收入。許多開源項目的作者和維護者都有其他收入來源（通常是大型科技公司）。Patreon 和 GitHub 的贊助者很多，但可能只有很小一部分開源項目的作者能夠僅靠贊助就過上舒適的生活。你能夠獲得的收入來源限制了你可以投入到開源項目上的時間。
再次是研發開發工具的公司。得益于過去幾年開發工具市場的迅猛增長，大多數此類公司都是創業公司。開發工具公司能提供的好處是：使用者、客戶、以及團隊成員通常都是同一群人。如果你開發了一個很棒的工具，你的用戶會很快樂，你得到報酬，你也會很快樂，你和你的同事都能使用這個工具，于是你獲得了雙倍的快樂！開發工具的創業公司還能給你金錢上的額外回報（如果你的部分薪酬是公司股權）。這種回報可能會很驚人。我個人認為，開發工具市場目前還處于發展初期。我相信將來有一天，高質量、廣泛使用的開發工具造成的影響將遠遠超過廣告驅動的網絡搜索、PC 操作系統和社交媒體。也就是說，總有一天，開發工具公司的市值會超過當今最有價值科技公司的總和。
當然，初創公司也有風險。公司極有可能無法實現其崇高目標，裁員甚至倒閉。沒有一種適合所有人的工作。就我個人而言，我遵循的原則是“收益最大化，風險最小化”，其中“收益”和“風險”的定義取決于你自己。
不管選擇大型公司，開源公司還是開發工具創業公司，你仍然面臨著一個問題：如何評估這個機會和工具是否值得你的付出。為此，需要綜合運用你的直覺和價值觀進行評判，接下來我們將進行討論。
3
滿足自己的需求，也要了解整個市場
杰米·扎溫斯基（Jamie Zawinski）曾經說過：“世界上最有效的激勵手段就是滿足自己的需求。”（the best motivator in the world is scratching your own itch） 他談的不就是開發工具嗎，他說得對。很多開發工具起源于程序員碰到一個難題，然后想出通過軟件自動化解決問題的方法，并通過代碼實現它。為自己開發軟件意味著你需要同時在產品經理、工程師和客戶這些不同角色間進行切換。如果想為自己和其他處于相同困境的人創建真正有用的東西，這真是一個絕妙的主意。當你評估企業開發工具的前景時，很大程度上依賴于你的直覺：痛點在哪，哪個產品能提供有效的解決方案。
但是，你也會希望將直覺與軟件開發方式結合起來——不同公司和部門間的共同點是什么，你要服務的細分市場有哪些不同點和特殊之處。重要的是你需要明白你的需求在整個軟件開發拼圖中的位置，以及其他人的需求在他們開發拼圖中的位置。
軟件的開發方式因組織而異，甚至因人而異，但是有一個通用的“軟件開發生命周期”模板：
制定計劃并描述軟件目標（例如，實現某個功能或修復某個錯誤）
閱讀并理解要修改的代碼
編寫、運行和調試新代碼
測試代碼
評審代碼
部署代碼
監控生產環境并對事件做出反應
這個生命周期也會有很多的變體：
個人開發者在開發個人軟件時會使用自己的編輯器來讀寫代碼，使用簡單的單元測試框架來測試代碼，以二進制文件的方式來發布應用程序，并通過小型的問題跟蹤軟件來接受反饋和管理 bug。
開發小組會使用更復雜的問題跟蹤軟件來制定項目計劃，使用代碼搜索工具理解代碼，使用各種不同的編輯器來編寫代碼， 利用 AWS 或 Google 云上的 CI（持續集成）服務如 Buildkite 或 CircleCI、Docker 實現軟件部署，采用一個簡單的日志聚合器來監控軟件運行和錯誤監測。
大型組織中，可能會有整個團隊或部門來負責開發環境、CI / CD 服務維護，計算資源配置，發布應用程序到生產環境、監測和定位關鍵生產問題以實現第一時間響應。
理解通用流程和客戶的具體實現非常重要。了解你要加速的生命周期——個人的、團隊的、組織的，或者上述的某種組合——也很重要。只賣給個人開發者本身并沒有什么問題，但很多最成功的開發工具創業公司都把產品賣給團隊和組織。向團隊推銷意味著要說服代表團隊利益的人——可能是開發經理、總監或者開發人員效率部門的主管 。而這個人可能不會每天編程。
在評估哪些開發工具和公司值得你花時間時，你可以考慮他們的客戶是團隊還是個人，他們怎樣向不同的客戶表達自己的價值理念，以及你構建的工具將如何適應客戶的軟件開發生命周期。
4
開發工具創業公司的一些簡單示例
讓我們了解下以下開發工具創業公司位于軟件開發生命周期的什么階段。
Sentry 可對生產環境中的錯誤發出告警，并幫助你快速定位需要修改的代碼位置。對于將大部分時間花在軟件開發生命周期第 1 - 5 階段的應用程序開發人員來說，它旨在使得第 7 階段 (“監控和反應”) 更易于操作 。它也能做到在問題到達第 7 階段之前在模擬環境中捕獲問題。
Honeycomb 可以檢測生產環境的錯誤和異常, 讓你鉆取到“無限寬的數據表”，從而獲取到足夠的上下文信息來找到問題的根源。與其他第 7 階段工具使用“monitoring”或“APM”標簽不同，
Honeycomb 定位于可觀察性 (Observability)——一種有效管理第 7 階段的思想理念。
Pulumi 允許你用最擅長的編程語言以編寫代碼的方式來描述架構。通過實例化對象（如 TypeScript 語言）來定義你的發布方式，Pulumi 負責將它映射到生產環境。對于那些擅長第 1 - 5 階段的開發人員來說，它使得第 6 階段操作更簡單。
YourBase 是一個測試運行服務，可以并行運行和優化你的構建服務。它檢查系統調用并執行語句分析，以推斷程序構建的依賴結構，可降低大型代碼庫的構建時間。它加快了階段 4 的運行速度，該階段對很多團隊都是致命的瓶頸。
Tilt 用來為多服務應用程序構建最佳的開發環境。像 Kubernetes 這樣的技術使得多服務應用程序的部署更加容易，但是多服務應用程序的開發環境還需要自行搭建。它解決了階段 3 中的痛點，這些痛點是由于階段 6 的創新引入的。
Caddy 是一個 web 服務器和反向代理服務器，它強調好的開發體驗、可擴展性和自動使用 https 等好的默認設置。它在階段 6 中使用，對于花費大部分時間在階段 1 - 5 中的開發人員來說非常有必要。
Wasmer 構建一個運行在服務器上的 WebAssembly 虛擬機 (在 web 瀏覽器之外)。它有可能影響階段 2 和 3 (Wapm 可實現不同語言源代碼間的相互依賴)，但是它最大的價值是在階段 6，為大量的服務端應用程序提供高性能、易于使用和安全的部署環境。
Codestream 是一個代碼討論工具，可以在代碼編寫環境下進行溝通和信息交換。它的目標是將代碼評審 (第 5 階段) 中發生的大量交流“左移（shift left）”到第 2 和第 3 階段。
Sourcegraph(我作為聯合創始人的公司) 是一個代碼搜索工具, 可以在你的代碼庫中發現模式、反模式、符號、引用和錯誤消息。它可以讓你更容易深入到不熟悉的代碼中，并對代碼的工作原理以及與其他代碼的依賴關系有一個快速的理解。我們的核心產品定位是階段 2，但是因為查找和閱讀代碼貫穿軟件開發生命周期的整個階段，所以集成了編輯器 (階段 3)、代碼評審工具 (階段 5)、代碼覆蓋工具 (階段 4) 和監控工具 (階段 7)。
軟件工程中的許多術語也可以從它們對軟件開發生命周期的意義方面來考慮。通過這種方式可以幫助我透過炒作，看清它們的真正含義:
DevOps包含兩件事：一是讓 Ops 對開發者更友好（即讓將大部分時間花在階段 1 - 5 的開發者更簡單地操作階段 6 - 7）。二是通過軟件自動化減少系統管理員的手工工作，讓系統管理員角色變得更像開發人員（讓階段 6 - 7 變得自動化）。代碼即是架構是 DevOps 的一個方面，它使用開發人員熟悉的語言來定義部署階段，從而實現部署過程的自動化。
Shift left（左移）意味著在軟件生命周期的早期階段捕捉 bug 和問題。普遍接受的規則是，軟件生命周期中，下一個階段修復 bug 的代價是上一個階段修復代價的 10 倍，如果是在階段 4 而不是階段 7 中捕獲問題，那就意味著在時間、精力和金錢方面的付出要減少 100 - 1000 倍。
Microservices通過調整軟件在階段 6 的部署方式，來解決階段 1 - 5 的瓶頸問題。編寫代碼時簡單，部署時就會復雜 (但希望早期的好處大于后期的壞處)。微服務和單體應用（monoliths）之間的爭論主要在于如何處理復雜性。有一些通用的規則可以幫助你選擇，但是更多取決于軟件團隊成員自身的能力，有多少經驗在 ops 階段 (6 - 7)，有多少是在 dev 階段 (1 - 5)，以及對有利于減輕各階段復雜度工具的熟悉程度。
誰知道呢? 也許對這類公司進行足夠的調查，并對個人經歷進行反思，你就會發現新的工具或公司可以滿足你的需求并給予你機會。你也可能會得出結論，最適合你的不是加入任何現有的開發工具創業公司，而是創建自己的開發工具——但這是另一個主題了。
過去幾年間，開發工具市場的發展經歷了一個分水嶺。軟件開發滲透到了經濟的各個領域，甚至“非技術”公司現在也雇傭了數百萬的程序員，在持續增長的開源代碼庫中工作。現在開發工具的研發是個潛力無限的市場。好的開發工具能提高我們的技術水平，成為技術進步的二階加速器。全球經濟向前發展的節奏和鼓點將是“開發人員，開發人員，開發人員”，因此，構建開發工具正是時候了。
https://beyang.org/time-to-build-dev-tools.html
