程式設計師的格言


看到這幾句是節錄第 3、9、35點 和 ex 第 6、14 點, 本來想紀錄覺得有趣的就好, 但是幾乎都太經典了(特別是最下面的 ex 系列), 還是全文轉載留存, 感謝作者的辛勞. Orz…(註: 內文轉載, 有稍做簡單的排版)

需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。

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

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

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

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

日本所說的 SE, 我是覺得比較像台灣稱的 系統分析師 - System Analyst(SA).

作者查詢的 SE 解釋: System Engineer(SE): 根據需求說明,編寫項目設計式樣書,同時參與部分模塊的開發與測試


下述文章完整轉載自: 程式設計師的格言 « but, or bug

程式設計師的格言(盜作不少)

譯自

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

譯註

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

  1. 每天有24小時。
    所謂的「今天之內」,是指到明天早上為止。
  2. 程式不會照自己所想的跑。只會照所寫的跑。
  3. 需求規格在程式寫完後才會敲定。
    基本規格要客戶看到成品後才會決定。
    詳細規格要使用者用過後才會確定。
  4. 我對軟體設計的方式導出的結論,有兩種方式。
    一是把軟體設計得單純到很明顯不會有缺陷,
    不然就是把軟體設計得複雜到沒有明顯的缺陷。

    - C.A.R.Hoare
  5. 程式碼不要在開發現場寫! 去客戶那寫!
    除錯不要在期限前做! 上線後再做!
  6. 畫面是藍色的!
    (國際太空站太空人重新安裝 Windows NT,日誌中的名句)
  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想受顧客喜歡,則要讓程式設計師討厭自己。
  22. 很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做,
    不過都沒這種機會。
  23. 品質的劣化程度依規格改變的次數與規模而定。
  24. 業務是認為空想能夠實現的夢想家。
    SE則是深信任何障礙都能突破的冒險家。
    程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
  25. 有才能的程式設計師第一次看到設計細節時,要先理解程式的目的。
    接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
  26. 程式是運氣與直覺堆砌而成的奇蹟。
    若不具備這兩者,不可能以這樣的工時實現這樣的規格。
    修改規格是對奇蹟吐槽的褻瀆行為。
    而追加修改則是相信奇蹟還會重現的無謀行動。
  27. 程式設計師聽了「把自己當作顧客去著想!」而開始思考。
    啊,像夢一樣。
  28. 對於因為興趣而寫程式的人來說,所謂的技術是程式語言能力。
    對於因為工作而寫程式的人來說,所謂的技術是邏輯思考能力與人際溝通能力。
    程式語言可以看著手冊溝通,客戶不行。
  29. 程式系統在交貨之前會不斷縮小。
    先用元件定義取悅老闆。
    再拿經費概算要部長妥協現實的方案。
    在運用會議中,課長會嘗識減少自己責任範圍。
    在細節會議中,負責人會把範圍縮到自己記得的部分。
  30. SE需要持久力,程式設計師需要爆發力。
  31. 準時離開公司,工作會變多。
  32. 完美的程式需要完美的時間與金錢。
    聽說揮霍著美國的國家預算的NASA,也覺得時間跟錢不夠。
  33. 詳細設計要在程式碼的註解裡做完。
    註解是唯一的自衛手段,至少要讓自己看懂。
  34. 還有時間看程式碼的話就執行他。
    CPU跑得比腦細胞快。至少這時候可以休息。
  35. 程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
  36. 所謂便服日,好像社會上把他叫做假日
    (註) 日本有些公司會有所謂便服日(不用穿西裝的日子),通常是星期五,但…
  37. 地獄持續一段時間後,充滿殺氣的怒吼會變多。
    再持續一段時間,說話會變少但牢騷會變多,壟罩在凝重的氣氛裡。
    再持續下去,反而會海闊天空,四周洋溢充滿活力的聲音。
    這種狀態稱為「Programmer’s High」,也是倒下來的人開始出現的時候。
  38. 遠處的火災一定燒到這裡。
  39. 禱告,然後 “工作” 吧。(修道院的標語)
  40. 程式不是用腦記的,要用身體記住。
  41. 明天能放假的話死了也罷。
  42. 外面有下雨耶,昨天開始下的嗎?
  43. 心若不廢掉(消極),身體會廢掉。
    若不讓自己殘忍,自己會被殺。
  44. 客戶會說謊,業務會作夢,SE會做白日夢。
    程式設計師則惦惦。(愈來愈自言自語)
  45. SE總是不講理的(unreasonable)說「沒有辦不到(impossible)」,
    業務總是沒辦法(impossible)說「沒道理(unreasonable)」。
  46. 規格書就像航海圖,客戶則是洋流。洋流陰晴不定,航海圖就變垃圾。
    程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
  47. 再嘮嘮叨叨下去也是要付錢的。
  48. 多想個10