作者herospeed (タシロス・シェン)
看板NIHONGO
標題[格言] プログラマーの格言
時間Sun Oct 12 15:47:45 2008
要求仕様はプログラム完成後に完結する．
基本仕様は完成品を顧客が見てから決定される．
詳細仕様は使用者がプログラムを動かしてから固まる．
※註解
一般來說，程式設計的流程應該要是
顧客要求 ──────→ 基本設計 ──────→ 詳細設計 ──┐
│
┌─────────────────────────────────┘
│
└→ 寫完程式 ──────→ 讓顧客看完成品 ───→ 使用者實際使用程式
然而，實際上作業並非如此。
在現場的流程會是
顧客要求 基本設計 詳細設計
↑ ↑ ↑
寫完程式 ──────→ 讓顧客看完成品 ───→ 使用者實際使用程式
在程式設計的世界裡面，完成品一定會先出現，在那之後，設計書才會出現。
也就是說，正常人所認識的「先有因，才有果」的這個邏輯，
在程式設計的世界裡面根本不成立。
因為這個在這個世界，只有能夠以「先有果，才有因」的邏輯思考的人，
才能活下去。我想，這同時也是造成"程式設計師是怪人的機率很高"的現象
成立的最大原因。
--
═╦╯ ║ ║╰╦═╩═╦╯═╮╭╬═══╬╮
═╬═║ ║ ║╭╬═╩═══╩═ ╰╠╬═══╬╣
╭╬╮╰╮║╭╯║║╠═════╣═╮╭═════╯
║║║ ╭╯╮ ║║╰═════╯ ╰╠╦╦═══╯
║║║╭╯ ╰╮ ║╭║╰╮╰╮ ╭║║╰═╮═╯
╯║║╯ ╰ ╯╯╰════╯═╯╯╰╯ ╰═╯
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 122.130.147.160
1F：推 but:應該是說客戶常常無法準確描述他想要的是什麼 造成開發時制定 10/12 15:52
2F：推 but:規格上線後 客戶才發現不是他想要的東西 而一改再改 10/12 15:55
不過這就是造成「先有果才有因」的最大因素不是?
反正最終的設計報告書永遠要等顧客滿意了才能寫...
相反的就代表在這一個製造工程裡面最後會被完成的都是設計書..
※ 編輯: herospeed 來自: 122.130.147.160 (10/12 15:57)
3F：→ but:再補翻譯XD: 需求規格在程式寫完後才會敲定。 10/12 15:56
4F：→ but: 基本規格要客戶看到成品後才會決定。 10/12 15:56
5F：→ but: 詳細規格要使用者用過後才會確定。 10/12 15:56
6F：推 johanna:軟體的理想設計決定於程式寫完之後，基本設計決定於顧客 10/12 16:04
7F：→ johanna:看到成品之後，詳細設計決定於使用者實際操作之後。 10/12 16:04
8F：推 dobioptt:想想頭都暈了...(樓上是花大耶,花大好 10/13 00:15