程式設計師的格言 (續)

又是蒐集自日本各大網站 (mixi, 2ch) 後，憑自己個人好惡選擇了一些句子。
只是我覺得還是之前的部分更經典XD

(最後修正 2011/10/26)

1
最好騙的總是自己。

2
抄來的程式碼是bug之母。

3
輕易刪掉的程式碼，往往在之後都需要用到。

4
電不會騙你，測試資料有錯時，都是人錯了。

5
交貨日是為了打破而存在的。
(譯註) 漫畫、作家業名句「截稿日是為了打破而存在的」，出處已不可考。

6
程式碼如其人。

7
發問是一時之恥，不問是一生之蟲。

8
「/* 刪掉下面這行不知道為什麼就會當掉 */」是永遠不滅的。

9
覺得「這是什麼沒可讀性的爛程式！」時，常常是自己以前寫出來的程式碼。

10
「誰說程式設計師就一定熟電腦的」

11
使用手冊是需要的人不會讀它，而不需要的人會去讀的神祕讀物。

12
無論有多奇怪，只要符合規格就是滿分。
無論如何完美，只要不符合規格就是零分。

13
我前方沒有規格，bug在我身後形成。
(譯註) 高村光太郎《道程》的名句 ─ 我前方沒有道路，路在我身後形成。

14
所謂的專業，並不是努力於辦不到的工作，
而是在事前能夠判斷出工作辦不到。

15
把勞基法當作是別國的法律就對了。

16
當你有「啊，加上這功能吧」的念頭時，還是不要想太多，早點去睡結果會比較好。

17
狀況總在週末來臨。

18
「責任」不是該負的人要負的，而是要負的人被逼著負的。

19
看到別家公司寫的程式碼，就知道客戶有多麼被看不起，然後自己得到了勇氣。

20
老闆是bug。

21
程式設計師的價值決定在寫了多少程式碼，
程式設計師的技能決定在讀了多少程式碼。

22
熟悉程式語言不表示就會寫軟體。

23
熟悉程式語言後，軟體會寫得更慢。

24
機器感受到你的著急，所以他壞了。

25
程式設計師就算有愛，也不能愛上程式設計，
因為程式有讓人墮入地獄的力量。

26
程式設計師重視過程，客戶重視結果，所以永遠是兩條平行線。

27
為了解決問題而最初想出來的點子，通常都有一些問題。

28
發現問題如何解決不是最重要的，發現哪裡是問題比較重要。

29
除錯，是喚醒沉睡錯誤的儀式。

30
測試後如果沒找到任何bug，一定是測試有出錯。

31
就像SE所說的「辦得到」往往不可信，PG說的「辦不到」也不可信。

32
如果bug十年都沒人發現，就不要理他。
去解掉它的話，不出半年就會被人當作bug了。

33
想個好的變數名稱比想演算法還花時間。

34
要在水面上行走、要照規格開發軟體都很簡單。如果能固定不動的話。

35
別相信手冊！相信我！

36
還沒付錢的，不是客戶。 已經付清的，也不是客戶。

37
不知道自己在修什麼的維修員。

38
try-catch 然後 return null。～推卸責任～

39
客戶的抱怨去認真聽（約兩小時左右）就對了。
這樣一來客戶的問題就可以說是解決一半了。
也就是程式就不用改了。

40
bug 是不會看臉色的。

41
昨天的自己是今天的敵人。

42
SE的沉默代表著進度順暢的安心，
PG的沉默代表著進度空白的悲鳴。

43
業務的幸福是技術者的不幸。

44
接受「口頭規格」的開發案，就好像開一張空白支票給別人一樣。

45
這不叫更改規格。
因為打從一開始就沒有規格存在。

46
程式這檔事，總是會有「難以置信」的事情發生。

47
程式設計師這種人，總是會寫出「難以置信」的程式碼。

48
而「難以置信」的程式碼，不知道為什麼常常跑得很好。

49
要證明 bug 不是自己的責任，往往比修好這個 bug 更花時間。

50
bug 是會怕生的。
兩個人在一起明明很大方的，更多人來看時就躲起來了。

51
程式的養分來自於程式設計師的鮮血。

52
不知道為什麼不會動的東西，OS程式設計師會在下一版讓他動。
不知道為什麼不會動的東西，開源程式設計師會在下一版捨棄它。
不知道為什麼不會動的東西，週日程式設計師會嘗試在下一版讓它動，結果膩了而放置。

53
當程式的原始碼規模超過臨界點，就會離開程式設計師的手，擁有自己的意志。

54
直接看程式碼，比看英文的註解好懂多了。

55
要求「功能要有彈性」的客戶，往往思考都沒有彈性。

56
程式的字典裡沒有「不可能」，但程式設計師有。

57
沒被發現的 bug，就不是 bug！

fin.
悲哀啊！
只能一直寫著這些悲觀格言，是台灣程式設計師的現實。

Social Comments