「高效程式設計師七項特質」、「程式設計的八條可靠建議」、「九位偉大程式人的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件事」這類標題有多籠統,基本上就像個範本,只要將其他領域中的角色換回程式人,幾乎就能適用,對待這類標題時,就更能知道,哪些該一笑置之,哪些該認真對待了!

作者簡介


Advertisement

更多 iThome相關內容