從個人習慣到真正的好方法

每個人做事情都有些個人習慣，有些習慣特彆強烈的，可能其程度就會上升到「癖」這個詞。明朝散文家張岱在其文《陶庵夢憶》中留有名句：「人無癖不可與交，以其無深情也。」。這裡的「癖」就是一個強烈的個人喜好與習慣。

作為程序員，過去這麼些年乾的最多的事情自然就是寫程序，所以也就形成了一些個人習慣或者說癖好。自己的習慣或癖好對別人本該是無所謂的，但有時不注意主動去把這種習慣或癖好強加於人就不太好了。

1

好些年前了，畢業幾年後我也成了需要帶新畢業學生的「老」程序員了。帶學生的主要事情自然也就是一起做項目，指導下他們上手開始寫真正的項目代碼，而不是實驗性質的課程作業。

工作頭幾年是我寫程序最多的幾年，基本也就寫出了一些個人的習慣和喜好。比如，工程的目錄結構，類的命名模式，介面的參數定義，甚至注釋和簽名的方式，都是我特別在意的東西。當看到新同學們各自按自己的想像寫的隨心所欲，就感到非常的焦心。那時候像 Java Maven 這種約定優於配置的工具還沒有流行起來，大家都按自己的喜好使用 Ant（一種 Java 構建工具）來定義工程項目結構，所以千差萬別。

因而，我就忍不住去把新同學們的工程按我自己的定義喜好進行修改，以一種權威的說辭來強調自己的偏好：「我們要統一下，免得像以前舊項目一樣差異太大，換個項目熟悉起來都要好半天，也不利於相互之間的代碼交流。」。

如今回想起來，當時這種「約定優於配置」的個人習慣在行業里還沒有成為共識，而我僅僅是出於自己對代碼的「潔癖」或者說強迫症，而產生了這種強加於人的衝動行為。一些年後，Maven 崛起逐步取代了 Ant，這種約定優於配置的思維就變成了 Java 程序員的普遍共識，而我也可以確認這個習慣確實是一個好方法了。

編程中如今總結出來的一些好方法，可能最早確實源自一些人的個人習慣，直到它們被大眾所認同並形成了普遍共識。即使這些習慣最後也許真得變成了大家認同的好方法，我們也不該去以個人的方式強加於人，何況當時你還未必能確認這樣的習慣真得會是一個好方法？

2

如今，很多形成共識的代碼規範，基本就是從早期少數人的習慣中加以提煉總結出來的，形成了大家共同認可的好方法，並在組織層面去形成了規範。形成了規範的東西，就不再是從個人習慣的角度去強加於人了。

寫代碼的一些方法能形成規範，但還有一些編程的好方法可能比較難用規範描述，這些就慢慢形成了所謂的「編程的智慧」。在程序員之間口口相傳，如今的「口口」可能更廣義一些，也包括了互聯網上的文字交流和傳播。

一些編程智慧類的好方法，不太好形成具體的規範描述，我隨便想了下，舉點例子：

設計模式

遵守設計模式總是能讓你少踩坑的，但如何靈活的採用合適的模式又是一種智慧了。

術語約定

約定了術語，總是能讓口頭的概念和落在代碼上的東西保持一致，溝通歧義減少，從而更高效。

單元測試

這比任何的代碼評審都來得可靠，哪裡該寫哪裡可以不用寫，這又是智慧了。但不要為了追求覆蓋率去寫，覆蓋率的技術統計方法其實是很唬人的，有些覆蓋率很高項目，該有的 bug 還是有的。

隨時重構

技術債務，每個月付點利息，比好幾年後連本帶息去還要感覺輕鬆得多。這條的特殊點在於，我想這是大部分程序員都認可的好方法，但卻不是大部分人的習慣。現實中欠了債，最多親人能幫你還，但技術上的債，實在自己還不起，總是可以推脫給下個倒霉的傢伙的。

3

編程中除了好方法，還有些確實是個人習慣的東西，如果我們不去留心區分，很容易模糊了兩者的界限。

舉個例子，我曾經一直有個編程習慣是這樣的。假如有一個介面方法叫 lookup()，在實現這個方法內部的邏輯要根據好幾種條件來查找，按不同的參數條件來實現不同的內部邏輯分支，但最後執行時又會走同樣的一段邏輯去存儲里查找。描述起來比較繞，用個簡圖來說明如下：

如上，lookupBy... 表達了不同參數邏輯的差異化處理，最後的 lookup0 一段共享的查找執行代碼。 lookup 是一個公開的介面方法，而後面再加個 0 基本就是我的個人的習慣了，表達了內部私有的一種技術性實現，它一定是私有的，不對外暴露的。

4

如上，這樣的個人習慣是讓我對所有類似需要的介面實現模式保持一致。但這確實只是個人的習慣偏好，我沒法也不會要求別人也用類似的方式，別人也可能有自己的習慣偏好，談不上誰比誰更好。

大家都認同並形成共識的習慣一定是好方法嗎？很有可能，能驅動大眾行動的方法很大可能是好方法。但反過來，大家都不做的一定是不好的方法嗎？這個就很難說了，比如程序員都不愛寫文檔，也沒有這個習慣。另外，一些流行的概念是好方法嗎？比如，結對編程。

結對編程，是一種流行的概念。結對編程的行為要求：兩位程序員坐在同一工作台前開發軟體。它的優勢作用：與兩位程序員各自獨立工作相比，結對編程能編寫出質量更高的代碼。它的理論基礎是：兩個程序員具有相同的缺點和盲點的可能性很小，所以當我們採用結對編程的時候會獲得一個強大的解決方案。

但有些人是很不喜歡結對編程的，比如我。真坐在一起編程，我感覺自己的效率會下降一半以上，因為難免分心而無法進入完美的心流狀態。除此以外，有些人還喜歡在看你代碼討論時，用手戳屏幕指指點點，這也是我很難接受的點。當然，聽說更嚴重的除了代碼潔癖，還有生活潔癖，根本接受不了任何其他人和自己共用一個鍵盤的。

也許稍微鬆散點，沒有那麼物理上的嚴格結對。而是確保每一個程序員寫得每一行代碼，如果都能有一個配對的程序員去進行檢視，這個過程完全是非同步或遠程的，效果應該也是可以保障的。這幾乎就是開源項目的運作模式。

開源協作模式是一種大眾行動證明的好方法，而結對編程也許只是一個流行的概念。

...

在我們從程序新人成長起來的過程中，要學會區分，哪些確實是值得學習與推廣的好方法，哪些僅僅是自己的個人習慣。特別是在我們開始成為技術主管後，曾經犯過的錯就是希望別人按照自己無關緊要的特有習慣來做事。

古語有云：己所不欲，勿施於人。而己之所欲，是自己的特有習慣，也就請勿施於人了。若確實覺得是個好方法，盡量建議於人，而非強加於人，即使你手上掌握有強加的權力。

學習Java的同學注意了！！！

學習過程中遇到什麼問題或者想獲取學習資源的話，歡迎加入Java學習交流群495273252，我們一起學Java！

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