開發者的 common sense

最近某位開發者和同人討論需求規格的問題,但他的反應卻讓人感到困惑,不知是他的理解能力有問題,還是面對問題太過情緒化?以下是我們對話的內容。

開發者 D 君問同人:「規格好像沒有提到欄位空白該如何處理?」

同人回答:「沒特別說明就是代表將該欄位填入空白。」

D 君說:「為什麼不是未指定欄位內容呢?」

同人說:「如果是那樣,該欄位不應該在交易訊息中出現;但如果該欄位的內容是空白,那就應該不指定訊息欄位的值。」

D 君說:「不過,從交易訊息的定義來看,那個欄位是必要欄位,不可能不出現。」

同人說:「所以那個欄位是必要的,訊息中沒有指定值就代表欄位要填入空白。」

D 君說:「那規格應該交待這個細節?」

同人說:「不需要,規格文件不寫語法而只會記載語意,因為語法是屬於 common sense,沒必要詳盡記錄在規格文件中。不然,如果連 common sense 都要寫在文件上的話,那是否意味程式設計者也不需要懂程式語言了,反正文件上都會寫。」

D 君說:「我知道了,你的意思是說我沒有 common sense!」

同人說:「如果你覺得我那裡說你沒 common sense,請明說我可以向你道歉,否則你這種情緒化的言論,只會讓人感到不舒服!」

D 君:…

同人將這件事寫在噗浪上,有噗友認為這類的開發者能力不行,沒什麼產值卻會製造問題。不過,在此事我所看到的問題倒不是開發者能力,而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通,這才是我認為最可怕的事情。

以同人的觀察來看,許多開發者看規格文件,通常不會站在問題的角度來思考,而是要求別人把答案準備好,然後告訴他們照著把功能做出來。

他們認為文件必須要註明他需要用到的所有資訊,而不要期待他們了解問題,因為他們不想花太多的心力來弄懂它,如果程式照規格開發而出現問題,那必然是規格問題而不是他們的疏失。因此,他們根本不在乎規格記錄語法或是語意,反正有寫就照著做,沒有寫的就不用管它,也不用思考合不合乎他們的 common sense

同人認為這種心態正是忽略軟體開發的複雜本質,特別是軟體開發常會碰到半結構化、甚至是非結構的問題,使得規格文件難以事先將所有可能遇到的狀況都定義清楚。

舉個常見的例子來說,系統發生某些特別的異常狀態多半不是事前可以預料到的,沒有人能在事前發現問題,但等到發生意外才會發現問題在那裡。而且當我們發現到愈多問題,我們就會發現更多難以預料的未知的問題。

因此,開發者期待文件詳盡到無所不包,在專案現實是不可能做到的。實務上,通常文件規格的重點在於瞭解問題或如何解決問題,而並非得到詳盡的規格。但不明究理的開發者總是不去瞭解問題,只關心規格實做上的細節,當然很難掌握解決問題的要領。同人想到溫伯格說的「沒問題病候群」,他建議碰到這種人還是閃遠一點吧。

其實,表面上 D 君碰到的問題,好像是更改對語法的定義就可以解決問題;客戶認為交易訊息中的欄位不應該是空白的,所以訊息中的欄位空白應該代表該欄位內容未指定。但這樣的想法將會使得語法會受到業務規則的衝擊,而破壞設計概念的整體性與一致性,而影響軟體的設計結構。事實上,語法是不應該受到業務規則的影響,而是用語意來解決業務邏輯的合理性問題。

如果該欄位是必要欄位,那訊息中此欄位出現空白就應該認定資料錯誤;但如果它並不是必要欄位,那麼就應該定義訊息此欄位為非必要欄位。而在前者的狀況下,我們應該增加一條業務規則來檢核必要欄位不可為空白,否則將拋出異常的回應。如此就非常簡單解決問題,而不該採取自廢武功的作為,因為那只會顯露出開發者缺乏抽象化思考的 common sense 呀。

Please follow and like us:
分類: 分析設計建模, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 衝突, 設計原則。這篇內容的永久連結

在〈開發者的 common sense〉中有 10 則留言

  1. 自動引用通知: 同人的生活派對 » 訊息交易的抽象化思考

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *