程式開發者可記的九大經典名句

評論
評論

剛逛到 Dan 的部落格, 我不認識他,從部落格內容看起來他應該是位優秀的 C#, .net 程式設計師。看到他的 新文 記錄了九個對他自己有重大影響名句佳言,大部分筆者自己都沒聽過,學到了並試著翻譯並加入自己的心得,分享如後:

 

設計是關於找問題,自身並不是解答。

Leslie Chicoine

正好最近用 ipad 2 在看 itune 上姚仁祿先生的 " 設計邊境" podcast,他也說設法從 現狀 想辦法靠近 期望 的能力等於「設計」。這跟 Leslie 說的有異曲同工之妙。

 

功能規格書根本不起作用。

37signals

這話很嚴重,但從 37signals 口中說出來就不意外。他們認為功能規格書是在資訊不充足下,就得做出關鍵性決定,這樣寫出來的文件可說只是在幻想,而更糟的是功能規格書還可能限制了改變,重新評估與版本演進的可能性。37signals 說," 不要寫功能規格書!"。

什麼是 Legacy Code? 就是一堆沒有留下測試的程式碼。

Michael Feathers

Michael 是敏捷開發與 XP 社群的活躍成員,對於各類軟體開發方法論都有深入的見解。對於需要維護公司舊系統的你,是否心有戚戚焉?但只要你寫的新程式沒有寫測試,你的程式碼交出去之後馬上也就會變成 legacy code。

 

任何傻瓜都能寫出電腦看的懂得程式碼。但只有好的程式設計師能寫出人看得懂的程式碼。

Martin Fowler

Martin 是位大師,專長在物件導向分析與設計, UML,敏捷開發方法論... 等。如果你熟悉 Dependency Injection ,而且發現這東西很難懂卻又偉大,你就知道 Martin 有多強了,因為那是他發明的詞。

 

Testing shows the presence,not the absence of bugs.

Edsger

得過 1972 Turing Award 的大師 Edsger W. Dijkstra 講了這句話,真是難翻譯,若有網友有好翻法,請留言告知。我去翻了這句話的 原文出處 ,在 1969 年的 NATO 軟體工程會議中,針對測試方法與技巧進行討論時,他說了這句經典,測試無法辦法顯示出臭蟲不存在,

 

簡化不先於複雜發生,而是在之後。

Alan Perlis

對於真正困難的問題類型,如果沒有知道複雜的全貌,是無從簡化起的。相反地,一開始就能簡化的問題,大概那個問題真的是簡單的不得了。

 

真正的開發者會交出產品。

Jeff Attwood

如果身為一個開發者,不以交出產品給市場為前提來工作,常常喊著需要更多的時間來開發,或因未知的技術問題裹足不前,猶豫不做行動等等,嚴格來看他不是個真正的開發者。面對各種的未知與挑戰的最好方法,就是交出產品,讓市場驗證。

 

沒有什麼是萬靈丹。

Frederick Brooks

人月神話 作者 Frederick 說相較於硬體開發,軟體開發不存在單一技術或管理技巧的發展能確定在十年內提昇軟體的生產力也好,穩定度也好,簡單易用也好,統統不行。軟體發展的萬靈丹並不存在。他也說,每兩年要提昇兩倍也是不可能的。

 

如果今天是我生命的最後一天,我會想要做我今天將做的事情嗎?

Steve Jobs

這是名言了。知道的人很多很多,因此只翻譯一小段。完整原文請到 這邊 去看。

 

你還有什麼樣的名句,大家交流交流吧。

Inside 寫稿的每一天,筆者可覺得都是自己想做的事情喔~

明天上班您要做的事情,也是你生命最後一天會想做的事情嗎? 如果不是,想想 Jobs 怎麼做的吧,共勉之!

 

相關文章

掌握 5 個基本概念,讓你寫出好 Code

我相信能建立一種心態架構,是能超越任何語言和函式庫,讓人一開始就能產生好的程式碼。這裡提出 5 點概念,記住這些原則,寫出好的程式碼將非難事。

別用瞎扯倡導對的事!104 實驗影片如何誤導人資專業?

廣告很明顯是在「陰」那七個主管,讓他們成為有眼無珠的笑柄。許多網友也留言嘲笑他們「狗眼看人低」之類的言論。說真的,他們真的有做錯什麼嗎?在職場選才的制度發展有一定的成熟度與專業度,根據一個人的過往學經歷去推測他「近期的可能性」何錯之有?

Google 傳今年再推新通訊軟體,將於 5 月中旬揭曉

Google 似乎計畫再推出新款通訊軟體,將可讓使用者共同在線上編輯照片,並且藉由各種方式快速分享。

評論