17年程式設計生涯的三大經驗總結

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

今年將迎來我程式設計的第十七個年頭。我的程式設計之旅始於九十年代末，上大學的時候，主要涉足基於表格的網頁設計，傳統的ASP，和Microsoft Access資料庫。原來只是當作業餘愛好的程式設計現在已經成為了我的事業和激情。我一生一半的時間都在學習、蹣跚、成功、失敗，並且經常情不自禁地為程式碼美麗和複雜的天性而折腰。

我在程式碼上淫浸了足夠長的時間，因此看到了很多語言和平臺的興盛和消亡，看到了很多模式被普及，被苛責，然後再次被推廣。在某些時候，我常常分不清這是大勢所趨還是明日黃花。

程式設計的流行趨勢是短暫的，但我堅守的規則，往往在生活中的其他地方也能發揮作用。事實上，生活就像程式碼（我已經買了這個域名來證明這一點！）。以下是我總結的3個偉大的經驗教訓，歷經一次又一次程式設計和生活的大浪淘沙。

1.可商榷的決定往往是一種權衡。

偉大的辯論總是發生在開發社群中。無論它是最近關於TDD作為web開發的一種可行方法的辯論，還是什麼水平的開發人員應該使用ORM（或micro-ORMs）。無論是.NET MVC應該優於WebForms還是以JavaScript為中心的app應該比基於頁面的app更受青睞，對我來說，答案都一樣：看你權衡之後的取捨？

在任何比較兩種流行方法的辯論中，我們總是會從自己的立場出發，兩利相權取其重，兩害相權取其輕。在我的職業生涯早期，我曾執著於追求所謂的正確答案。感覺過程是線性的：擺脫做事的老辦法，轉而投向新的並且更好的方法的懷抱。曾經有一段時間我深信，編寫自己的SQL查詢是一種過時的練習，並且ORMs是最後贏家。

但是，我瞭解到，更好的辦法應該由內容決定的。例如，今天完全成熟的ORMs在隔離對映相關資料網格到物件的冗長管道提供了偉大服務，但隔離也使得某種非標準查詢變得困難並且有潛在的效率低下問題。n+1 select problem就是經典的在少寫程式碼和寫更多高效程式碼之間做權衡。我使用ORM的程度完全受我期待應用程式使用的資料量，我所受到的潛在的時間限制，app長期可擴充套件性需求這三者的影響。（順便說一句，我目前是micro-ORMs，比如說Dapper的忠實粉絲，它能讓我編寫我自己的SQL和一些精巧的物件-關係對映）。

我已經將這個經驗應用到了我生活的其他方面。我是應該買一套公寓還是長租房子？我是應該啟動自己的生意還是工作於已經成立的公司？沒有絕對正確的選擇。當你權衡利弊了之後，你便可以更好地應對生活中的各種難題。

2.清晰並不總和簡潔相關。

和大多數工程師一樣，我對持續重構一直到程式碼儘可能地少和簡潔的機會垂涎三尺。如果可以選擇更少又更簡潔的程式碼來完成同樣的任務，那麼我為什麼要選擇要個更多程式碼的方案呢？通常情況下，更簡潔的語言會導致更好的交流。畫蛇添足只會阻礙核心資訊的提取。但是，最終的目標不應該是簡潔——而應該是可交流。於我而言，下面這段直截了當的程式碼，在它更長的時候……

if (HasFarm() && HasBoat())
{
  Broadcast("You are wealthy!");
}
else if (HasFarm() && !HasBoat())
{
  Broadcast("You are OK!");
}
else if (!HasFarm() && HasBoat())
{
  Broadcast("You are OK!");
}
else if (!HasFarm() && !HasBoat())
{
  Broadcast("You are poor!");
}

……反而比這個簡潔版本更明確。

(HasFarm() && HasBoat()) ? Broadcast("You are wealthy!") : 
(HasFarm() || HasBoat()) ? Broadcast("You are OK!") : 
Broadcast("You are poor!");

雖然這是一個品味問題（有些人可能會覺得後者看上去更加一目瞭然），但是我在這裡要表述的觀點是，有時候解釋的最偉大方法並不是簡化。這個經驗也適用於日常生活，我花了大量時間來思考怎麼樣才能更好地傳達訊息以便於對方接收——有時更詳細的講解並非沒有價值，而是更明確傳達資訊的必須。

舉例來說，我想要更明確和更詳細地告訴我爸爸應該如何關閉iPad（“按住右側的按鈕一段時間……”）。或者，我看似多此一舉地鍵入了一些我已經提交到本地分支的內容給我的同事（“剛剛犯的錯誤已被修復”），然後當它涉及到部署更新到產品中時，我就能很明確地知道哪些具體的提交被合併和出現（“檢查4812-4822行，其中包括在6/15發行版本中的DoneDone問題，將在今晚的產品釋出中提出來。”）。

3.累計良性債務，並且要持續償還。

我在一個特別害怕欠債的家庭中長大。八十年代中期，我的父母傾其所有又東拼西湊，付了他們第一套房子75％的首付，然後在七年內付清了剩餘款項。用現金支付是常態。信用支付在他們看來幾乎是一種罪過。作為一個孩子，我的看法是，債務完全是壞的。我從不認為欠債是一種優勢。

直到我看到其他人是如何對待債務的——在我20出頭的時候——我終於知道了債務也可以是有益的。如果你能夠合理地承擔債務，那麼之後你也能獲得成功。如果藉助現在更好的上升空間可以加速你之後的成長，那麼債務可以成為一筆巨大的財富。

程式碼也是如此。有時它值得你現在承擔一點債務——錯過抽象或者有一些未優化的SQL程式碼——如果這樣做可以讓你更快地釋出內容給不斷增長的觀眾的話。關鍵是要了解你必須償還它，以及你可以在適當的時間段之後償還。

這就是債務在生活和程式設計中的竅門。償還債務需要持續進行。將一週10％的時間用於重構，相當於你是在按時支付編碼的信用卡賬單。如果你保持一種持續、可支撐的還債狀態，那麼累積債務實際上對你是有好處的。