程式師語錄 - 黑暗選集

語錄有兩種，有一種在於闡述智慧哲理，使人樂觀向上，積極進取；另一種則直搗人生無奈，看完會心一笑，撫慰心靈。方式不同，但都是能帶來正面能量的心靈雞湯。最近看到網友but翻譯自日本程式鄉民的開發感想彙整，顯然是後者，讓搞程式專案快20年的我，讀來心有戚戚焉，忍不住頭點如搗蒜。

摘要整理一些特別有fu的(部分有額外融入自已的觀點及體驗，作了改寫)，預備於未來身處專案煉獄或遭程式花惹發纏身時咀嚼回味，追求心靈平靜，有消彌輕生念頭之效... (與讀金剛經有相同功效來著 XD)

• 每天有24小時。所謂的「今天之內」是指明天早上9點之前。
• 程式不會照你所想的方式跑，只會照你所寫的方式跑。
• 多想10秒鐘，你可以不用說「嗯，這個做得到」。
• 需求規格在程式寫完後才會敲定；基本規格要客戶看到成品後才會決定；詳細規格要使用者用過後才會確定。
• 軟體設計的奧義: 讓軟體設計單純到很明顯不會出錯，不然就是複雜到有錯也看不出來。
• 先說「沒辦法」的人贏，有意見的話你自己寫。
• 要殺一個程式設計師不需要刀，改三次規格就好囉!
• 詳細設計要寫在程式碼註解裡，註解常是唯一救贖，記得要讓自己看得懂。
• 程式異常該稱為「Bug」還是「規格限制」是看Deadline還有多久決定。
• 地獄期在一段時間後，充滿殺氣的怒吼會變多；
  再持續一段時間，說話變少牢騷會變多，開始壟罩在凝重氣氛裡。
  再持續下去反而會海闊天空，四周洋溢充滿活力的聲音。
  這種狀態稱為「Programmer’s High」，也是開始有人倒下的時候。
  (註: 馬拉松有所謂Runner's High，指跑者到後期反而精神舒暢的迴光返照期)
• 老手用來提振精神的魔法格言：「比起以前來說這算不了什麼…」
  新人用來提起幹勁的魔法格言：「把這件工作做完的話…」(他們還不知道工作是沒有終點的。)
• 能夠迅速想到解法的程式設計師太多了，他們用一分鐘想到方法，用一天去寫程式；而不是花一小時想解法，再用一小時去寫程式。
• 改掉舊的Bug總是會導致新的Bug -- 這是所謂的「Bug不滅定律」。
• 無論規格多晚確定，結案期限永遠不會變 -- 這是所謂的「期限守恆定理」。
• 不懂電腦的操作者是找出Bug的天才，很遺憾，同一個Bug他們通常沒法表演第二次。
• 規格與規格書是兩碼事。
• 將沒發現任何Bug的系統送上線 -- 恐怖啊! 恐怖到了極點~
• 當某人寫的程式碼出現Bug，當事人通常不在（墨菲定理？）
• 系統交付日是為了延後而存在的。
• 當你有「啊，加上這功能吧」的念頭時，還是不要想太多，早點去睡結果會比較好。
• 熟悉程式語言不表示就會寫軟體；徹底熟悉程式語言後，軟體會寫得更慢~
• 發現問題如何解決不是最重要的，發現哪裡是問題比較重要。
• 還沒付錢的，不是客戶；已經付清的，也不是客戶。
• 認真聽足客戶抱怨兩小時，問題就算解決一半，有時連程式都不用改就可結案。
• 接受「口頭規格」，就像開一張空白支票給別人一樣。
• 要證明 Bug 不是自己的責任，往往比修好它更花時間。
• Bug是很害羞的，跟你獨處時明明很大方，有別人來看時就躲起來了。
• 程式的養分來自程式設計師的鮮血。
• 當程式碼的規模超過臨界點，就會脫離程式設計師的手擁有自己的意志。
• SA總是很扯地跟程式師說: "怎麼會沒辦法?"；
  業務總是沒辦法跟客戶說: "這個很扯"
• 機器感受到龐大的時程壓力，所以它也崩潰了 orz
• 沒被發現的 Bug，就不算Bug！

原始出處:
http://but.tw/2008/10/programmers_rule/
http://but.tw/2011/10/programming-rule-next/