語錄有兩種，有一種在於闡述智慧哲理，使人樂觀向上，積極進取；另一種則直搗人生無奈，看完會心一笑，撫慰心靈。方式不同，但都是能帶來正面能量的心靈雞湯。最近看到網友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/