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


Comments

# by Litfal

沒擲出的異常就不算異常! 太好了我要用try...catch把整個Main包起來 報告學長,沒有異常!

# by MIS2000 Lab.

趕緊筆記起來,以免忘記.....讚喔!

Post a comment