[格言] プログラマーの格言

[herospeed (タシロス・シェン)]

                   要求仕様はプログラム完成後に完結する．
                 基本仕様は完成品を顧客が見てから決定される．
              詳細仕様は使用者がプログラムを動かしてから固まる．

※註解

一般來說，程式設計的流程應該要是

        顧客要求 ──────→ 基本設計 ──────→ 詳細設計  ──┐
                                                                      │
  ┌─────────────────────────────────┘
  │
  └→　寫完程式 ──────→ 讓顧客看完成品 ───→ 使用者實際使用程式

然而，實際上作業並非如此。
在現場的流程會是

        顧客要求           　　 基本設計           　　 詳細設計
                           　                      　
           ↑              　      ↑             　       ↑
                         　　                      　
        寫完程式 ──────→ 讓顧客看完成品 ───→ 使用者實際使用程式

在程式設計的世界裡面，完成品一定會先出現，在那之後，設計書才會出現。
也就是說，正常人所認識的「先有因，才有果」的這個邏輯，
在程式設計的世界裡面根本不成立。
因為這個在這個世界，只有能夠以「先有果，才有因」的邏輯思考的人，
才能活下去。我想，這同時也是造成"程式設計師是怪人的機率很高"的現象
成立的最大原因。

--
═╦╯    ║      ║╰╦═╩═╦╯═╮╭╬═══╬╮
═╬═║  ║  ║╭╬═╩═══╩═  ╰╠╬═══╬╣
╭╬╮╰╮║╭╯║║╠═════╣═╮╭═════╯
║║║  ╭╯╮  ║║╰═════╯  ╰╠╦╦═══╯
║║║╭╯  ╰╮  ║╭║╰╮╰╮    ╭║║╰═╮═╯
╯║║╯      ╰  ╯╯╰════╯═╯╯╰╯  ╰═╯

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 122.130.147.160
推 but:應該是說客戶常常無法準確描述他想要的是什麼 造成開發時制定
推 but:規格上線後 客戶才發現不是他想要的東西 而一改再改
不過這就是造成「先有果才有因」的最大因素不是?
反正最終的設計報告書永遠要等顧客滿意了才能寫...
相反的就代表在這一個製造工程裡面最後會被完成的都是設計書..
※ 編輯: herospeed       來自: 122.130.147.160      (10/12 15:57)
→ but:再補翻譯XD: 需求規格在程式寫完後才會敲定。
→ but:            基本規格要客戶看到成品後才會決定。
→ but:             詳細規格要使用者用過後才會確定。
推 johanna:軟體的理想設計決定於程式寫完之後，基本設計決定於顧客
→ johanna:看到成品之後，詳細設計決定於使用者實際操作之後。