大部分軟體工程其實就是管道作業

作者｜Karl L. Hughes

譯者｜薛命燈

編輯丨小智

我最近在網上讀到一篇有關軟體工程師電話技術面試的文章，為了拿到 offer，一個工程師必須在電話里完成一個非常複雜的代碼挑戰。他表現得很好，也拿到了 offer，但在加入公司後，他發現他所做的工作與預期相去甚遠。他的主要任務就是為運行在虛擬機上的遺留系統構建基本的 CRUD。

在招聘中，這類情況一直在發生。我們讓工程師通過嚴格的篩選程序，問他們一些有挑戰性的問題，但在把他們招進公司之後，只是讓他們做一些枯燥乏味的事情，比如負責由五六個服務組成的系統，或者讓頁面看起來更漂亮些。我並不是說這些任務就不需要技能，只是這些任務所需要的技能與大多數面試涉及的內容根本不一樣。

剝掉糖衣

軟體是因為能夠提供業務價值，所以才被創建出來。

雖然閱讀有關軟體工藝的書籍並且在軟體技術上追求卓越對我們來說頗具吸引力，但歸根結底，如果不能形成業務並從中賺到錢（或省錢），我們的工作就毫無意義。

因此，軟體行業的現狀自有它的道理。就像水管工一樣，他們獲得報酬，是因為他們了解自己所使用的工具，並知道如何使用它們讓設備運轉起來，而不是讓他們重新發明技術，或者花 80 個小時去優化只有 5% 的用戶會用到的東西。

正視問題

中小型企業很少會去處理與規模擴展或優化相關的問題——一部分原因是硬體變得越來越便宜，一部分原因是基礎的開源軟體已經做得很好了。這是一件好事，作為軟體開發人員，我們應該擁抱這樣的現實。

現在讓我們回到管道問題上。想像一下，你擁有一家帶有一個洗手間和 10 名員工的小餐館。你每周有幾百個顧客，其中 10％可能會使用你的洗手間。顯然，你必須要有一個洗手間，但它是否需要比你家的廁所更高檔或更先進？你需要 10 個隔間、活動龍頭、戴森干手器和大理石櫃檯嗎？可能不需要，除非你想要表現你的闊氣。

然而，我們卻一直在初創軟體工程領域做著類似的事情。

一家擁有 5 到 10 名員工的小型企業，他們在構建 SaaS Web 應用程序時需要一個可靠、安全的系統，但這個系統是否需要比現成提供的服務更強大？是否真的需要基於人工智慧的搜索？是否真的需要為每個團隊成員提供實時的儀錶盤？是否真的需要微秒級的主頁載入速度？是否真的需要為發布的每個功能進行拆分測試？可能不需要，除非你想要表現自己有多「成功」……

就像優秀的小企業主應該僱用知道如何使用標準工具修理洗手間的管道工並按照市場行情支付他們報酬一樣，優秀的工程經理應該聘請知道如何使用行業標準工具來開發可靠軟體的團隊成員，並按市場行情支付他們報酬。

然而，我所看到的很多工程經理的做法都是相反的。他們在面試中給人的印象是，他們僱用的每個人都必須是高級工程師，必須具備「大數據」經驗，或者必須深入了解每種排序演算法。

我們犯了過度工程的罪

另一個問題是我們的軟體過度設計了。從這方面講，我也是有罪的。

我剛加入 Graide Network 公司就立即開始將遺留應用程序分解為微服務。現在，我不得不為新來的開發人員提供自定義工具，以便讓他們在本地計算機上把系統運行起來——而在我們的業務生命周期中，這並非真正值得花費時間的事情。

這也讓我自己很難招到人。我不想將候選人限定在了解多個特定 Web 框架、Docker 容器、微服務、Redis 和 MySQL 的工程師身上，但我已經把自己逼到了這樣的角落裡。最近我才意識到這一點，並開始考慮簡化我們的技術棧，以後我會另寫文章來說明。

投資者犯了「壓迫」我們的罪

另一方面是來自投資者和媒體的壓力。在初創領域，這一點尤其明顯，因為我發現投資者就像記者那樣喜歡抓住一些熱詞不放。

「哦，所以你正在開發一個應用程序？它使用 AI 了嗎？區塊鏈呢？拿我的錢去做吧！「

於是你把自己賣給了投資者，成為一家 AI 或區塊鏈公司，所以你必須聘請這方面的工程師，即使你不確定這樣是否真的能夠幫你建立起更好的業務。於是你避開了那些在現有技術領域擁有超過 10 年經驗的候選人，把橄欖枝伸向了那些追逐熱詞的小鮮肉。這就像聘請了一位只有 3 年經驗卻自己發明了工具的水管工，高風險、低回報。

我們該怎麼辦？

我們生活在一個大多數「軟體工程」基本上就是管道作業的世界裡。我們該怎麼辦？這對於我們的職業生涯來說意味著什麼？現金流會一直持續下去嗎？

首先，我們應該認識到並接受這樣的一個事實，即我們可以用更少的資源構建更多的東西。也就是說，我們工作中不是那麼有價值的部分可能進行自動化，或者構建工具，讓業務人員為我們做這些工作。例如，每當我的團隊中有人想要修改自動電子郵件副本時，我就要去修改代碼。而現在，他們只需要在可視化編輯器中編輯模板，我甚至都不知道它們被改過了。

其次，我們在設計系統時需要考慮到系統的複雜性。如果有現成的解決方案，那麼就用它，不要再從頭開始構建。我們要學會組裝零件，這樣就可以比那些每次在啟動項目時都要自定義構建框架的軟體工匠更高效、更快、更好。

第三，我們應該設定切合實際的期望。大部分編碼工作都只要求 CS 學位，而這些工作所涉及的內容可能只比知道如何導入庫和了解 HTTP 原理多那麼一點點。不過確實有些工作需要進行微優化，但這類工作可能很少，而且離我們很遠。你的軟體可能沒有你想像的那麼特別。

最後，不要陷入了舒適區而不能自拔。這並不是軟體工程師的普遍看法，但我相信在這個領域裡，有很多人拿到的報酬已經遠遠超出了他們所從事工作的難度。有時候是因為他們是這個領域唯一知道怎麼做這些事情的人，有時候是因為他們所在的公司無法從人才市場上招到更好的人，有時候是因為其他工程師故意過度設計，這樣初級開發人員就需要花費很長時間才能理解它。無論如何，如果我們想要保持高薪和不被踢出局，就不能停止學習。加強知識的廣度和深度，並學會如何將炒作從真正的突破性技術中過濾掉。

https://www.karllhughes.com/posts/plumbing

InfoQer 說

各位 InfoQ 的讀者朋友，你有經歷過哪些「面試造核彈，入職擰螺絲」的工作呢？快在留言區告訴我們吧！

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！