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

http://www.quora.com/What-distinguishes-a-good-software-engineer-from-a-great-one?__snids__=16428567

http://www.inside.com.tw/2011/04/27/developer-quotes

我將我覺得重要的摘錄如下

"Design is finding the problem, not the solution" -- Leslie Chicoine

設計是找問題，而不是找解答。

而實際上我理解後，我認為設計應該還是尋找問題及適合特定對象的答案。例如說，如果你想要設計一台車，你絕對不會空想一台車，而是你確定這台車是要給誰開的，才會為了那類的人去設計那台車。

"Legacy Code is Code Without Tests" -- Michael Feathers

沒有測試過的程式碼就不能夠使用。

這是千真萬確的，不管是個怎樣強的編程機器，一定會有盲點。不管寫得再完整再漂亮，其實很多都是因為寫程式的人會習慣性地告訴自己，寫這樣多程式已經足夠，其實本來就沒有所謂絕對完美的架構或程式碼。而我自始至終都認為自己剛寫出來的東西「根本就不能信任」，一定要站在使用者的角度，撰寫功能性的測試。測試過了，才能夠「信任」。沒有經過測試到的功能，就要視為不可以使用的功能。

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" --Martin Fowler

任何人都可以寫出電腦懂的語言，好的程式設計師寫的是人可以看得懂的語言。

其實這是一個非常困難的目標。多年以來，我發現所謂的開發者，是必須經過有一段期間，用自己才能夠理解的邏輯，去把東西做出來。甚至這樣的邏輯，在很多人的心中早就是一種本能，而那樣的本能是無法描述出來的。所以，要寫出自己看得懂的程式很簡單，但要他人看得懂就很非常困難。更何況會去看你的程式的人，有些時候只是單純為了要糾正你的程式而已。

所以我認為這句話，應該是要讓自己朝向一個目標：不要只是把程式寫完，要留一些資料來解釋自己的程式究竟在做什麼。這樣子程式就不再只是一個單純的程式，而是可以讓看的人去瞭解一些「想法」，而這些人他們應該也只是想透過程是來去瞭解想法，而並非對你怎樣做出來的真的有興趣。

還是老話一句，在這個時代，光會寫程式，是無法將自己的想法表達出來的。

"Simplicity does not precede complexity, but follows it" -- Alan Perlis

簡化不可能發生在複雜化之前，一定是之後。

這句話也是驗證很多事情啊。在工作的期間，有注意到幾個狀況：

在設計系統的時候，一定會經過一個階段就是討論「使用者需要什麼？我們究竟該做什麼？」而討論了很多，每個人都有自己的想法，就往往無法收斂。一旦沒有人引導整個討論，就會讓整件事情越來越糟糕。而一旦討論稍微收斂，又有些人會本能地將事情複雜化，而無法理解需求發散了之後需要的是收斂，才能真正進入時程規劃，系統設計及開發的階段。

另一個是很多「聰明」的開發者，會在討論時簡化自己該做的事情，想要藉此來減輕自己的工作量。但實際上，真正在系統實做之後，往往會因為過度的簡化，造成幾個現象：1. 自己設計的東西缺乏彈性，因此對於新的需求往往會很焦躁 2. 會想要反過來去推翻使用者的需求

因此，讓不同特性的人，在同一個討論會議，重複進行思考發散及收斂的動作。這樣的訓練是非常的重要。一旦習慣這樣的週期，如同scrum那樣的模式才能夠真正形成。

"Real developers ship" -- Jeff Attwood

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

是的，也因此可以發現很多開發者是不太習慣交出產品，也並不清楚自己的程式到底能不能千錘百鍊。總之還是一句話：「測試」。此外，能夠瞭解使用者需求的，才有可能交出產品。開發者不應該要活在自己「最佳化程式」那樣的夢境裡，反而應該找些時間跳出來聽聽用過你的程式的人的聲音。

"There is no silver bullet" -- Frederick Brooks

沒有什麼是萬靈丹。

最近和一些熟悉硬體開發的人相處，也才知道他們口中的軟體，並不是像我們常聽到的應用軟體。以硬帶軟，始終是會將軟體視作是一種「生產」。他們相信，軟體開發是可以最佳化的，軟體是應該要有生產力的，並不需要太多的創意，也不該因為需要創意而給予時間養分。我當然也認同，軟體應該要有生產力，但終究不可能像是做硬體那樣，一旦規格確立，前因後果研究清楚了，就開始大量生產。會進入那種模式的，我想還是像韌體，或是系統軟體。這些軟體比較有可能在規格確立清楚後，就開始投入人力「寫」。

也因此，寫應用軟體會比較重視創意，以及與使用者互動來磨練，應用軟體絕對是需要這種養分，也絕對需要時間。並不可能使用單一種管理，生產方式或作法就能夠讓全部的人都寫出有價值的東西。會去對任何人強調說自己的公司是使用這樣的管理方式，那無非就是策略而已，並不應該是一間開發應用軟體的公司所為。

"For the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something...almost everything - all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose." -- Steve Jobs

過去33年來，我每天早上看著鏡子問我自己：「如果今天就是生命的最後一天，我會去做今天應該要做的事嗎？」。儘管每次最後答案還是「不會」，我都知道我需要改變...改變所有的事情：不要擔著外在的期望，不要驕傲，不要害怕丟臉或失敗。因為這些事在死神面前都不再存在，而只會留下真正重要的事。提醒自己馬上就要死了，就是可以避免讓自己落入患得患失陷阱的最好方法。

"What distinguishes a good software engineer from a great one? Able to balance pragmatism and perfectionism, Not averse to debugging and bugfixing and Healthy skepticism " -- Russel Simmons

如何區別好的與偉大的軟體工程師？ 能夠平衡實用主義與完美主義，對於解bug永不厭惡，以及有建設性的懷疑。