程式人到底要知道幾件事？

「高效程式設計師七項特質」、「程式設計的八條可靠建議」、「九位偉大程式人的Q&A」、「明星程式設計師必備的十項特質」、「20條程式設計名句」、「59條搞笑而真實的程式設計語錄」……這類標題中，具有數字的文章，你看過幾個呢？

甚至，O'Reilly乾脆出了《程式設計人應該知道的97件事》這本書，然而，程式人該知道的事到底還有幾件？

標題數字僅供參考

在長期觀察下，這類具標題中有數字的文章一旦出現，往往會獲得極大的共嗚與轉載，在其他領域中，大概只有「傑出父母對孩子只做三件事」、「父母別做的七件事」、「25個成功父母的原則」這類親職教育文章能與此現象相比了。就如同希望小孩成長過程，是一路往對的方向，程式人也希望程式設計下的產品，是一路往對的路線成形，因而努力塑造自己成為一個完美的程式人，希望對待產品能如同對待小孩那般地完美。

可惜的是，程式設計有太多需要知道的事，也有太多不同的情境需要面對，在具備基本的程式設計能力之後，老實說，幾乎所有程式人都是在一邊從事程式設計，一邊學習怎麼做程式設計，要學的東西，多的不得了，自己犯下或看到他人犯下的錯，也多的不得了，因此看到數字時就會有種莫名的興奮與認同，某些程度上，自己能符合文章中越多條原則，就會有種越往成功路上邁進的感覺，形成一種自我催眠。

說老實話，程式設計上對的事與不對的事，即便只是原則，真的是能一、三、五、七、九，就能條列完全嗎？如果來在Hackpad上開個〈問題專案共筆：不要再對程式這樣做！〉，我想上頭能列出的點，會多到程式人連看都看不完。其實，當這些程式設計語錄或程式人應該知道的事，在條列數字上不斷遞增展開之時，真正傳達出來的概念，跟食品包裝打上：「圖片僅供參考，產品以實物為準」沒兩樣，也就是標題數字僅供參考，就算做到（或沒做）這n件事，既不保證能成為偉大程式設計師，也不保證產品開發過程能夠一帆風順，擁有幸福快樂的結局。

原來有這些想法與作法

如果從標題敘述上可清楚看出這篇文章，只是籠統列出優秀程式設計師或成功專案的共同特質，通常我會略過不看。

某些程度上，這類文章多半是基於生存者偏差（Survivorship bias）觀點下，所整理出來的內容，只挑優秀或成功案例來抓出共同點，忽略了各案例實際情境，以及同樣情況下更多失敗者的下場。

通常這類文章多半在塑造一種高手神話，吸引那些想要尋求捷徑，立即成為高手而享受光環的程式人，文章背後往往有其他目的，也許是型塑個人、網站或報刊的專業與成功形象。這類文章對程式人不會有任何幫助，甚至是種妨礙，如同Ryan Brush在〈The Guru Myth〉中說到的：「軟體業中最大的障礙之一，是有些聰明人有目的地宣揚高手神話。」

如果是節錄某些大師名句而整理出來的文章，也得小心，因為有些作者通常會在節錄的句子之後，穿鑿附會上自己的觀點，忽略了當大師講述時的前後情境。因此，如果標題上可以看得出提供了語錄，我會進一步看看內容，並試著找出感興趣的語句之原出處，詳細閱讀其前後文，我在寫作時也儘量保留此習慣，對於我引用到的名言佳句，儘可能地提供出處來源，以便讀者進一步親自閱讀，實際瞭解原作者的想法。

若是記錄優秀程式設計人Q&A的文章，只要訪談內容沒有被特意避重就輕的話，就可以看看，通常這類文章較能呈現被訪者的想法與觀點，因此，《Coders at work》這類列出15位軟體大師核心思維、《松本行弘的程式設計世界》條列了14種思考術，或者是《程式設計人應該知道的97件事》的這類書籍，都值得一看，因為它們都比較能呈現出各個程式人，醞釀出各自觀點的各自環境，而不只是最終的寥寥幾點原則。

說穿了，程式人要知道並不只是幾件事而已，閱讀這類文章的樂趣在於，總能驚喜地發現到，竟然有人會有這種想法，原來有人會有這種做法，基於對這些想法、做法等的認同與不認同，來逐漸修正、完備自己心中真正的原則與作法。可以仔細想想，你並不是一開始就依照著原則而做事的，而是多年來不斷學習、體驗與反覆精煉諸多觀點之後，才會有了現在持有的原則！

學會適時地修正方向

程式設計到現在確實累積了不少經驗，這些經驗多半來自於過去曾犯下的錯，能事先瞭解一些最佳實踐或設計原則，確實可以避免重複犯下一些錯誤，不過，程式設計上可能的錯誤太多了，如果寄望能在每個原則都套用之後，專案就能完美無缺，那就會是最大的錯誤。

在程式設計上，一開始就想做對的想法，已被證實行不通，專案本身會不斷地修正，隨著程式人對程式設計本身或專案領域的瞭解。而且，程式碼也會不斷地變化，身為一個負責的程式人，面對這類變化也有可能是自發進行重構，而非在客戶或老闆指派下才進行。

更何況，程式設計這領域，無論是語言、工具、典範等各方面，也都還在演進，現在是對的東西，以後可能會是錯的，像是曾經頌揚一時的單例（Singleton）模式，現在幾乎是成了反模式，隨著語言特性或工具本身特性的功能演進，過去某些最佳實踐，也有可能成為最差實踐，或許因為這類情況，在stackoverflow上〈What's your most controversial programming opinion?〉上，就曾列出一個條目：「動腦才是唯一永久適用的『最佳實踐』」。

某些情況下，這確實是跟親職教育有點像，也難怪程式設計與親職教育領域，都經常會有數字標題殺人法的文章出現，因為同樣都是沒有完全對或完全錯的東西。在親職教育上，雖然可以從前人過去曾犯下的錯中吸收經驗，然而隨著社會環境等型態之轉變，如果父母對著幾本育兒書或幾篇文章照本宣科地養育，無法針對不同小孩的差異性適時修正調整，對小孩的成長絕對是傷害，而不會是種助益，甚至引發一輩子的憾事。

如同親職教育在有些文章或書上的觀念上，根本就是相互對立的，端看父母是否從中獲益或受害，程式設計上也有這類現象。

舉例來說，Ruby on Rails創始人David Heinemeier Hansson在今年RailsConf大會中抨擊TDD，甚至之後還發了〈TDD is dead. Long live testing〉，想當然爾地，TDD受害者與TDD受益者（擁護者）兩邊就戰起來了。

還會想要多幾種思考角度？

面對這類「程式人要知道的n件事」標題，或許最重要的是承認自己「不會總是朝著正確的方向」，從不同角度看時，總是會發現與心中期待的方向有所偏差，看看那些標題下的內容，該做的並不是對自己有做到的原則點頭稱是，而是將自己未曾有過的思考方式，加入成為未來思考問題時的角度之一，在適當時候用來校正自己期待的方向，而不只是標題內容中想要的方向。

甚至必要時，可以跨出自己的領域，看看其他領域中該知道的幾件事，不該做的幾個禁忌等標題下的文章，這時就會發現，「程式人要知道的n件事」這類標題有多籠統，基本上就像個範本，只要將其他領域中的角色換回程式人，幾乎就能適用，對待這類標題時，就更能知道，哪些該一笑置之，哪些該認真對待了！