終于進入到程序員看上去最熟悉的一個主題：自動化。

每每提及自動化，我就會想起 Perl 語言的發明人 Larry Wall 一個經典敘述：優秀程序員應該有三大美德：懶惰、急躁和傲慢（Laziness, Impatience and hubris）。

有人甚至為此專門打造了一個三大美德的網站，闡釋這個初看起來匪夷所思的說法。

懶惰，是一種品質，它會使你花很大力氣去規避過度的精力消耗，敦促你寫出節省體力的程序，別人也能很好地利用，你還會為此寫出完善的文檔，以免別人來問問題。

急躁，是計算機偷懶時，你會感到的一種憤怒。它會促使你寫出超越預期的程序，而不只是響應需求。

傲慢，極度自信，寫出（或維護）別人挑不出毛病的程序。

不知道你是否感受到，程序員獨有的幽默和透露出的那種驕傲：我做的東西就應該是最好的。

之所以要從 Larry Wall 的這段話開啟“自動化”這個模塊，因為只要一說到自動化，我就會情不自禁地聯想到“偷懶”這個詞。是的，我們程序員的工作，本質上就是打造各種自動化的工具，讓人們從各種繁復的工作中解脫出來，讓人有機會“偷懶”。

不過，我也知道，從機器那里偷來的“懶”很快就被更多的工作填滿了。但 Larry Wall 的這段話卻可以鼓勵我們不斷地打造出更好的工具。

作為程序員，你當然知道“自動化”這件事的價值，在日常工作中，也實實在在地踐行著打造自動化工具的任務，但很多人對自動化的理解可能有些單薄。今天，我就從一個你可能會忽略的主題開始討論：不要自動化。

不要自動化

我先給你講一個讓我印象深刻的“不自動化”的例子。

之前在 ThoughtWorks 工作時，我們有一項工作是，幫助其他公司啟動一些新產品。有一次，我的兩個同事被一個公司請去啟動一個視頻網站的項目。那時候還不像如今的市場，已經由幾大視頻網站瓜分完畢，當時不少公司看到了視頻網站的苗頭，覺得自己有機會。這個來請我們的公司也不例外，覺得自己也能分一杯羹。

兩個星期之后，我的兩個同事回來了。我們饒有興趣地去問項目的進展，因為項目啟動之后，通常會有后續的開發合作，但結果令我們很意外，這個項目停止了。

“出了什么狀況嗎？”我們問。

“是我們建議用戶停掉這個項目的。”他們回答道。

我們“恨恨地”問他們為什么丟掉了一個這么重要的機會。這兩個同事的回答也很直白，他們結合著客戶的想法算了一筆賬：這個項目需要大量的資金投入，投入規模之大，是超出客戶想象的，按照現有的規劃投入，這個項目肯定會虧本。要么重新規劃，要么取消這個項目。客戶認真研究了一番，最終決定取消項目。

這件事大約發生在10年前，今天我們都看到各大視頻網站在燒錢上的投入，以那個公司的實力，想要參加這場比拼，確實還差太多。

這件事之所以給我留下深刻印象，因為它是我職業生涯中見到的第一個通過“主動取消項目”獲取項目成功的案例。

或許你不能理解我這里所說的“項目成功”。在我看來，做有價值的事是重要的，這里面的有價值，不僅僅是“做”了什么，通過“不做”節省時間和成本也是有價值的。我的兩個同事阻止了客戶的浪費，所以，我將這個項目視為成功。

對于開發來說，也遵循同樣的道理。程序員這個群體技術能力實在太強，做一個技術方案簡直是太符合直覺的做法，我們就是忠實地把一個個需求做出來，把“全世界”都自動化了。

但事實上，這個世界太多的浪費就是做了不該做的東西。在我們的專欄里，我反復地說，我們要多問問題，目的就是為了不做那些不該做的事。

小心 NIH 綜合癥

你可以從需求的角度判斷哪些工作是可以不做的，但我們也要防止程序員自己“加戲”，我再給你講一個技術人員普遍存在的問題：NIH 綜合癥（Not Invented Here Syndrome）。

NIH 是什么意思？就是有人特別看不上別人做的東西，非要自己做出一套來，原因只是因為那個東西不是我做的，可能存在各種問題。

這種現象在開源之前尤為流行，很多公司都要做自己的中間件，做自己的數據庫封裝。雖然很多公司因此有了自己特色的框架，但是因為水平有限，做出來的東西通常極為難用，很多人一邊罵，一邊還要繼續在上面開發。

開源運動興起之后，我以為這種現象會好一些，但事實證明，我想多了。

比如，這種亂象在前端領域也出現了，各種各樣的框架，讓很多前端程序員哭訴，實在學不動了。再比如，我曾經面試過一個接觸 Go 比較早的程序員，他就是恨不得把所有框架都自己寫。

因為他學 Go 的時候，確實框架比較少，但問題是，如今的 Go 已經不是他學習時的那個 Go 了，現在各種框架已經很豐富了，不需要什么都自己做。當時我問他，如果有一天你離開了，公司怎么辦呢？實際上，他從來沒考慮過這個問題。

