程式設計笑話2

出處:http://www.tgsc.com.tw/usb20/viewthread.php?tid=7501
上程式設計課…

老師：「你們說說看，微軟這家公司有什麼了不起的？有什麼是他們自己

創造的？DOS？買來的；Windows？還不是抄麥金塔的；IE？沒Nescape他
們哪做的出IE呀？你們說說說看，有什麼是他的？」
這時，台下傳來一個聲音：
「錢。」

出處http://but.tw/2008/10/programmers_rule/
程式設計師的格言
底下節錄些自己覺得有戚戚焉的 :)

• 1 每天有24小時。所謂的「今天之內」，是指到明天早上為止。
• 2 程式不會照自己所想的跑。只會照所寫的跑。
• 3 需求規格在程式寫完後才會敲定。
     基本規格要客戶看到成品後才會決定。
     詳細規格要使用者用過後才會確定。
• 7 先說「沒辦法」的人贏。
• 8 有意見的話你寫。
• 9 要殺一個程式設計師不需要刀，改三次規格就好。
• 11 開發沒有終點。只有釋出(release)。
• 12 無論規格多晚才能確定，結案期限永遠不會變。這是所謂的「期限守恆定理」。
• 13 客戶總是覺得水跟追加需求是不用錢的。
• 16 一個人掛了大家都掛了。
• 17 bug 過了一晚可能就變成規格了。
• 23 品質的劣化程度依規格改變的次數與規模而定。
• 24 業務是認為空想能夠實現的夢想家。
       SE則是深信任何障礙都能突破的冒險家。
       程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
• 25 有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
       接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
• 35 程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
• 46 規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
       程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
• 48 多想個10秒鐘，你可以不說「嗯，這個做得到」。
• 56 上線後的除錯才叫做bug :-)
• 57 追加需求確定後交貨期限就無法確定，
       交貨期限確定後追加需求就無法確定。
       這稱為「追加需求與交貨期限的測不準原理」。
• 58 除三個錯就會冒出一個錯。
       這稱為bug的無窮迴圈。
• 61 不懂電腦的操作者是發現bug的天才。而且無法重現。
• 62 每次開會就更改規格的客戶，他的操作手冊要等到操作寫好的程式後才能寫出來。
• 64 啊，那是微軟的規格。
• 69 那是你說的規格。
• 71 即使爛了，規格還是規格。
• 73 為什麼你不能兩三下解決掉他啦。
       因為之前兩三下搞定的東西也被你兩三下就否定了。
• 74 不會動的bug就只是普通的bug。（會動的bug則能視為規格）
  (譯註) 宮崎駿電影《紅豬》「不會飛的豬就只是普通的豬」。
• 75 今天好好清理bug，bug應該死光了吧。
       咦？Windows也死了唷。
• 87 能拿到錢的規格變更稱為「受理項目」，
       拿不到錢的規格變更則稱為「SE的規格確認失誤」。程式設計師是這麼看的。
• 93 「不要讓老闆當業務比較好」
• ex 1 就算程式裡沒bug，編譯器會有bug。
          就算編譯器沒bug，OS會有bug。
          就算一切都沒bug，客戶會決定什麼是bug。
• ex 6 過了三天就是別人寫的程式碼。
• ex 13 估價需要1%的經驗與99%的直覺。
• ex 14 沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。
• ex 16 當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）
• ex 18 最強藉口
            以前「那是硬體的極限」
            現在「那是Windows的規格」
• ex 19 「程式碼的可信度，不會比寫的人還可信。」