jim yeh on 一月 19th, 2010

在軟體開發的過程中,有沒有方法可以避免我們浪費心力在無謂的堅持上,然後用比較簡單而又有效率的方式來完成我們的工作呢?經過與同事上面的對話,同人想到運用到我在分享會中所提到的觀念與實務,可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來,也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。

Continue reading about 掌握設計演進的節奏

     
jim yeh on 一月 7th, 2010

敏捷開發並不是教條式的照本宣科,開發者要懂得變通最重要的是用心思考,而非把必要的思考都看成精神層面的問題,這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應,但文辭有略為做過一番修飾,可以用來澄清我對測試驅動開發步驟的看法。

Continue reading about 測試驅動開發的步驟

     
jim yeh on 一月 5th, 2010

測試驅動開發的精神,不應該用一般機械論的觀點來進行工作或任務的化約,而是基於複雜理論的重要觀念;維持穩定與變化的動態平衡,不在於掌握系統核心而在於邊緣,讓變動限定在人們可以掌握的範圍內,這或許才是測試驅動開發最關鍵的精神吧!

Continue reading about 測試驅動開發的精神

     
jim yeh on 十二月 16th, 2009

表面上看起來好像實作泛型可以讓某一段程式碼重複使用,但 Java 在泛型的限制,也增加他重構程式碼的困難度與複雜度。這麼說來,假如石頭成的想法是正確的,用 Java 的泛型來重構程式碼,只會讓程式員沒事自討苦吃。然而,同人在仔細研究他的程式碼之後,發現可以用更簡潔的方式來使用 Java 的泛型。

Continue reading about Java 泛型複雜嗎?

     
jim yeh on 六月 7th, 2009

程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率,同時使得程式的再用性難以提昇。因此降低程式碼的重覆性對程式碼的品質與彈性有很大的助益。然而,在資料存取與與物件型別的無法分離的情況下,卻會使得開發者難以對治程式碼的重覆性;相同處理資料的邏輯,受限於處理資料的不同型態,使得開發者必須依據資料型態不同,而改寫同一段程式碼,使得程式碼很難共用。 就像一個比較常見的例子是資料永續存取的實作,常會因為存取資料型態的不同,而影響到資料存取的界面,因此對每一個需要持久化的商業領域物件,都必須重覆地實作它們的 CRUD 存取功能。 雖然透過永續層的概念,我們可以將這種重覆性隔離開來,加上有些 ORM 永續框架的協助,開發資料存取物件的負擔並不太大。然而即使如此,我們有沒有可能避免重覆開發資料存取的元件,不用針對每一種物件型別都要寫一支相對的資料存取物件呢?要達到這樣的目的,我們必須分離資料存取的處理程序與物件型別,但要如何才能做到呢?

Continue reading about 降低資料存取的重覆性

     
jim yeh on 二月 3rd, 2009

在〈開發者的 common sense〉的留言中,同人看到一些網友的批評。我發現這些批評顯示了有些開發者不擅於抽象化思考,而習慣於用經驗法則來取代思考。然而,誠如 Brooks 所言:「軟體的本質是複雜的,而不是偶然發生的」對治複雜度本來就是開發者的天職,而軟體開發的抽象化思考則是其用以統理複雜度的利器。由此看來,那些網友的批評著實令人為他們捏一把冷汗呀。 從路邊的垃圾桶與路人的留言,我們可以發現他們弄錯 common sense 的意思。他們認為 common sense 不能一概而論,因為每個人的 common sense 都不同。但這樣的觀點令人感到疑惑,如果每個人的 common sense 都不一樣,所以無法一概而論,那這種 common sense 還能叫做 common sense 嗎? 到底他們觀點上邏輯的矛盾,問題是出在那裡呢?同人認為問題並不是開發者的 common sense 不存在,而是忽略了開發者應該將經驗化成一般性的通用概念。舉例來說,軟體工程領域本身就是從實務發展出來的理論,其中許多概念就是開發者必須知道的 common sense,對開發者來說是合理的知識,也是他們都知道、無須解釋或加以論證的常識。 由此可知,如果開發者缺乏一般性的通用概念,那他碰到問題就很難舉一反三,自然也就難以掌握重點,而只能依據表相來處理問題,往往使得問題變得更複雜。oofunp 的留言就很像欠缺概念思考的開發者常見的反應,一開始以自己熟悉的技術來看問題,最後才發現自己對問題的理解是錯誤的。尤其「以為抽象化是將資料庫定義抽象化」的想法,更是整個弄錯抽象化思考的意義,結果最後他還是誤解了業務規則的意思。 同人前一篇文章所提到的業務規則,並非來自技術領域上萬用的設計,而是對問題領域經過抽象化思考後,所萃取而得到可以解決業務需求的重要概念。顯然 oofunp 的誤解是以技術的角度來看待抽象化思考,才會產生嚴重的觀念混淆。事實上,抽象化思考重視的不是技術實作,而是如何從實際問題當中萃取出重要的抽象概念,以增進我們對問題領域的瞭解,才能採用最適當的技術來開發軟體系統。 此外,過份強調技術經驗而輕忽概念性思維的開發者,很容易表現出自己對問題的盲目。就像 X files 留言的批評一樣,責怪同人沒有交待清楚是 XML 格式的問題,直到別人提出質疑才說明與列出參考文獻,認為同人缺乏部落格文章寫作的 common sense。但我的文章已經很清楚地提到是有關「交易訊息」語法的問題,難道他不瞭解交易訊息是 XML 技術的一般化抽象概念表述嗎?XML 只是實現交易訊息概念的一種技術,用以解決跨系統整合的問題。如果他要看到 XML 字眼才知道是訊息格式的問題,那改天換了另一種交易訊息的實作方式,我想大概他腦筋又要轉不過來了吧。 以上網友的三種批評,表面上看起來好像是不同的問題,但其背後都存在同樣的本質,那就是從交易訊息的問題中可見一斑,他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢?

