jim yeh on 五月 8th, 2009

在台灣,品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外,以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」,讓開發人員認為品質是品質部門的責任,而品質部門則認為提昇品質不是他們的責任,以為最多只能做到知道產品有問題,而不知道如何改善它們,只能退回到開發人員那邊來解決。

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 一月 5th, 2009

元旦假期到高雄遊玩,我們搭乘高鐵到高雄,然後以高捷做為連結各個景點的主要交通工具,最後再搭乘台鐵回台北。藉著這次機會,讓同人有了第一次體驗乘坐高捷的經驗,本來對服務人員的悉心解說、與親切的服務態度,讓我對高捷有很好的印象。但可惜在最後,搭高捷到火車站卻因為服務人員的一句話,改變了我對高捷系統的服務評價

Continue reading about 一句話改變我對高捷的評價

     
jim yeh on 十月 23rd, 2008

專案經理利用軟體缺陷的創造信用來進行短期信用的流通,把 bug fixing 變成 feature request 的好處就等同於創造增加軟體開發修改 bug 代價的貨幣。然而,把 feature request 變成信用商品的後遺症,正是讓信用生產結構的迂迴,使信用崩潰延遲發生。

Continue reading about 軟體缺陷的信用創造

     
jim yeh on 八月 13th, 2008

新政府團隊似乎想要在就職典禮的活動上,改變舊制以發揮新創意,營造出耳目一新的感覺。但實際上卻反而把問題複雜化,造成一團混亂。這讓筆者想到在軟體開發過程中,也經常出現同樣的情況。改革的困難正是考驗著領導者的領導能力,他應該如何領導團隊來進行成功的改革呢?

Continue reading about 新官上任三把火

     
jim yeh on 三月 11th, 2008

在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。但至於要如何增進良好設計架構的產能呢?

Continue reading about 專案時間不足,如何達成不可能的任務

     
jim yeh on 二月 4th, 2008

對於開發者而言,總是要到驗收前才發現程式有問題可真是可怕的夢魘呀。然而,這樣的現象為什麼老是一而再,再而三地發生,到底是什麼地方出了問題呢?

Continue reading about 總是要到驗收前才發現程式有問題?

     
jim yeh on 十二月 11th, 2007

雖然「計劃趕不上變化,變化比不上老闆一句話」,但趕不上或比不上並不代表要放棄計劃,否則專案的成功也只是聽天由命的偶然罷了。同人認為,軟體專案要成功,關鍵不在於如何照計劃進行,而是要「計劃」當計劃趕不上變化時該怎麼辦。

Continue reading about 當軟體專案計劃趕不上變化時

     
jim yeh on 十一月 16th, 2007

驗收測試與 TDD 有何不同?一個是由客戶端來驗證軟體是否符合他們的品質要求,另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地,「做 TDD,還是驗收測試?」的重點並不在測試,而是「開發者應該自己驗證程式,還是該仰賴客戶來幫你找程式缺陷?」。換言之,就是我們常聽到的一句話:品質是檢驗出來的,還是設計出來的?

Continue reading about 品質是檢驗出來的,還是設計出來的?

     
jim yeh on 八月 11th, 2007

本篇文章不談高鐵,而是從我所寫的〈從高鐵談大型公共建設軟體開發專案〉的上下篇的讀者迴響中,發現有一些值得探討的議題,在此做個整理。

Continue reading about 大型公共建設軟體專案後續討論