圍棋定式，是指在特定的情況下，黑白雙方的最優解。限於篇幅，介紹定式的書，通常只描述了標準答案，或者最多加上幾種變化，但在現實中，可能有幾百種變化。我就不喜歡背定式。我喜歡偏偏不按定式走，看看對手會怎麼應，接下來局勢會如何變化，對我如何不利，然後解決這些問題。當我把這些問題都解決完，我也就逼近了標準的定式，但同時我掌握了幾乎所有的變化，這樣在實戰中，對手不按定式的變化來應招，我也知道怎麼下。

在程式設計領域，也有很多定式，我們稱之為模式。同樣的，我認為只把書上的設計模式背下來，不能算掌握了這種模式。

我喜歡寫樸實無華的程式碼，不喜歡用“黑科技”式的模式。舉個例子，摩托羅拉有一位令我尊敬的高手寫了一個工廠類，根據不同的輸入引數，建立不同的物件。他使用了c#的反射標籤，宣告類時在上面打上標籤，構造時根據輸入引數迴圈所有的類，發現標籤跟輸入引數一致，就構造這個物件。這樣程式碼很簡潔，沒有冗長的if else或switch case。但對第一次看這個程式碼的人，會造成閱讀困難，我相信即使是對反射技術很熟悉的人，也要花更多的時間才能明白這程式碼的意圖。更別提這種反射用法應該不是很常用（可能是我孤陋寡聞）。更重要的是，實際應用場景裡，需求可能只有三四個case（我記得是用於區分產品線型別）。即使寫成if else也不會太長。程式碼換成我來寫，我就會先用簡單的if else實現這個邏輯，如果隨著產品的維護if else變得很長，比如有幾十個，再考慮重構，採用技術簡化，比如上面的反射。在工作中，我遇到不少照搬定式，過度設計的情況。有的是因為對模式理解不深，有的則是為了炫耀技術。由於可能涉及公司業務就不細說了。《設計的原則，模式與實踐》這本書中，作者提出了第一顆子彈原則，一開始不必把系統設計得過於複雜，當你中了一顆子彈，再做相應的修改調整。這是我從小性格養成的習慣。這導致我考試成績一直不怎麼樣。每當學到一個公式，我都會想研究它是怎麼推導的，它所代表的實際意義是什麼。但在實際工作中，我發現我的表現在周圍人的排名遠遠好於學校裡的情況。