幾周前我主持了一個小組讨論，會上有人問道：“為什麼程式設計語言社群沒那麼多初創公司呢？”
這個小組會議的主題是職業路徑，是程式設計語言設計和實作（PLDI）會議的一個環節。那人問的是為什麼我們沒有看到很多一流的程式設計語言和軟體分析技術走向商業化。
程式員待解決的痛苦顯然有很多。但為什麼我們沒有看到更多“深層”技術從實驗室走向行業，進而實作技術轉移，是我從大學開始就一直在思考的事情——當時我決定用我的一生來讓程式員的生活變得更好。從機器人技術到資料庫，其他許多領域都有更加清晰的商業化路徑。
但對于新生的程式設計語言或軟體分析技術來說，就算技術實作了轉移，轉移路徑也往往長達幾十年。我是一名程式設計語言博士生的時候就在思考這個問題，然後當了教授，現在又成為了 Akita 的創始人——這是一家以 API 為中心的可觀察性公司，旨在将軟體分析技術應用于 API 流量——我的思考并未停下來過。
但在小組讨論會上我隻是主持人，是以我必須關注那些實際上是為小組成員準備的問題。上周，我開了一個 Twitter 話題 征求這個問題的答案。這篇文章是對這個讨論串的詳細說明。盡管開發工具得到的投資和銷量正在增長，但“深度技術”工具并沒有收獲自己的增長份額，我要探讨的就是這種現象背後的成因。我們可以做很多事情來解決這個問題——我很樂意與大家一起改變現狀。
在這篇文章中，我将重點讨論為什麼我們沒有看到更多高成長的初創公司專注于來自 PLDI 社群（程式設計工具的“深度技術”側）的各種語言和工具。在其他領域還有很多類型的開發工具造就了許多高成長的初創公司。成功的技術轉移途徑也還有不少（大公司、開源項目），這裡我就不提了。
1、軟體團隊正在購買工具
有一種流行的說法是公司并不會為開發工具付費，但這種觀點越來越站不住腳了。甚至在幾年前，人們還在談論風險投資支援的開發工具公司所面臨的挑戰，以及 圍繞開發工具建立大型企業的難度有多高。
關于開發工具銷售情況的一個流行觀點
到了 2021 年，人們普遍認為開發工具有錢途可言了。在過去的幾年裡，我們看到 Salesforce 以 2.12 億美元收購了 Heroku，微軟以 75 億美元收購了 GitHub。如今，私營公司 Postman 的估值達到了 20 億美元，HashiCorp 的估值有 51 億美元。一些開發者優先的公司也上市了，表現不錯：New Relic 的市值超過 40 億美元；Datadog 的市值超過 320 億美元。
但是人們并沒有為基于新生程式設計語言和技術的東西慷慨解囊，尤其是那些旨在幫助人們編寫有更多保證的代碼的技術。2020 年，整個靜态分析市場規模估計為 7.481 億美元，預計到 2027 年也才達到 20.02 億美元。程式設計語言的開發主要由大公司支援，例如 Go 和 Python 的例子；或者是一群動力十足的開發人員尋找其他方式來支援自己，彙聚成一個個開源社群，例如 Ruby、Elm 和 Julia。
程式員的痛苦顯然是存在的——其中一些新生語言和工具恰恰可以解決這些痛苦。那麼到底出了什麼問題呢？
2、程式員正在用他們的預算投票
難道工程上司人所選擇的工具在違背開發人員的意願嗎？很多人持這種觀點。
關于開發工具銷量的一個常見問題
但資料并不支援這一點。根據 2017 年的開發世界狀态調查（來自 SlashData），77% 的開發者現在在工具選擇方面有發言權。他們選擇将這些工具預算花在讓他們的工作更輕松的産品上，而不是花在讓他們的代碼品質更高的工具上。不管怎樣，這兩個關注點并不是一回事兒。
值得一提的是程式員的願望和程式員的需求是不一樣的。我希望在我家後院裝一個鳥舍，在那裡我可以飼養寵物貓頭鷹。但是我現在需要做的就是寫一些電子郵件和吃午飯。類似地，程式員希望按時傳遞無錯誤的代碼，希望這些代碼的運作速度能一直與和測試時一樣快。但他們需要的是解決眼前火燒眉毛的事件，然後在路線圖上找地方把進度趕回來，這樣才能盡快将規劃的特性釋出出去。
如果有人提到一種可以神奇地将錯誤減少到零的工具，軟體開發人員可能會很感興趣，但腳踏實地的軟體開發人員知道其實他們的使用者似乎對某些錯誤有很高的容忍度。軟體開發人員可能會在周末用這種閃閃發亮的研究型語言來發洩一番，但他們内心深處知道，在他們淩亂的工作代碼庫中采用它并不是推進職業生涯的最佳路徑。
那麼為什麼開發人員會選擇花錢購買某些工具呢？這些工具相比其他工具來說有什麼好處？
3、幹活兒的開發人員不會購買“奢侈品”
有些人會說，更進階、更深層次的技術得到廣泛采用隻是時間問題。個人拙見：程式設計語言社群目前持有的一些假設是與程式員的需求不一緻的。
以下是一些不符合 PL 世界觀的程式員需求例子：
零錯誤：往往不是首要任務。語言設計和軟體分析的一個共同目标是“健全性”：如果出現了一個錯誤，工具會發現它。如果你正在建造一艘宇宙飛船，其中一個錯誤就意味着幾條人命和數百萬美元的代價，那麼用細齒梳來檢查可能存在的錯誤的确是有意義的。然而，對于常見的 web 應用來說，修複錯誤和傳遞特性之間存在很大的權衡空間。Web 應用開發人員通常需要一些東西來幫助他們快速建構軟體，同時又不犧牲太多的正确性——而不是相反。
人們不想搞清楚他們所有的問題。我經常看到“花哨的”技術假設開發人員想知道系統中存在的所有錯誤。你最受人歡迎的朋友會總是告訴你所有可能出錯的地方嗎？人們不想搞清楚他們所有的問題，尤其是考慮到并非所有問題都那麼重要的時候。如果你想讓開發人員高興起來，請給他們一個優先級清單，列出下一步要做什麼，而不是給他們一個充斥着潛在問題的清單，讓他們把你的消息直接靜音掉。
技術棧是有機進化的生态系統，而不是集中規劃的實體。現在的問題是為什麼沒有哪種程式設計語言或架構會統治世界。在所有領域，理想中的銀彈解決方案都很有吸引力，做夢想象一種真正完美的語言也挺有趣。但大多數具有一定成熟度的系統都會再去選擇第二種語言，然後是第三種語言。技術棧的不同層次會采用各自的語言和技術。這并不是因為組織出現了混亂，或者沒有考慮周全。語言在發展，系統的需求在發展，下一代程式員也在進步。
從在職開發人員的角度來看，零錯誤的理念、足夠讓你解決所有錯誤的時間表以及對技術棧的完全控制看來都是不可能擁有的奢侈品。
程式設計語言社群一直在開發的技術并沒有壞掉，但它們需要适應在職開發人員的需求！在下一節中，我将讨論如何做到這一點。
4、工具需要适應開發人員的日常生活
為了适應開發人員的生活，程式設計工具建立者需要根據預期的開發體驗來倒推具體的方案，而不是從我們想要建構的技術去正推結果。為了做到這一點，我們需要接觸一個技術人員經常視為肮髒詞彙的學科：設計。
我經常看到忽視設計的程式設計工具，但我相信這是因為人們誤解了設計的含義。特别是在程式設計工具中，設計意味着減少摩擦以幫助開發人員到達他們需要去的地方，而不是裝飾外觀或裝點使用者體驗的小玩意兒，例如可愛的錯誤消息或黑暗模式。
以下是我從使用者研究和與設計師合作的過程中學到的一些經驗教訓，它們可以幫助我們打包現有技術，讓它們直接助力開發人員的工作：
工具解決的問題比什麼都重要。在技術程式設計語言社群中，我經常看到人們更多地強調他們正在建構的是什麼東西而不是他們正在解決哪些問題——而且給使用者一個模糊的、假設性的圖景往往也不被認為是什麼大事。例如，我經常看到函數式程式設計愛好者出于與軟體團隊當下面對的高優先級問題無關的技術原因（更多保證；優雅）而發起争論，争辯說他們的語言更适合開發人員。如果人們不采用這些技術，可能并不是因為他們沒有“明白”這項技術有多酷，而是因為他們不知道它是怎樣幫助他們解決最重要的問題的。
适應工作流程比技術“驚歎”更重要。特别是對于“深度技術”工具來說，這些工具的開發者往往在乎的是自己做的事情是不是夠新夠酷。在對開發人員進行了幾十次使用者研究調查後，我開始了解各款工具在生态系統中的作用。當我問開發人員為什麼采用工具 X 或 Y 時，答案通常是它适合他們的程式設計語言或基礎架構，或者它有他們想要的 Slack/GitHub/Jira 內建。我看到的許多“深度技術”工具都假設開發人員會切換到全新的工具鍊，隻是為了獲得相對較少的好處。對于大多數軟體團隊來說，這是不可能的。
包裝往往比技術解決方案更重要。如果你是一名開發人員，隻是為了證明某件事物是可行的而去跑上它幾次，那麼它的輸出不那麼好看也沒關系，并且你也不在乎去查查資料或者手工美化它一下以加深了解。如果你要日複一日地使用某款工具并與你的團隊共享結果，那麼如果它能花時間撫平粗糙邊緣，讓你很容易看到你需要看到的輸出，并讓你輕松地對結果做你想做的事情，就會是很不一樣的體驗。
正如我在 Akita 所經曆的那樣，在建構深度技術的同時采取面向設計的視角是相當困難的——我看到大公司附屬的研究實驗室在這方面做的不錯，畢竟那裡有幾乎無限的資源。但我确實相信這在初創公司中是有可能做到的，尤其是我們現在看到開發工具公司在早期就能獲得相當大的資本支援，我很想看到更多初創公司采用這種理念。
5、前進的道路
我們正在邁入開發工具的黃金時代——我很樂意看到“深度技術”開發工具能分得一杯羹。我離開了學術界，因為我覺得自己可以利用程式設計語言和軟體分析方面的專業知識為開發人員解決很多核心問題。另外我寫這篇文章的很大一部分動機是因為這個任務對于一個團隊來說負擔太大了！我深信，隻要我們将正确的技術與正确的問題相結合，就可以讓軟體開發過程比現在更加順暢，甚至更令人愉悅。
從程式設計工具一側來看，為了獲得更廣泛的采用率，工具需要做到以下目标：
更多地滿足開發人員的需求、适應工具所在的工作流程
與現有開發工具的互操作性更強
更多适用于現有内容的增量改進
更多符合開發者優先級順序的設計
減少對 100% 保證的關注
減少對建構“新世界”的關注
如果你是程式設計工具的消費者，希望獲得更好的工具，你也可以做些力所能及的事情！為了讓“深度技術”程式設計工具在生态系統中更受歡迎，我認為開發人員需要做到以下幾點：
接受更多邊緣有點粗糙的工具——人們很難為完全新生的事物創造良好的開發體驗！
接受更多 、複雜性探索工具
提供更多關于你想使用某些工具 / 工具類來解決問題的回報
不要那麼期待“銀彈”
不要夢想“有一種語言來解決一切”
對拖累開發人員生産力的流程少些耐心，尤其是在影響業務（更容易修複）的層面
顯然，這說起來容易做起來難！我已經在 Akita 走過了多年的旅程——并且還在很多事情上尋找答案。但我們談論這個話題越多，開發者工具愛好者能夠團結起來的希望就越大，我們就更可能利用最前沿的技術讓開發者的生活更加美好！