我叫 Dan McKinley，坑裡的那個人就是我。
我現在在一家叫作 Mailchimp 的公司上班。更早之前是在 Etsy，因為在 Etsy 待的時間比較長，所以後面會更多地提到我在這家公司的經歷。其實在離開 Etsy 之後，我也在其他幾家公司幹過。
我既在大公司待過，也在小公司待過，還創辦過自己的公司。在經歷了這些公司之後，我注意到了一些現象。
大公司有自己的做事方式，他們提供了“沙盒”一樣的環境，在這樣的環境裡，會有人滿足你的需求，幫你答疑解惑，讓你感覺受到了“百般寵愛”。
但我也經歷過幾個過渡時期，在這些過渡時期，需要自己解決一些棘手的問題。
首先，如何選擇合適的技術？
另一個我比較關心的問題是：如何讓開發人員開心地使用這些技術？因為我自己也是開發者，所以這一點對於我來說比較重要。如果有可能，我會盡量讓自己過得開心些。
如果你問開發人員什麼東西會讓他們開心，他們通常會說：“如果可以使用 Clojure 作為開發語言，我就會很開心”。我不否認，當他們說這些話的時候，他們腦子裡浮現的應該是曾經最讓他們感到興奮的經歷。
但我相信他們所描述的這種狀態是他們所能達到的最高的精神境界。
我以前也喜歡這樣。
例如，Etsy 的早期應用程序是用 PHP 開發的，而開發這些應用程序的人當時剛好在學習 PHP。
但我卻花了好幾年時間儘量不去碰觸這些 PHP 代碼，我甚至嘗試使用 Scala 和 MongoDB 來重新開發這些服務，因為我認為它們才是更好的技術棧，可以解決所有的開發效率問題。但事實上，沒有任何跡象表明我的做法是對的。
現在在網上還能找到我在這段時期所做的一些尷尬的事情，你可以把它們搜出來，然後用它們來取笑我。現在的 Etsy 員工還在拿這些東西來調侃我。
後來我創辦了自己的公司，用上了 Clojure。雖然，這家公司現在已經不在了。但請不要多想，公司倒閉並不是因為使用了 Clojure。
不過我還是很樂意分享這段經歷，畢竟我也是個體驗過函數式編程樂趣的人。
我並不是一個容易沉迷於開發技術的工程師。我的其他演講很少是關於工程技術的。
我還沒老到或者脾氣暴躁到成為那樣的人。但通過總結馬洛斯需求金字塔理論，我也有了自己的看法。
簡單地說，馬洛斯需求金字塔就是指在滿足更高層次的需求之前，需要先滿足較低層次的需求。如果你連肚子都填不飽，哪裡還有心情吟詩作對？
雖然這個比喻不一定非常貼切，但在軟件開發領域，這是事實。如果你還在忙於討論要使用哪個數據庫，怎麼可能有時間去擔心整個產品的藍圖？
幸運的是，在我經歷的一些場景中，基本需求都得到了滿足，所以我希望也能讓其他項目進入這樣的狀態。
要達到這樣的狀態，首先要集中注意力。人類專注細節的能力是有限的。
我的朋友 Andrew 總是穿同一牌子的黑 T 恤。他認為，如果把花在挑選衣服上的精力囤起來，就可以把它們花在其他更有意義的事情上。
我不知道這樣做算不算缺乏品味，但我覺得是有意義的。
接下來我要談談我的想法。假設我們手上有一些代幣，但數量有限。
這些代幣代表了我們的創新能力或解決困難挑戰的能力。在一家公司的早期，我們可能有三枚這樣的代幣。
那麼你的公司會怎麼做？Etsy，也就是我之前工作過的公司，宣稱要重塑整個世界的經濟。
我不知道開發者該如何看待一家科技公司所宣揚的使命，我是覺得壓根就不應該把它當回事。
不過，現在姑且讓我們保留一點點“天真”，看看如果這家公司真的要改變世界，結果會怎樣。
重塑整個世界經濟不是一件小事，可能需要花掉一個代幣。
離開 Etsy 之後，我加入了另一家公司，這家公司想要“增加互聯網的 GDP”。
這個看起來也是件大事，所以可能也需要花掉一個或兩個或所有的代幣。
即使你認為創新是一種稀缺資源，但對於已經很成熟的數據庫或編程範式來說，創新並沒有太大意義。
問題不在於說它們的創新不可行，實際上，它們是可行的。
但在軟件開發領域，越是晚出現的東西越是需要更多的關注。
為了找出其中的原因，我想從哲學方面入手。對於一項技術，我知道多少東西？
我不喜歡 Donald Rumsfeld（美國前國防部長），我希望他滾蛋。但他與我們要討論的問題有關，所以我不得不忍受他惡魔般的存在。
在面對未知事物時，通常有兩種情況。
一種是“已知的未知”（known unknown），也就是那些我們知道自己不瞭解的東西。還有一種是“未知的未知”（unknown unknown），也就是那些我們不知道自己不知道的東西。
這是一個“已知未知”的例子。當數據庫發生故障時，我們可能不知道具體原因是什麼，但我們知道網絡分區有可能是造成故障的原因之一。因為我們知道有這個可能性，所以可以進行針對性的測試。或者我們也可以雙手合十，希望這個跟網絡分區沒有關係。不管怎樣，我們都知道有這個可能性存在。
還有一些是“未知的未知”。這是我最近看到的一個例子：一個人花了四個月時間試圖弄清楚為什麼會出現 GC 停頓，結果發現是因為他往文件中寫入了統計信息。顯然，他事先並不知道會發生這樣的事情。
軟件中的很多 bug 都是這樣的。我們並不知道系統裡存在這些 bug，它們都是“未知的未知”。
現在，我們知道這兩種“未知”在軟件系統中都存在。一個 10 年的老軟件系統通常在 JIRA 裡會有很多相應的 ticket，沒有人會去修復這些問題。除了這些，系統裡還會有很多未知的 bug。
但並非所有技術都是一樣的，新技術更有可能出現這兩種情況。
我選擇了“無聊的技術”作為標題，併為此後悔了好多天。因為有人說：“無聊的就是糟糕的，你為什麼還說它是好東西呢？”
但我所說的“無聊”與 CSPAN（美國總統電視系列）的無聊是不一樣的，我所說的“無聊”是指有些東西我們已經很瞭解了。如果你認為一項技術不夠好，那是因為你已經知道其中的原因了。
你可以只使用 Postgres，這樣就萬事大吉了？不，你所選擇的技術組合也有問題。
假設你已經使用了這個技術棧：Python、Memcached、MySQL 和 Apache。
然後你有一個新的問題需要解決。那麼，你認為在技術棧里加入 Ruby 會有助於你解決問題嗎？
幾乎所有人都會說：“天哪，這怎麼可能！”
我們知道，加入 Ruby 給我們帶來的邊際效益並不會多過它給我們帶來的複雜性，因為 Python 和 Ruby 基本上就是類似的東西。
好吧，那麼加入 Redis 呢？我們已經有 MySQL 和 Memcached 了，還需要加入 Redis 嗎？
從我的經驗來看，這就是問題的關鍵所在。出了問題就打著多語言編程的旗號，就像帶著一班人攻擊巴士底獄一樣，然後說：“你不能阻止我們使用最好的工具來完成這項工作。”
當人們開始屈服於這種本能，就會說服自己：這是在給開發者更多的自由。的確，這是一種自由，但其實是一種狹義的自由。
那麼，這背後究竟是怎麼回事？讓我們來探究一下。
當我們要往項目裡添加一些半冗餘的技術時，通常是這想的：“這項新技術在短期內會讓開發變得更容易，它給我們帶來的好處超過了採用新技術所耗費的成本”。
我們可以換一種結構化的思維來考慮這個問題。
假設你的工作就像我的朋友 Coda 所說的那樣：通過技術來解決業務問題。
因為我們所在的領域和計算機科學有一定關係，所以不妨先假設自己是計算機科學家，並用二分圖來描述我們的問題。
我們需要把左圖所有的點與右圖的點連接起來，這樣才算把問題解決了。連接一條邊表示做出了一項技術決策。
每一個技術決策都有一定的維護成本，但同時也享受著新技術帶來的好處。
也就是說，每一項技術決策既會給我們帶來好處，也需要我們承擔一定的成本。
我們可以使用之前已經選好的技術。
也可以選擇其他技術。選擇新技術需要承擔相應的成本，但如果採用新技術會加快開發速度，那麼就是值得的。
我們試圖最小化這個成本函數。總成本等於總維護成本減去開發速度的提升和從這些技術決策中得到的好處。
我們的行為實際上取決於方程中的哪一項在現實當中占主導地位。
如果技術維護成本很高，那麼成本就占主導地位。如果技術極大地改變了開發方式，那麼技術所帶來的好處就占主導地位。
所以，你可能會像圖中所示的那樣，使用不同的技術把所有問題都解決了。
如果說每增加一種技術的成本很低，那麼這樣做就沒什麼問題。
這是另外一種策略。我們只選擇了一部分技術來解決所有問題。
當新技術會給我們帶來很大負擔時才會這麼做。
在現實中，新的技術決策通常伴隨著很大的負擔。
長期維護一項技術的成本通常會超過它能夠給我們帶來的便利性。
所以，通常我們會選擇可以解決所有問題的最小技術集合。
要把技術維護做到很專業其實是很難的。在剛開始時可能很容易，但越到後面就越難。
為什麼會這樣？添加新技術很容易，但要維護好並不容易。
比如，我現在就可以用 brew 安裝一個數據庫，然後開始寫代碼。但要在生產環境中運行整個系統又是另一碼事了。
所以，技術多元化並不是我們要追求的自由。
如果你將局部決策權賦予個別團隊，會對全局造成傷害。
從某個角度來看，這確實是一種自由。你把一團鏈條和掛鎖交給了開發者，然後告訴他們可以自由地做出技術決策。這些技術決策會一直伴隨著它們，直到死神來臨……
更糟糕的是，技術多元化不僅會給我們帶來重複勞動和維護開銷，還消除了使用共享平臺給我們帶來的積極正面的好處。
以 Etsy 網站的活動頁為例。
Twitter 和 Facebook 都有類似的功能。Etsy 在經歷了多年的風投之後，也想要一個跟他們類似的功能。
所以，在 2000 年，我開發了這個小功能。
要開發一個活動流功能，可以像下面這樣：從外部獲取事件，把事件寫入數據庫。然後另一個進程（比如機器學習）對這些事件進行聚合，把結果寫到 Redis 裡，最後前端流量就可以訪問 Redis 裡的數據了。
在我們剛開始開發這個功能時還沒有 Redis，所以我們選擇了 Memcached。它們的功能很類似：存儲二進制對象，然後通過相似的 API 獲取對象。但它們在某些方面很不一樣，對於我們來說，最大的不同是 Redis 支持持久化，而 Memcached 不支持。
也就是說，在使用 Memcached 時，我們需要做一些額外的工作。因為可能當你需要某些數據時，Memcached 剛好給你弄丟了。
為此，我們需要多做很多額外的開發工作。但我們將這些額外工作與新加入一個數據庫可能帶來的運營成本相比，還是決定硬著頭皮繼續使用 Memcached。
就這樣過了幾年，我們也很少想起這件事。
有一天，我不禁想起了這個功能。然後很吃驚地發現這個功能的使用流量比最開始時增加了 20 倍。
這個功能的用戶增加了 2000%，而我竟然毫不知情。當然，這無疑是我技術職業生涯的一個巨大成就。
之所以會出現這種情況，是因為我們使用了共享基礎設施。共享基礎設施會有專人照看，他們會在必要的時候增加更多的 MySQL 實例或者其他資源，還有一些人負責把新機器運行數據中心，把它們加到基礎設施裡。這是一種橫向伸縮。但是，這些人都不知道我們開發的這個應用程序。
如果我們當初使用的是 Redis，那麼可以肯定的是，在用戶流量增加 20 倍之後，一定會在某個時刻出現瓶頸。如果是這樣的話，我們就不得不自己去倒騰 Redis 的擴容問題。
或者更有可能是讓其他人來做這件事情，因為我們的團隊在一年後解散了。
但我發現，人們其實並不喜歡給別人擦屁股，所以這件事對於任何人來說都是很件苦差事。
我想借這個例子告訴大家，請儘量選擇成熟的技術，而且儘量不要使用過多的技術。
但這也只是個建議，請不要把它當成是一個準則，因為有時候往技術棧裡添加新技術也是有必要的。
問題在於如何選擇新技術。
簡單地說就是：你要和大家一起討論。
因為在公司層面採用新技術涉及到整個公司的利益，並不是工程師個人的事情。
在討論過程中，你可以這麼問：“如果不使用新技術，那該怎麼解決眼前的這個問題？”
這個問題其實就是要採用新技術的一個徵兆。“可能是因為我們沒有使用 Cassandra，要不我們試試看”。只要走多這一步，後面就可以停止討論了。
假設你在現實當中遇到了這樣的問題。比如，你在生產環境中部署了一個服務，而你認為如果不在使用新技術就無法完成新的功能，那可能是因為你想得不夠多。
你可能需要使用一些特別的方法，但不管怎樣，你完全可以基於簡單的技術棧獲得更好的效果。
你可以把需要做的事情列出來，你會發現情況並沒有想象的那麼糟糕。即使它們看起來很糟糕，但肯定不會比維護新技術更糟糕。
當然，也會出現另一種情況：當你把所有東西都列出來後，你會發現採用新技術可能更值得。
如果你決定採用新技術，那麼就要想辦法把風險降到最低。不要試圖一次性重寫整個應用程序，而是要循序漸進，每次修改一點點，逐步建立信心。
如果你往技術棧裡添加了與之前類似的技術，那麼就要想辦法把舊技術替換掉，而不是同時維護兩種技術。這是一個長期的計劃。如果發現新技術不合適，還要有回退的能力。
總 結
選擇人們所熟知的技術。
所選擇的技術應該能夠讓你把注意力放在值得的東西上。
從整體考慮問題，你所選擇的技術應該能夠覆蓋到整個問題領域，並解決所有問題。
掌握你所選擇的技術，這一點很關鍵。
我發現幾乎所有的軟件系統都遵循這個定律。在剛開始時你會覺得它們很爛，因為你會碰到很多問題。
如果你是一個新手，可以試著在實踐中驗證這條定律。你可以試著把新開發的功能部署到生產環境，然後你就會想：下一個新功能我想嘗試新的技術。
但使用新技術並不一定會更好，因為你根本不知道它們還會出什麼問題。
可能是因為你跳過了曲線的”Mastery“部分。儘管在這個階段仍然存在問題，但你會覺得這些問題是可控的。
這個定律有一個可怕的悖論：或許你要使用你最討厭的技術，因為你越是討厭它，說明你對它越瞭解。
在使用新技術時，你需要遵循一定的流程，比如先和其他人一起討論。
你應該試著順著馬洛斯需求金字塔網上爬，從全局看問題，而不是每天想著是使用這個數據庫還是那個數據庫。如果你每天的工作就是幹這個，那一定是哪裡出了問題。
做有意義的工作會讓你幸福感滿滿。
好了，現在可以把我從坑裡挖出來了嗎？
【擴展閱讀：技術總監之路系列】
喜歡關於程序猿成長的內容，可關注我的頭條號 “軟件真理與光”！
閱讀更多 軟件真理與光 的文章