Continue reading about 訊息交易的抽象化思考

     
jim yeh on 一月 23rd, 2009

最近某位開發者和同人討論需求規格的問題,但他的反應卻讓人感到困惑,不知是他的理解能力有問題,還是面對問題太過情緒化?以下是我們對話的內容。 開發者 D 君問同人:「規格好像沒有提到欄位空白該如何處理?」 同人回答:「沒特別說明就是代表將該欄位填入空白。」 D 君說:「為什麼不是未指定欄位內容呢?」 同人說:「如果是那樣,該欄位不應該在交易訊息中出現;但如果該欄位的內容是空白,那就應該不指定訊息欄位的值。」 D 君說:「不過,從交易訊息的定義來看,那個欄位是必要欄位,不可能不出現。」 同人說:「所以那個欄位是必要的,訊息中沒有指定值就代表欄位要填入空白。」 D 君說:「那規格應該交待這個細節?」 同人說:「不需要,規格文件不寫語法而只會記載語意,因為語法是屬於 common sense,沒必要詳盡記錄在規格文件中。不然,如果連 common sense 都要寫在文件上的話,那是否意味程式設計者也不需要懂程式語言了,反正文件上都會寫。」 D 君說:「我知道了,你的意思是說我沒有 common sense!」 同人說:「如果你覺得我那裡說你沒 common sense,請明說我可以向你道歉,否則你這種情緒化的言論,只會讓人感到不舒服!」 D 君:… 同人將這件事寫在噗浪上,有噗友認為這類的開發者能力不行,沒什麼產值卻會製造問題。不過,在此事我所看到的問題倒不是開發者能力,而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通,這才是我認為最可怕的事情。

Continue reading about 開發者的 common sense

     
jim yeh on 一月 16th, 2009

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外,同人也在該篇文章內容中,發現了一些值得探討的問題,因此想在這篇文章發表我的看法。 以該篇文章內容而言,同人認為值得探討的有兩個地方,一個是程式語言一直再改變的迷思、另一個則是作者建議讀者,儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念,而第二個問題就是嚴重的偏見了,值得讓人進行思辨以建立正確的觀念。

Continue reading about 再談程式設計的迷思

     
jim yeh on 一月 9th, 2009

如果穩定的程式真的是偶然的,程式的穩定似乎只能依賴運氣而不是人為努力,事情真的是這樣嗎?其實這位噗友太過強調環境變化的隨機性,卻忽略了適應環境變化,程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的,雖然演化的過程是偶然、但其最後結果卻是必然。換句話說,穩定的程式是偶然下的必然。

Continue reading about 穩定的程式是偶然?

     
jim yeh on 十月 14th, 2008

最近寫了很多的占星文章,不知道有沒有人不習慣呀?為了擔心有些讀者無法適應,同人在此寫了一篇有關軟體開發的文章以中和主題,並用來分享我對彈性分類策略的設計心得。 許多的資料查詢,常會根據某些不同的分群觀點來將資料作分類。例如交易資料中的「產品分類」或是「單據種類」,使用者經常會希望將這些欄位當作查詢條件,讓他們可以找出相同產品分類或是單據分類的資料。 然而,實際上的查詢作業需求可能會比較複雜,也就是使用者可能會需要在一次資料查詢的結果,希望把不同資料分類,但彼此的分類之間卻同屬於相同分類群組的資料顯示在一起。我們可以新增資料分類群組的欄位,並依據資料分類來設定其分類群組的內容。這種作法在資料查詢方面的實作上非常簡便,但缺點則是要在資料的維護上額外花費一些成本。 因為這樣的設計會造成資料欄位的遞移相依,違反資料正規化的原則。當資料分類內容修改時,分類群組的內容也要跟著修正;而實際上很可能會因為程式的瑕疵或系統出現異常現象而造成資料不完整或缺乏一致性的風險。 而且,很多依據分類群組集中查詢的需求往往是在專案後期才提出來,如果開發者並不願意因此改動資料庫結構,要如何在不增加群組欄位的情況下,實作出依據分類群組集中查詢的功能呢? 答案當然是將分類群組欄位化成對應的查詢語法或群組欄位的顯示內容,這樣會讓查詢資料的實作程式變得複雜些。因為程式實作者除了必須知道資料的來源之外,尚須瞭解群組欄位與資料分類之間如何轉換。而當相同的查詢需求散布在系統各個程式之間時,就會增加程式開發的複雜度與出錯機率。尤其使用者可能會視作業方式來增加分類群組的需求,開發者應該如何運用設計的彈性,以降低程式開發沒有必要的複雜度呢? 同人在此提出一種設計手法,運用彈性分類群組策略的設計來解決以上的問題

Continue reading about 彈性分類群組策略的設計