程式設計師語錄手冊

Web開發者發表於2012-07-13

 程式設計師語錄手冊

  1. 程式不會照自己所想的跑。只會照所寫的跑。
  2. 我對軟體設計的方式匯出的結論,有兩種方式。一是把軟體設計得單純到很明顯不會有缺陷,不然就是把軟體設計得複雜到沒有辦法看到明顯的缺陷。
  3. 有意見的話你寫。
  4. 要殺一個程式設計師不需要刀,改三次需求就好無論需求多晚才能確定,完工期限永遠不會變。這是所謂的「期限守恆定理」。
  5. 客戶總是覺得水跟追加需求是不用錢的。
  6. 一個人掛了大家都掛了。
  7. bug過了一晚可能就變成需求了。
  8. 顧客想受PM喜歡,要自己瞭解到系統開發需要時間與金錢,早點確定需求。PM想受顧客喜歡,則要讓程式設計師討厭自己。
  9. 很多PM跟程式設計師都暗自想著有錢有時間的話什麼系統都想自己動手做,這樣有成就感不過都沒這種機會。
  10. 質量的劣化程度依需求改變的次數與規模而定。
  11. 業務是認為空想能夠實現的夢想家。PM則是深信任何障礙都能突破的冒險家。程式設計師則是被夢想家和冒險家拋到漆黑海里的漂流者。
  12. 有才能的程式設計師第一次看到設計細節時,要先理解程式的目的。接下來要設法讓PM瞭解到用指定的方法、時間並無法完成這個工作。
  13. 程式是運氣與直覺堆砌而成的奇蹟。若不具備這兩者,不可能以這樣的工時實現這樣的需求。修改需求是對奇蹟的褻瀆行為。而追加修改則是相信奇蹟還會重現的愚蠢行動。
  14. PM需要持久力,程式設計師需要爆發力。
  15. 每天準時下班,工作會變多。
  16. 完美的程式需要完美的時間與金錢。
  17. 詳細設計要在程式程式碼的批註裡做完。批註是程式設計師唯一的自衛手段,至少要讓自己看懂。
  18. 還有時間看程式程式碼的話就執行他。CPU跑得比腦細胞快。至少這時候可以休息。
  19. 程式的異常該稱為「bug」還是「技術或需求上的限制」是看期限還剩多久決定的。
  20. 禱告上線沒有問題,然後跑吧。
  21. 程式不是用腦記的,要用身體記住。
  22. 當誰寫的程式程式碼跑出嚴重bug時,那個人通常都不在了(xxx定理?)
  23. 需求書就像航海圖,客戶則是水流。水流陰晴不定,航海圖就變垃圾。
  24. 程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
  25. 多想個10秒鐘,你可以不說「嗯,這個做得到」。
  26. 人是無法從別人失敗記取教訓的動物。砍成本、改需求、加需求、趕上線,從來沒有人從眾多失敗中記取教訓。
  27. 老手用來提振精神的魔法格言:「比起以前來說算是輕鬆…」。新人用來提起幹勁的魔法格言:「把這件工作做完的話…」他們還不知道工作是沒有終點的。
  28. 程式、PM、經理不是職務。是逃不掉的連環責任。
  29. 能夠迅速想到解法的程式設計師太多了。
  30. 他們能用一分鐘想到方法,用一天去寫程式。
  31. 上線後的除錯才叫做bug。
  32. 追加需求確定後交貨期限就無法確定,交貨期限確定後追加需求就無法確定。這稱為「追加需求與交貨期限的測不準原理」。
  33. 除三個錯就會冒出一個新錯。這稱為bug的無窮迴圈。
  34. 不祥的預感總會實現。不過程式設計師不應該去煩惱不祥的預感,那是PM的工作。
  35. 不懂計算機的操作者是發現bug的天才。而且他們通常無法重現那個bug。
  36. 每次開會就更改需求的客戶,他的操作手冊要等到程式上線後才能寫出來。
  37. 程式設計師所不滿的需求也一定會讓客戶不滿。(這是說程式設計師覺得難寫的地方常常是PM溝通有落差)
  38. 正因為健康,程式設計師才能做不健康的事。
  39. 那是你說的需求,真的。
  40. 壞了也是因為需求。
  41. 「程式程式碼的可信度,不會比寫的人還可信。」
  42. 唯一不產生bug的方法,就是不寫程式。第二好的方法,就是在期限跟人員確定之後的每次改需求,都重新檢視過整個專案。(但通常大家都忘了)
  43. 共同責任是程式設計師的責任。
  44. 如果可以改行的話,想找個準時下班不叫「逃跑」的工作。
  45. 對職業程式設計師來說,漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的批註,也就是新手程式設計師也能馬上動手改的程式。而要寫這樣的程式,需要單純、簡單、美麗的需求。但可惜客人總是喜歡搞很複雜。
  46. PM對程式設計師說的「常識」每三小時變一次。
  47. 小學生時第一次看到計算機,初中時第一次學會怎麼用,高中與大學學會程式語言,出社會後才發現自己早就走錯路
  48. 「不要讓老闆當業務需求比較好」
  49. 說來說去,要去研究根本不知道為什麼會執行的東西為什麼不會執行了,找愛迪生來也沒搞頭。
  50. 就算程式裡沒bug,編譯器會有bug。就算編譯器沒bug,OS會有bug。就算一切都沒bug,客戶會決定什麼是bug。
  51. 需求與需求書是不同的東西,通常都是。
  52. 比期限更重要的是靈感與睡眠。
  53. 比知識與經驗重要的是手冊與時間。
  54. 過了三天看上去就是別人寫的程式程式碼。
  55. 無論怎麼檢查,不管怎麼確認,上線前一晚就是睡不著。
  56. 沒有什麼事情比讓一開始就找不到任何bug的程式直接上線還要可怕的了。

相關文章