最近某位開發者和同人討論需求規格的問題，但他的反應卻讓人感到困惑，不知是他的理解能力有問題，還是面對問題太過情緒化？以下是我們對話的內容。
開發者 D 君問同人：「規格好像沒有提到欄位空白該如何處理？」
同人回答：「沒特別說明就是代表將該欄位填入空白。」
D 君說：「為什麼不是未指定欄位內容呢？」
同人說：「如果是那樣，該欄位不應該在交易訊息中出現；但如果該欄位的內容是空白，那就應該不指定訊息欄位的值。」
D 君說：「不過，從交易訊息的定義來看，那個欄位是必要欄位，不可能不出現。」
同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」
D 君說：「那規格應該交待這個細節？」
同人說：「不需要，規格文件不寫語法而只會記載語意，因為語法是屬於 common sense，沒必要詳盡記錄在規格文件中。不然，如果連 common sense 都要寫在文件上的話，那是否意味程式設計者也不需要懂程式語言了，反正文件上都會寫。」
D 君說：「我知道了，你的意思是說我沒有 common sense！」
同人說：「如果你覺得我那裡說你沒 common sense，請明說我可以向你道歉，否則你這種情緒化的言論，只會讓人感到不舒服！」
D 君：…
同人將這件事寫在噗浪上，有噗友認為這類的開發者能力不行，沒什麼產值卻會製造問題。不過，在此事我所看到的問題倒不是開發者能力，而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通，這才是我認為最可怕的事情。
以同人的觀察來看，許多開發者看規格文件，通常不會站在問題的角度來思考，而是要求別人把答案準備好，然後告訴他們照著把功能做出來。
他們認為文件必須要註明他需要用到的所有資訊，而不要期待他們了解問題，因為他們不想花太多的心力來弄懂它，如果程式照規格開發而出現問題，那必然是規格問題而不是他們的疏失。因此，他們根本不在乎規格記錄語法或是語意，反正有寫就照著做，沒有寫的就不用管它，也不用思考合不合乎他們的 common sense。
同人認為這種心態正是忽略軟體開發的複雜本質，特別是軟體開發常會碰到半結構化、甚至是非結構的問題，使得規格文件難以事先將所有可能遇到的狀況都定義清楚。
舉個常見的例子來說，系統發生某些特別的異常狀態多半不是事前可以預料到的，沒有人能在事前發現問題，但等到發生意外才會發現問題在那裡。而且當我們發現到愈多問題，我們就會發現更多難以預料的未知的問題。
因此，開發者期待文件詳盡到無所不包，在專案現實是不可能做到的。實務上，通常文件規格的重點在於瞭解問題或如何解決問題，而並非得到詳盡的規格。但不明究理的開發者總是不去瞭解問題，只關心規格實做上的細節，當然很難掌握解決問題的要領。同人想到溫伯格說的「沒問題病候群」，他建議碰到這種人還是閃遠一點吧。
其實，表面上 D 君碰到的問題，好像是更改對語法的定義就可以解決問題；客戶認為交易訊息中的欄位不應該是空白的，所以訊息中的欄位空白應該代表該欄位內容未指定。但這樣的想法將會使得語法會受到業務規則的衝擊，而破壞設計概念的整體性與一致性，而影響軟體的設計結構。事實上，語法是不應該受到業務規則的影響，而是用語意來解決業務邏輯的合理性問題。
如果該欄位是必要欄位，那訊息中此欄位出現空白就應該認定資料錯誤；但如果它並不是必要欄位，那麼就應該定義訊息此欄位為非必要欄位。而在前者的狀況下，我們應該增加一條業務規則來檢核必要欄位不可為空白，否則將拋出異常的回應。如此就非常簡單解決問題，而不該採取自廢武功的作為，因為那只會顯露出開發者缺乏抽象化思考的 common sense 呀。
慘了，原來我也沒有 common sense …. (T_T)
就個人而言會要求該欄位應標示是否接受 null 值，是否為必要欄位，以及若為字串時是否接受 0 長度字串。
正因為使用者無法在螢幕上分辨出來這一個空白格子中究竟代表著什麼意義，所以更應需要一個明確定義以確保系統不致於發生 GIGO 的情形！
再說，這裡所謂的 common sense 究竟是屬於誰的 common sense ？技術人員的？使用單位主管的？實際使用者的？或者其實是使用單位隔壁那間辦公室的？
沒錯!我也同意1樓的講法.
敝人也有多年程式設計以及帶領軟體專案的經驗,這篇文章讓我覺得同人版主是個不夠謹慎的程式人員.(很抱歉!不是要批評版主,純粹以個人經驗就事論事,如果讓你感到不舒服請明說,我會道歉)
你的common sense不等於我的common sense,文件不夠詳細之處就應該提出來討論,都以自己的common sense去猜想,以我的經驗來看,這正是事後除錯困難的原因之一.常常會有自以為資深的程式人員,以自己的common sense去處理,等到錯誤被抓出來之後,才又辯解:這不是應該怎樣怎樣….,或者: 這個以前不是都怎樣怎樣處理….
尤其像這個案例,空值、空白、未指定 這些不同的處理方式,本來就應該在資料定義時註明,或許有些系統對這幾種資料不同內容的處理沒有影響,但有些(定義嚴謹的)系統對這些內容處理卻會大不同.
假設我是D君
我來理解一下格主想要表達的意思:
—————————————–
文件上沒寫的,
就由我自己決定(->我的common sense).
.
專案有明確的期限,
但是在期限內,需求會不斷地修改,
.
所以我設計資料庫不用想太多.
也就是說不要管資料庫正規化、設定Check..等
所有的欄位,型態都是文字,也全都允許null.
.
資料的內容定義和檢查,就全部交由業務邏輯程式來完成
這樣子,需求改變,只要改業務邏輯程式就好了.
————————————-
.
我這樣子理解對嗎?
呼,我又看了幾回,
我想我誤解意思了
這看起來不是在討論資料庫的定義.
反而是資料庫已經定義好.
而是在討論Function對參數的處理,
.
格主所說的common sense,是指程式語言.
也就是Function的規格不需要詳細到用程式語言去描述,
不然也不需要程設師來寫程式.
.
我覺得格主有誤會D君所問的->”那規格應該交待這個細節？”這句話
D君說的細節應該不是指用程式來描述處理規則(語法).
而是規則沒有寫清楚(語意).
但D君實際上也問到他要的答案了
也就是->
“同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」”
.
他只是在疑問為什麼這句話不寫進去規格?
這跟程設師有沒有common sense(程式語言能力)沒有關係吧.
.
看來,這只是很單純的一場誤會而已.(也就是雞同鴨講啦.)
=======================================
.
至於,最後所說的->”我們應該增加一條業務規則來檢核必要欄位不可為空白…”
是指檢查業務規則的函數要作成可以用委派(函數指標? 事件? dll?)的方式來動態加入嗎?
.
這樣作是很有彈性沒錯,但我覺得這比較適合在作萬用型的基礎系統,
如果是客製化的專案,時間應該都很有限吧? 這樣作反而增加專案的困難度.
會比較好嗎??
=========================================
個人是覺得格主的文章好像文言文,我看好幾遍,都還是有點看不懂,
一開始我還以為格主所說的抽象化,是指要將整個資料庫定義抽象化,
落差還真大.
是我的語文能力太差嗎…-_-
問題根本不在空白或是null，如果看不懂我指的 common sense 是什麼的話，我之前寫的文章說得很清楚：
因此，對於沒看清楚文章訴求重點就亂評論的人，同人不予置評，因為那代表你沒認真看文章，我也不用浪費我的時間幫你弄清楚。
這種 common sense 才是亂糟糟的程式的由來..
文章前後都沒提到是關於XML的格式,也沒有列出reference的文章,又怎麼叫人家看清楚你的訴求重點呢?
這也是寫部落格的common sense呢,程式我不懂所以不知道到底是誰沒common sense;但以寫部落格來講,居然在沒有任何標註reference的情況下,要讀者自己去找以前文章才能了解(幸好作者自己有回應補充,才稍有頭緒),難道你的文章是bible,一定要從第一篇讀起才能做回應嗎?這實在是缺乏common sense(我是指寫部落格文章,不是指寫程式).
自動引用通知: 同人的生活派對 » 訊息交易的抽象化思考
在溝通上有必要這麼激烈嗎？？
而且每個人認定的標準不同
設計師認為是工程師沒腦袋
工程師認為設計師設計不良
但明確的規範不正是減少 Bug 的良藥嗎？
在審視每一個細節時才會發現架構的疏失啊！
評估再評估！分析再分析！
工程師擔心做錯而要求明確性
我也不想一天到晚都在改 code 找 bug
接受他人的意見
去改善自我可能的問題
這不也是領導者的課題嗎？
既然樓上說過每個人認定的標準不同，那麼你說的激烈實際上可能不激烈嘍。
不同的認知，沒有對錯。但開發者不願意思考問題，只希望我們告訴他答案可以讓他不用大腦。我看到這樣實在很危險，難道不應該提出來溝通怎麼解決問題嗎？還是只能坐視他在工作態度的頽廢？