(轉貼)程式設計師的格言

這是今天早上同事轉寄過來的網址，
原作者翻譯了日本人寫的「程式設計師的格言」。
雖然日本有許多的習慣、生活方式都與台灣大不相同，
但是在軟體產業，似乎有著大同小異的情況。
所以這些日本程式設計師口中說出的話，
還有不少讓我感同身受的。
原文來自：http://buttaiwan.wordpress.com/

程式設計師的格言（盜作不少）

譯自
http://www2.biglobe.ne.jp/~oni_page/other/etc/pr03.html
http://mixi.jp/view_community.pl?id=1772737

(版本2 2008/10/12更新)

譯註
SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
程式設計師多半自己不面對客戶。
跟PM又不一樣。（有什麼比較貼切的職稱翻譯嗎？）

註 by 狼神
黑色字體為原文，適度在不改變原意下略為修改。
綠色字體為狼神加油添醋的意見。

—————

1
每天有24小時。
所謂的「今天之內」，是指到明天早上為止。
=>也就是說不管你要不要睡，要不要回家，就是明天早上看到成果就對了！

2
程式不會照自己所想的跑。只會照所寫的跑。
=>十分同意，只是自己所寫的往往不會跟自己想的一樣…

3
需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
=>也就是說出貨前都不會定…

4
我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare

5
程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！

6
畫面藍了。

7
先說「沒辦法」的人贏。
=>沒錯！有膽先說的人就贏了…

8
有意見的話你寫
=>我一直很想講，但講不出口的話…

9
要殺一個程式設計師不需要刀，改三次規格就好
=>其實不見得一定要到三次…

10
首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）
=>這招我已經練到，會懷疑自己，但不會先說出口

11
開發沒有終點。只有釋出(release)。
=>不然呢？

12
無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。
=>它跟物理界的「質能手恆定理」同等重要

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

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

15
在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。

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

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

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

19
客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。

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

21
顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。
=>其實蠻多SE（在我們公司是蠻接近PM的），還蠻成功的…

22
很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。

23
品質的劣化程度依規格改變的次數與規模而定。
=>其實跟公司COST DOWN的程度也有關係

24
業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
=>為什麼夢想家跟冒險家是把別人推進海裡呢？

25
有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
=>我的才能還不夠…

26
程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。
=>這句說的好！

27
程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。
=>我也很希望我是顧客…

28
對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。
=>我很早就說過，我希望我的工作只需要跟機器往來，而不是人類。

29
程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。

30
SE需要持久力，程式設計師需要爆發力。

31
準時離開公司，工作會變多。

32
完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。

33
詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。
=>實際上，註解常常是在好不容易才看懂一段自己寫的程式之後才會產生的…

34
還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。
=>原來如此啊，我都沒想到

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

36
所謂便服日，好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但…
=>我們每天都穿便服啦，還好我們假日跟便服日是不同的

37
地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
=>這種「Programmer’s High」基本上就是跟「迴光返照」有點類似的情況。或者「物極必反」也是蠻貼切的。

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

39
禱告，然後跑(run 程式)吧。

40
程式不是用腦記的，要用身體記住。

41
明天能放假的話死了也罷。
=>不如請假還是辭職吧

42
外面有下雨耶，昨天開始下的嗎？

43
若不能心靜不移，身體會掛。
若不讓自己殘忍，自己會被殺。

44
客戶會說謊，業務會作夢，SE會做白日夢。
程式設計師則惦惦。（愈來愈自言自語）

45
（日文文字遊戲）
SE總是不負責的說「別逞強」，
業務總是無理取鬧不准說「沒辦法」。

46
規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。

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

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

49
人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從眾多失敗中記取教訓。
=>其實也沒辦法從自己的失敗記取教訓，以前被人家這樣搞，等自己昇官了，還是這樣搞別人

50
老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。

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

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

53
業務是最難搞的客戶。

54
能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley

55
漂亮的規格，可以從沒有bug出現看出來。
明明爛的就是設計，為什麼是這樣…

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

57
追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。

58
除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。
=>那出現的一個錯，有時可能會比前面三個加起來還大。

59
不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感，那是SE的工作。

60
要解決地獄的辦法，就是客戶把錢交出來。
=>交出來也沒有用，因為不會到程式設計師的手上

61
不懂電腦的操作者是發現bug的天才。而且無法重現。
=>我一直覺得「不懂電腦」這點應該要列入TSD徵才的條件之一

62
每次開會就更改規格的客戶，
他的操作手冊要等到操作寫好的程式後才能寫出來。

63
搞不懂的時候，Currency（長整數）比Interger（整數）好用。
Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。
安全第一。
（VB程式設計師如是說）

64
啊，那是微軟的規格。
=>喔，微軟BUG很多啦…

65
程式設計師所不滿的規格也一定會讓客戶不滿。
（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）

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

67
正因為健康，才能做不健康的事。

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

69
那是你說的規格。

70
開發室沒有窗戶，那是因為以前…

71
爛了也是因為規格。

72
SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態）

73
為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。

74
不會動的bug就只是普通的bug。（會動的bug則能視為規格）

75
今天好好清理bug，bug應該死光了吧。
咦？Windows也死了唷。

76
客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。

77
唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。
=>我一直想用第一好的辦法，可是上面不同意。上面一直希望我用第二好的辦法，可是我不願意。

78
共同責任是程式設計師的責任。
管理職？那是啥？好吃嗎？我沒吃過耶。

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

80
對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，
也就是新手程式設計師也能馬上動手改的程式。
而要寫租這樣的程式，需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。

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

82
無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。

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

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

85
「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日，一個月常常是指4.5人月喔。
=>這個可能每個公司都有別

86
工時要減掉一半的單體測試與一半的系統測試，
而交貨期則要另外加上上線後的兩個月。

87
能拿到錢的規格變更稱為「受理項目」，
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。

88
累了。我想睡了。可以回家嗎。
（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）

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

90
REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零 嗎？ 拜託加上注音吧。
（譯註：我比較煩惱 Linux）

91
有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。
=>我們是看過晶片廠商提供的程式中，除錯用的訊息出現「OH~~真驚訝會執行到這裡！」

92
小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路

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

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

————————

ex 1
就算程式裡沒bug，編譯器會有bug。
就算編譯器沒bug，OS會有bug。
就算一切都沒bug，客戶會決定什麼是bug。

ex 2
規格與規格書是不同的東西。

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

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

ex 5
能動就好了，能動的話…

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

ex 7 (大搜查線系列)
規格變動不是在會議室裡發生的！是在現場發生的！

ex 8 (大搜查線系列)
異常不是在模擬測試時發生的！是上線後才會發生的！

ex 9
漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了

ex 10
bug與規格是一體兩面

ex 11
電腦裡沒有bug，bug常在人心。

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

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

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

ex 15
・『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
・『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
・『PM』＝每天修改自己定下的行程表的人
・『業界老鳥』＝臉色蒼白缺乏表情的人
・『外包』＝幫不會寫程式的正職員工寫程式的人
・『coding』＝複製貼上的工作
・『單體測試』＝指開始寫程式
・『除錯』＝把程式碼註解掉的工作
・『新同事』＝在火燒屁股的專案火上加油的人
・『出貨日』＝把只完成一半的系統上線的日子
・『末班電車』＝業界平均的下班時間
・『颱風假』＝一年一度可以準時下班的業界假日

ex 16
當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）

ex 17
最終手段
「重開機」
意外的常常都很有效

ex 18
最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」
=>完全都是微軟的陰謀啦

ex 19
「程式碼的可信度，不會比寫的人還可信。」