在台灣,品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外,以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」,讓開發人員認為品質是品質部門的責任,而品質部門則認為提昇品質不是他們的責任,以為最多只能做到知道產品有問題,而不知道如何改善它們,只能退回到開發人員那邊來解決。
在〈開發者的 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 字眼才知道是訊息格式的問題,那改天換了另一種交易訊息的實作方式,我想大概他腦筋又要轉不過來了吧。 以上網友的三種批評,表面上看起來好像是不同的問題,但其背後都存在同樣的本質,那就是從交易訊息的問題中可見一斑,他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢?
元旦假期到高雄遊玩,我們搭乘高鐵到高雄,然後以高捷做為連結各個景點的主要交通工具,最後再搭乘台鐵回台北。藉著這次機會,讓同人有了第一次體驗乘坐高捷的經驗,本來對服務人員的悉心解說、與親切的服務態度,讓我對高捷有很好的印象。但可惜在最後,搭高捷到火車站卻因為服務人員的一句話,改變了我對高捷系統的服務評價
專案經理利用軟體缺陷的創造信用來進行短期信用的流通,把 bug fixing 變成 feature request 的好處就等同於創造增加軟體開發修改 bug 代價的貨幣。然而,把 feature request 變成信用商品的後遺症,正是讓信用生產結構的迂迴,使信用崩潰延遲發生。
新政府團隊似乎想要在就職典禮的活動上,改變舊制以發揮新創意,營造出耳目一新的感覺。但實際上卻反而把問題複雜化,造成一團混亂。這讓筆者想到在軟體開發過程中,也經常出現同樣的情況。改革的困難正是考驗著領導者的領導能力,他應該如何領導團隊來進行成功的改革呢?
在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。但至於要如何增進良好設計架構的產能呢?
對於開發者而言,總是要到驗收前才發現程式有問題可真是可怕的夢魘呀。然而,這樣的現象為什麼老是一而再,再而三地發生,到底是什麼地方出了問題呢?
雖然「計劃趕不上變化,變化比不上老闆一句話」,但趕不上或比不上並不代表要放棄計劃,否則專案的成功也只是聽天由命的偶然罷了。同人認為,軟體專案要成功,關鍵不在於如何照計劃進行,而是要「計劃」當計劃趕不上變化時該怎麼辦。
驗收測試與 TDD 有何不同?一個是由客戶端來驗證軟體是否符合他們的品質要求,另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地,「做 TDD,還是驗收測試?」的重點並不在測試,而是「開發者應該自己驗證程式,還是該仰賴客戶來幫你找程式缺陷?」。換言之,就是我們常聽到的一句話:品質是檢驗出來的,還是設計出來的?
本篇文章不談高鐵,而是從我所寫的〈從高鐵談大型公共建設軟體開發專案〉的上下篇的讀者迴響中,發現有一些值得探討的議題,在此做個整理。





最新迴響