/ Chat

程式設計師的格言

全文轉載自:
http://buttaiwan.wordpress.com/2008/10/12/programmers_rule/

程式設計師的格言(盜作不少)譯自:
http://www2.biglobe.ne.jp/~oni_page/other/etc/pr03.html

版本 2 2008/10/12 更新

http://mixi.jp/view_community.pl?id=1772737

譯註

SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式,主要工作是跟客戶確認規格。

程式設計師多半自己不面對客戶。

跟 PM 又不一樣。(有什麼比較貼切的職稱翻譯嗎?)

  1. 每天有 24 小時。
    所謂的「今天之內」,是指到明天早上為止。
  • 程式不會照自己所想的跑。只會照所寫的跑。

  • 需求規格在程式寫完後才會敲定。

    基本規格要客戶看到成品後才會決定。

    詳細規格要使用者用過後才會確定。

  • 我對軟體設計的方式導出的結論,有兩種方式。

    一是把軟體設計得單純到很明顯不會有缺陷,

    不然就是把軟體設計得複雜到沒有明顯的缺陷。

    -- C.A.R.Hoare

  • 程式碼不要在開發現場寫! 去客戶那寫!

    除錯不要在期限前做! 上線後再做!

  • 畫面藍了。

  • 先說「沒辦法」的人贏。

  • 有意見的話你寫

  • 要殺一個程式設計師不需要刀,改三次規格就好

  • 首先要先懷疑別人,被懷疑的人或許會把問題解決掉。

    (註:通常會「先懷疑自己」)

  • 開發沒有終點。只有釋出(release)。

  • 無論規格多晚才能確定,結案期限永遠不會變。

    這是所謂的「期限守恆定理」。

  • 客戶總是覺得水跟追加需求是不用錢的。

  • 付錢愈計較的客人愈囉唆。

  • 在排定開發行程時,總是視而不見一些連小學生都會的算數。

    業務部門總是一堆不知道 1+1=2 的人。

  • 一個人掛了大家都掛了。

  • bug 過了一晚可能就變成規格了。

  • 好的規格找一個天才不如找三個凡人。

    爛的規格找一百個凡人不如找一個天才。

  • 客製軟體中 30% 的價格用在確認規格上。

    30% 用在修改規格上。
    30% 用在找 bug。
    結果初期規格反映在價格上占的比例只有 10%。

  • 對客戶來說 SE 是部下,程式設計師是家畜。

    對 SE 來說客人是錢,對程式設計師來說顧客是看不見的病毒。
    除了弄完程式以外,沒有其他驅除的辦法。

  • 顧客想受 SE 喜歡,要自己了解到系統開發需要時間與金錢,早點確定規格。

    SE 想受顧客喜歡,則要讓程式設計師討厭自己。

  • 很多 SE 跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做,

    不過都沒這種機會。

  • 品質的劣化程度依規格改變的次數與規模而定。

  • 業務是認為空想能夠實現的夢想家。

    SE 則是深信任何障礙都能突破的冒險家。
    程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。

  • 有才能的程式設計師第一次看到設計細節時,要先理解程式的目的。

    接下來要設法讓 SE 了解到以指定的方法、工時並無法完成這個工作。

  • 程式是運氣與直覺堆砌而成的奇蹟。

    若不具備這兩者,不可能以這樣的工時實現這樣的規格。

    修改規格是對奇蹟吐槽的褻瀆行為。

    而追加修改則是相信奇蹟還會重現的無謀行動。

  • 程式設計師聽了「把自己當作顧客去著想!」而開始思考。

    啊,像夢一樣。

  • 對於因為興趣而寫程式的人來說,所謂的技術是程式語言能力。

    對於因為工作而寫程式的人來說,所謂的技術是邏輯思考能力與人際溝通能力。

    程式語言可以看著手冊溝通,客戶不行。

  • 程式系統在交貨之前會不斷縮小。

    先用元件定義取悅老闆。

    再拿經費概算要部長妥協現實的方案。

    在運用會議中,課長會嘗識減少自己責任範圍。

    在細節會議中,負責人會把範圍縮到自己記得的部分。

  • SE 需要持久力,程式設計師需要爆發力。

  • 準時離開公司,工作會變多。

  • 完美的程式需要完美的時間與金錢。

    聽說揮霍著美國的國家預算的NASA,也覺得時間跟錢不夠。

  • 詳細設計要在程式碼的註解裡做完。

    註解是唯一的自衛手段,至少要讓自己看懂。

  • 還有時間看程式碼的話就執行他。

    CPU跑得比腦細胞快。至少這時候可以休息。

  • 程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。

  • 所謂便服日,好像社會上把他叫做假日

    (註) 日本有些公司會有所謂便服日(不用穿西裝的日子),通常是星期五,但…

  • 地獄持續一段時間後,充滿殺氣的怒吼會變多。

    再持續一段時間,說話會變少但牢騷會變多,壟罩在凝重的氣氛裡。

    再持續下去,反而會海闊天空,四周洋溢充滿活力的聲音。

    這種狀態稱為「Programmer’s High」,也是倒下來的人開始出現的時候。

  • 遠處的火災一定燒到這裡。

  • 禱告,然後跑吧。

  • 程式不是用腦記的,要用身體記住。

  • 明天能放假的話死了也罷。

  • 外面有下雨耶,昨天開始下的嗎?

  • 若不能心靜不移,身體會掛。

    若不讓自己殘忍,自己會被殺。

  • 客戶會說謊,業務會作夢, SE 會做白日夢。

    程式設計師則惦惦。(愈來愈自言自語)

  • (日文文字遊戲)

    SE 總是不負責的說「別逞強」,
    業務總是無理取鬧不准說「沒辦法」。

  • 規格書就像航海圖,客戶則是洋流。洋流陰晴不定,航海圖就變垃圾。

    程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。

  • 再嘮嘮叨叨下去也是要付錢的。

  • 多想個10秒鐘,你可以不說「嗯,這個做得到」。

  • 人是無法從別人失敗記取教訓的動物。

    砍成本、改規格、加需求、趕上線,從來沒有人從眾多失敗中記取教訓。

  • 老手用來提振精神的魔法格言:

    「不過比起以前來說算是…」

    新人用來提起幹勁的魔法格言:

    「把這件工作做完的話…」他們還不知道工作是沒有終點的。

  • 所謂交案期限,是指開發現場從公司換到客戶那裡的日子。

  • 程式、 SE 、經理不是職務。是逃不掉的責任。

  • 業務是最難搞的客戶。

  • 能夠迅速想到解法的程式設計師太多了。

    他們能用一分鐘想到方法,用一天去寫程式。

    不需要花一小時想到解法,再用一小時去寫程式。

    -- Jon Bentley

  • 漂亮的規格,可以從沒有bug出現看出來。

    明明爛的就是設計,為什麼是這樣…

  • 上線後的除錯才叫做bug。

  • 追加需求確定後交貨期限就無法確定,

    交貨期限確定後追加需求就無法確定。

    這稱為「追加需求與交貨期限的測不準原理」。

  • 除三個錯就會冒出一個錯。

    這稱為bug的無窮迴圈。

  • 不祥的預感總會實現。

    不過程式設計師不會去煩惱不祥的預感,那是 SE 的工作。

  • 要解決地獄的辦法,就是客戶把錢交出來。

  • 不懂電腦的操作者是發現bug的天才。而且無法重現。

  • 每次開會就更改規格的客戶,

    他的操作手冊要等到操作寫好的程式後才能寫出來。

  • 搞不懂的時候,Currency(長整數)比Interger(整數)好用。

    Variant(字串、數字都能存的萬能變數)又比Currency(長整數)好用。
    安全第一。

    (VB程式設計師如是說)

  • 啊,那是微軟的規格。

  • 程式設計師所不滿的規格也一定會讓客戶不滿。

    (這是說程式設計師覺得難寫的地方常常是 SE 溝通有落差)

  • 程式設計師需要的技能,

    包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
    SE 需要的技能則減掉程式語言、架構、維護與使用。

    專案經理需要的能力則再減掉業務分析、提案與設計。

    業務需要的能力再扣掉時程管理。

  • 正因為健康,才能做不健康的事。

  • 規、規格、是規格啦。不過有一點跟規格不太一樣啦。

  • 那是你說的規格。

  • 開發室沒有窗戶,那是因為以前…

  • 爛了也是因為規格。

  • SE : 真沒辦法。

    PG: 也沒註解。
    (碰到不知道是誰寫的程式,大家都束手無策的狀態)

  • 為什麼你不能兩三下解決掉他啦。

    因為之前兩三下搞定的東西也被你兩三下就否定了。

  • 不會動的bug就只是普通的bug。(會動的bug則能視為規格)

  • 今天好好清理bug,bug應該死光了吧。

    咦?Windows也死了唷。

  • 客戶不會去想最壞的情況。要他面對最壞的情況,他會認為是漫天開價。

    SE 則會顧慮最壞的情況,準備應付最壞的情況。
    程式設計師比誰都早預料到最壞的情況,而無視最壞的情況。

  • 唯一不產生bug的方法,就是不寫程式。

    第二好的方法,就是在時程跟人員確定之後的每次改規格,都重新檢視過整個專案。

  • 共同責任是程式設計師的責任。

    管理職?那是啥?好吃嗎?我沒吃過耶。

  • 如果可以改行的話,想找個準時下班不叫「逃跑」的工作。

  • 對職業程式設計師來說,漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註,

    也就是新手程式設計師也能馬上動手改的程式。

    而要寫租這樣的程式,需要單純、簡單、美麗的規格。

    但可惜客人總是喜歡搞很複雜。

  • 設計者應該是不該要求製作者製作出超過設計以上內容的吧…

  • 無論是做的比規格書裡的多,還是只照規格書裡的寫, SE 都會找程式設計師的碴。

    所以程式設計師只做規格書裡的寫的內容。

  • SE 對程式設計師說的「常識」每三小時變一次。

  • 自己看規格書。不能跑的是規格。

  • 「沒辦法」是要看把一天當多少小時來算。

    一天常常指的是3人日,一個月常常是指4.5人月喔。

  • 工時要減掉一半的單體測試與一半的系統測試,

    而交貨期則要另外加上上線後的兩個月。

  • 能拿到錢的規格變更稱為「受理項目」,

    拿不到錢的規格變更則稱為「 SE 的規格確認失誤」。

    程式設計師是這麼看的。

  • 累了。我想睡了。可以回家嗎。

    (累了吧,我也累了。好累喔怎麼了。反正就是規格啦,管他的)

  • 試圖降低成本的話,為了配合預算,品質會下降,不過漫天開價做出來的品質也不見得好
    哪裡去。

  • REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎,難道是 red 零 ?
    拜託加上注音吧。

    (譯註:我比較煩惱 Linux)

  • 有人在程式碼註解裡寫日記。像「今天是雨天…」,「想回家…」之類的。甚至還有「修改: 2003/10/10 不能同意你更多」這種註解出現。說到這個,好像也看過「吃大便」這樣的註解。

  • 小學生時第一次看到電腦

    國中時第一次學會怎麼用

    高中與大學學會程式語言

    出社會後才發現自己走錯路

  • 「不要讓老闆當業務比較好」

  • 來說去,要去研究根本不知道為什麼會動的東西為什麼不會動了,找拿破崙來也沒搞頭。

  • 就算程式裡沒 bug,編譯器會有 bug。

    就算編譯器沒 bug,OS 會有 bug。

    就算一切都沒 bug,客戶會決定什麼是 bug。

  • 規格與規格書是不同的東西。

  • 比期限更重要的是靈感與睡眠。

  • 比知識與經驗重要的是手冊與時間。

  • 能動就好了,能動的話…

  • 過了三天就是別人寫的程式碼。

    (搜查線系列)

  • 規格變動不是在會議室裡發生的!是在現場發生的!

    (搜查線系列)

  • 異常不是在模擬測試時發生的!是上線後才會發生的!

  • 漂亮的設計三天或許就膩了

    骯髒的設計三天就習慣了

  • bug與規格是一體兩面

  • 電腦裡沒有bug,bug常在人心。

  • 無論怎麼檢查,不管怎麼確認,上線前一晚就是睡不著。(RFC968)

  • 估價需要1%的經驗與99%的直覺

  • 沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。

  • 『程式設計師』=能將 SE 條理不通的說明翻譯成程式碼的高手

    『 SE 』=與客戶討論改寫規格書、與程式設計師討論後再改寫規格書,程式出貨後還要繼續改寫規格書的人

    『PM』=每天修改自己定下的行程表的人

    『業界老鳥』=臉色蒼白缺乏表情的人

    『外包』=幫不會寫程式的正職員工寫程式的人

    『coding』=複製貼上的工作

    『單體測試』=指開始寫程式

    『除錯』=把程式碼註解掉的工作

    『新同事』=在火燒屁股的專案火上加油的人

    『出貨日』=把只完成一半的系統上線的日子

    『末班電車』=業界平均的下班時間

    『颱風假』=一年一度可以準時下班的業界假日

  • 當誰寫的程式碼跑出bug時,那個人大概都不在了(墨菲定理?)

  • 最終手段

    「重開機」

    意外的常常都很有效

  • 最強藉口

    以前「那是硬體的極限」

    現在「那是 Windows 的規格」

  • 程式碼的可信度,不會比寫的人還可信。