「開發者的 common sense」的迴響

由：jim yeh

jim yeh — Thu, 05 Nov 2009 04:52:44 +0000

既然樓上說過每個人認定的標準不同，那麼你說的激烈實際上可能不激烈嘍。

不同的認知，沒有對錯。但開發者不願意思考問題，只希望我們告訴他答案可以讓他不用大腦。我看到這樣實在很危險，難道不應該提出來溝通怎麼解決問題嗎？還是只能坐視他在工作態度的頽廢？

由：weskerjax

weskerjax — Thu, 05 Nov 2009 02:57:59 +0000

在溝通上有必要這麼激烈嗎？？

而且每個人認定的標準不同
設計師認為是工程師沒腦袋
工程師認為設計師設計不良

但明確的規範不正是減少 Bug 的良藥嗎？
在審視每一個細節時才會發現架構的疏失啊！
評估再評估！分析再分析！

工程師擔心做錯而要求明確性
我也不想一天到晚都在改 code 找 bug
接受他人的意見
去改善自我可能的問題
這不也是領導者的課題嗎？

由：同人的生活派對 » 訊息交易的抽象化思考

同人的生活派對 » 訊息交易的抽象化思考 — Tue, 03 Feb 2009 10:13:06 +0000

[...] 在〈開發者的 common sense〉的留言中，同人看到一些網友的批評。我發現這些批評顯示了有些開發者不擅於抽象化思考，而習慣於用經驗法則來取代思考。然而，誠如 Brooks 所言：「軟體的本質是複雜的，而不是偶然發生的」對治複雜度本來就是開發者的天職，而軟體開發的抽象化思考則是其用以統理複雜度的利器。由此看來，那些網友的批評著實令人為他們捏一把冷汗呀。 [...]

由：X files

X files — Thu, 29 Jan 2009 02:40:36 +0000

文章前後都沒提到是關於XML的格式,也沒有列出reference的文章,又怎麼叫人家看清楚你的訴求重點呢?
這也是寫部落格的common sense呢,程式我不懂所以不知道到底是誰沒common sense;但以寫部落格來講,居然在沒有任何標註reference的情況下,要讀者自己去找以前文章才能了解(幸好作者自己有回應補充,才稍有頭緒),難道你的文章是bible,一定要從第一篇讀起才能做回應嗎?這實在是缺乏common sense(我是指寫部落格文章,不是指寫程式).

由：3

Tue, 27 Jan 2009 04:34:09 +0000

這種 common sense 才是亂糟糟的程式的由來..

由：jim yeh

jim yeh — Mon, 26 Jan 2009 08:12:02 +0000

問題根本不在空白或是null，如果看不懂我指的 common sense 是什麼的話，我之前寫的文章說得很清楚：

XML 訊息中，使用空標籤並不能代表用不到該標籤對應到的欄位。同人以為有經驗的開發者應該都知道上面提到的觀念，空標籤代表應對的資料內容是空值，而省略標籤則代表不知該資料的確切內容，或是指該資料在此刻並「不適用」（N/A，Not available）

因此，對於沒看清楚文章訴求重點就亂評論的人，同人不予置評，因為那代表你沒認真看文章，我也不用浪費我的時間幫你弄清楚。

由：oofunp

oofunp — Sat, 24 Jan 2009 15:41:50 +0000

呼,我又看了幾回,
我想我誤解意思了
這看起來不是在討論資料庫的定義.
反而是資料庫已經定義好.
而是在討論Function對參數的處理,
.
格主所說的common sense,是指程式語言.
也就是Function的規格不需要詳細到用程式語言去描述,
不然也不需要程設師來寫程式.
.
我覺得格主有誤會D君所問的->"那規格應該交待這個細節？"這句話
D君說的細節應該不是指用程式來描述處理規則(語法).
而是規則沒有寫清楚(語意).
但D君實際上也問到他要的答案了
也就是->
"同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」"
.
他只是在疑問為什麼這句話不寫進去規格?
這跟程設師有沒有common sense(程式語言能力)沒有關係吧.
.
看來,這只是很單純的一場誤會而已.(也就是雞同鴨講啦.)
=======================================
.
至於,最後所說的->"我們應該增加一條業務規則來檢核必要欄位不可為空白…"
是指檢查業務規則的函數要作成可以用委派(函數指標? 事件? dll?)的方式來動態加入嗎?
.
這樣作是很有彈性沒錯,但我覺得這比較適合在作萬用型的基礎系統,
如果是客製化的專案,時間應該都很有限吧? 這樣作反而增加專案的困難度.
會比較好嗎??
=========================================
個人是覺得格主的文章好像文言文,我看好幾遍,都還是有點看不懂,
一開始我還以為格主所說的抽象化,是指要將整個資料庫定義抽象化,
落差還真大.
是我的語文能力太差嗎…-_-

由：oofunp

oofunp — Sat, 24 Jan 2009 10:57:24 +0000

假設我是D君
我來理解一下格主想要表達的意思:
—————————————–
文件上沒寫的,
就由我自己決定(->我的common sense).
.
專案有明確的期限,
但是在期限內,需求會不斷地修改,
.
所以我設計資料庫不用想太多.
也就是說不要管資料庫正規化、設定Check..等
所有的欄位,型態都是文字,也全都允許null.
.
資料的內容定義和檢查,就全部交由業務邏輯程式來完成
這樣子,需求改變,只要改業務邏輯程式就好了.
————————————-
.
我這樣子理解對嗎?

由：路人

路人 — Sat, 24 Jan 2009 01:20:20 +0000

沒錯!我也同意1樓的講法.
敝人也有多年程式設計以及帶領軟體專案的經驗,這篇文章讓我覺得同人版主是個不夠謹慎的程式人員.(很抱歉!不是要批評版主,純粹以個人經驗就事論事,如果讓你感到不舒服請明說,我會道歉)
你的common sense不等於我的common sense,文件不夠詳細之處就應該提出來討論,都以自己的common sense去猜想,以我的經驗來看,這正是事後除錯困難的原因之一.常常會有自以為資深的程式人員,以自己的common sense去處理,等到錯誤被抓出來之後,才又辯解:這不是應該怎樣怎樣….,或者: 這個以前不是都怎樣怎樣處理….
尤其像這個案例,空值、空白、未指定這些不同的處理方式,本來就應該在資料定義時註明,或許有些系統對這幾種資料不同內容的處理沒有影響,但有些(定義嚴謹的)系統對這些內容處理卻會大不同.

由：路邊的垃圾筒

路邊的垃圾筒 — Fri, 23 Jan 2009 12:02:11 +0000

慘了，原來我也沒有 common sense …. (T_T)

就個人而言會要求該欄位應標示是否接受 null 值，是否為必要欄位，以及若為字串時是否接受 0 長度字串。

正因為使用者無法在螢幕上分辨出來這一個空白格子中究竟代表著什麼意義，所以更應需要一個明確定義以確保系統不致於發生 GIGO 的情形！

再說，這裡所謂的 common sense 究竟是屬於誰的 common sense ？技術人員的？使用單位主管的？實際使用者的？或者其實是使用單位隔壁那間辦公室的？