說了這么多，無非就是想說明一件事，寫代碼之前，先問問自己真的要做嗎？能不做就不做，直到你有了足夠的理由去做。對應到 Larry Wall 的說法，你要懶惰，花大力氣去規避精力消耗。

做好自動化

說完了不要自動化的部分，再來說說要自動化的部分。

我還是先從你可能會忽略的問題入手，你的日常工作是給別人打造自動化，但你自己的工作夠自動化嗎？還是問一個更具體的問題吧！如果你寫的代碼要上線，會經過怎樣的過程？

我先給你看一個極其糟糕的例子。剛開始工作不久，我有一次出差到客戶現場。臨近下班時，我發現了程序的一個Bug。在那個年代，我們的程序是按照官方推薦做法編寫的 EJB（Enterprise JavaBean），今天很多年輕的程序員可能不了解了，它只有部署到應用服務器才能運行。

我的解決方案就是加上一些打印語句，然后部署到應用服務器上，看輸出的結果，再加上另外一些語句，再部署，如此往復。那時我們完全是手工打包上傳，每次至少要十幾分鐘。最終，定位到了問題，只修改了一行代碼。但幾個小時的時間就這樣被無謂的消耗了。

那之后，我花了很長時間研究怎么做自動化的增量部署，最終讓這個過程簡化了下來。但這件事對我的影響很大，這是我第一次認識到一個部署過程可能對開發造成的影響，也讓我對自動化在開發過程內的應用有了屬于自己的認識。

相比于我剛開始工作那會。現在在工具層面做類似的事已經容易很多了，在后面的內容中，我會結合著具體的場景介紹一下現在的最佳實踐。

你要懂得軟件設計

最后，我們再來說說我們的本職工作，給別人打造自動化工具中需要的能力：軟件設計。

軟件設計，是很多人既熟悉又陌生的一個詞，說熟悉，很多人都知道，做軟件要設計，還能順嘴說出幾個設計模式的名字；說陌生，是因為在我的職業生涯中，遇到真正懂軟件設計的程序員少之又少。大多數人都是混淆了設計和實現。

舉個例子。有一次，我要在兩個系統之間做一個連接器，讓上游系統向下游系統發消息，或許你一聽就知道了，這里需要的是一個消息隊列。但實際上，我們需要的能力要比消息隊列更豐富一些，比如，要將重復的消息去除。一個同事給我推薦了 Kafka 當作這個連接器的基礎，我欣然地接受了。

不過，在后續設計的討論中，我們就經常出現話語體系的分歧。我說，這個連接器要有怎樣的能力，他會說 Kafka 能夠如何如何。究其根因，我在討論的是設計，而他說的是實現，所以，我們兩個很難把問題討論到一起。

為什么我會如此看重設計呢？在軟件開發中，其它的東西都是易變的，唯有設計的可變性是你可以控制的。

同樣以前面的討論為例，盡管 Kafka 在當下比較火熱，但是我不敢保證 Kafka 在未來不會被我換掉。因為就在幾年前，消息隊列還是傳統中間件的強項，現在也漸漸被人淡忘了。

我不想讓我的設計隨著某一個技術選型而不斷搖擺。如果工作許多年，知識體系只能靠各種新框架新工具支撐，我們做程序員就只剩下疲于奔命了。不懂軟件設計，只專注各種工具，其結果一定是被新技術遺棄，這也是很多人經常抱怨 IT 行業變化快的重要原因。

回到 Larry Wall 的說法上，你要想寫出一個別人挑不出毛病的程序，你先要懂得軟件設計。幸運的是，軟件設計這些年的變化真不大，掌握了軟件設計再來看很多框架和工具，學習起來就會容易很多。在這個模塊的后半部分，我會與你探討軟件設計的話題，降低自己給自己挖坑的概率。

總結時刻

Perl 語言的發明人 Larry Wall 曾經說過，優秀程序員應該有三大美德：懶惰、急躁和傲慢（Laziness, Impatience and hubris）。想要成為一個優秀的程序員，就要讓機器為自己很好地工作，而這需要對自動化有著很好地理解。

我們學習自動化，先要知道哪些東西不要自動化，盡最大的努力不做浪費時間的事。一方面，我們要從需求上規避那些沒必要做的事；另一方面，我們也從自身防止 NIH 綜合癥（Not Invented Here Syndrome），爭取做一個懶惰的程序員。

對于要自動化的事，我們需要反思一下，在為別人打造自動化工具的同時，我們自己的工作過程有沒有很好地自動化。而如果我們想擁有打造良好的自動化工具，我們需要對軟件設計有著充分地理解。

如果今天的內容你只能記住一件事，那請記住：請謹慎地將工作自動化。

最后，我想請你分享一下，學習了本講之后，你現在是怎樣理解自動化的呢？歡迎在留言區寫下你的想法。

感謝閱讀，如果你覺得這篇文章對你有幫助的話，也歡迎把它分享給你的朋友。

總結

以上是生活随笔為你收集整理的29 | “懒惰”应该是所有程序员的骄傲的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。