[轉錄]程式設計的格言

SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
程式設計師多半自己不面對客戶。
---------------------------------------------------------------------------------
1
每天有24小時。所謂的「今天之內」，是指到明天早上為止。
2
程式不會照自己所想的跑。只會照所寫的跑。
3
需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
4
我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
5
程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！
6
先說「沒辦法」的人贏。
7
有意見的話你寫
8
要殺一個程式設計師不需要刀，改三次規格就好
9
首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）
10
開發沒有終點。只有釋出(release)。
11
無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。
12
客戶總是覺得水跟追加需求是不用錢的。
13
付錢愈計較的客人愈囉唆。
14
在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。
15
一個人掛了大家都掛了。
16
bug過了一晚可能就變成規格了。
17
好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。
18
客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。
19
對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。
20
顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，則要早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。
21
很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。
22
品質的劣化程度依規格改變的次數與規模而定。
23
業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
24
有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
25
程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。
26
程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。
27
對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。
28
程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗試減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。
29
SE需要持久力，程式設計師需要爆發力。
30
準時離開公司，工作會變多。
31
完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。
32
詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。
33
還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。
34
程式的異常該稱為「bug」還是「規格上的限制」
是看期限還剩多久決定的。
35
地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
36
遠處的火災一定燒到這裡。
37
禱告，然後跑吧。