Conceptual Integrity
2006 年 一月 9 日 (星期一) 11:23 pm分類：職場, 閱讀, 電腦
標籤：軟體開發論
昨晚和朋友 shane 去公館一家新開幕的麻辣火鍋店用餐。席間談論到他對微軟軟體開發流程的近距離觀察，尤其是 design proposal/review/defense meeting 等制度時，突然見他引用了 The Mythical Man-Month 書中反覆強調的 “conceptual integrity” 觀念，真是一針見血啊！除了讚歎有個直諒多聞的好朋友之外，也聯想到，這正好可以簡潔扼要地回答日前網友 James 在我〈教育訓練半年偶得〉文後所提的部份問題，可省了我不少打字的工夫，呵呵。
James 的留言提到：
第一點，能否請您稍微多敘述「第五點、抽象思考能力…」這部份，例如舉個例子，或是提供一些參考資料、書籍… 等等，提供在下參考。
大哉問！我一時無法好好整理比較抽象、自我修煉的觀點，暫時先給個較為具象、組織學習的建議吧。
我的看法是，經營一個願意在捲起袖子 coding 之前，先認真進行 design proposal/review/defense 等環節的團隊（而且得是「玩真的」），將會大大直接刺激整個團隊的抽象思考。一開始可能會抱怨部份的 management overhead，但長時間來看，這不僅是大幅降低整體 overhead 的良藥，更重要的是：在這樣的組織文化之下，個人及團隊的抽象思考專業技能（在架構、模型、patterns、演算法等層面推演論證）及溝通技能（表達、傾聽、說服、辯護、反駁、指正……）都將大幅提升，不至於陷入「現在我才發現，我只有 1 年的工作經驗，只不過重複了 20 年」的感慨。
我不否認這樣的看法，與我長年待在交大資科某實驗室的體驗有關。個人頗受惠於這種訓練，而看著一屆屆新生從剛進門的青澀，到後來思辨力成長到可直接在抽象層次進行討論；再反觀其他無法在此層次對話的工程師，就不由得深深愛上這種制度。所以我在〈教育訓練半年偶得〉該文中才會有感而發：
只可惜這種能力，如果不在無憂無慮、百花齊放、無所為而為的校園中薰習，一旦就業，到了處處講究速效的場域，往往很難再有機緣及時間去接受抽象思考的洗禮；即使萬事俱備，屆時的智力及心力，只怕早已被塵俗污損退化得心力交瘁，只欠東風。
當然啦，這種制度要能有效益，必須有一兩位資深的 mentor，不只願意扮黑臉，更要有耐心。
培養出抽象思考能力，才有可能執簡馭繁，披亂解紛，直探本源，才有可能在此分層、互連、糾葛日益繁複的時代，仍能設法維持 “conceptual integrity”。有了 conceptual integrity，才能先在「人」的層面處理好 James 所提的另一個問題：
第二點，您文章結尾部分有提到「…所有的歷程，所有的中間產物，隨時可調閱，隨時將 “traceability” 做為每一小階段的收尾要務。」請問您是利用什麼樣的方法完成的呢?
工具固然讓人事半功倍，但是如果沒有先在「人」的層面建立好觀念及態度，工具也使不上力，制度也會淪為「玩假的」。所以就讓我先鎖定在「人」的層面來聊聊吧。
Frederick P. Brooks 非常強調 “conceptual integrity”，在 The Mythical Man-Month 書末索引就可看到 13 條線索。在此僅節選部份段落。
之所以如此重視 conceptual integrity 的原因是：
- Chapter 18 4.1
“Conceptual integrity is the most important consideration in system design.”- Chapter 3 p.36
The success of the scaling-up process depends upon the fact that the conceptual integrity of each piece has been radically improved.- Chapter 18 3.6
Most experiences with really large systems show the brute-force approach to scaling up to be costly, slow, inefficient, and to produce systems that are not conceptually integrated.- Chapter 4 p.42
It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.- Chapter 18 4.7
A conceptually integrated system is faster to build and to test.
我對於上述第一句話 “Conceptual integrity is the most important consideration in system design.” 真可算是感觸良多啊。多年以來，看了這麼多本質概念醜陋、結構嚴重缺陷，一路挖東牆補西牆苟延殘喘的系統，真不禁大聲附和 Brooks 這句重話。
為了達到 conceptual integrity，他認為必須放大格局，調整心態：
- Chapter 18 4.4
“Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects.” [Small ones, too.]- Chapter 18 4.3
To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.- Chapter 18 4.5
“If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.”
上述第一句話是強調抽象思考的重要，後面幾句話則涉及團隊組織。因此，第三章以「外科手術小組」做為隱喻，談到他心目中理想的軟體開發團隊裡，應該要組成一個核心圈（你也可以稱他們為 chief architect），致力確保 conceptual integrity：
- Chapter 18 3.3
A small sharp team is best—as few minds as possible.- Chapter 18 3.4
A team of two, with one leader, is often the best use of minds.- Chapter 18 3.7
A chief-programmer, surgical-team organization offers a way to get the product integrity of few minds and the total productivity of many helpers, with radically reduced communication.
因此，資深人士組成的核心圈裡，至少會有人負責 requirement 的 conceptual integrity，有人會負責 architectural design 的 conceptual integrty，負責主導該事務的全局，做為該議題的最終仲裁者。少了專人坐鎮，很難想像系統亂度會狂飆到何等光景。
有趣的是，之前所提的 design proposal/review/defense meeting 制度，優點在此一一浮現。只要是玩真的，整個團隊成員會漸漸成熟到對於 conceptual integrity 有種內化的一體感及警覺心，那麼核心圈的擔子就可分攤一些出去，享受組織學習的效益。
用正確的方法做事，儘管有短暫的 overhead，但長期來看，收穫會更豐盛。值得！
「人」搞定了，再從環境面要求透明度，也就是我所在〈教育訓練半年偶得〉文中說的「所有的歷程，所有的中間產物，隨時可調閱」；也從制度面要求 identify → execute → review 的 cycle，「所有的歷程，所有的中間產物，隨時將 “traceability” 做為每一小階段的收尾要務」，沒有事前的 identify，沒有事後的 review，就不算結束，要求收尾。
只要觀念釐清了，心態調整了，環境及制度建立了，那麼，即使沒有好的工具協助，仍然可以用 annotation tag 搭配 scripts 去兜出一套陽春版的 traceability 管理系統。不過以 James 留言所提的情況，那又另當別論了：
敝人所任職之公司最近也正在推動 CMMI 之認證，讀完您的文章，真是有所感觸。[略]
舉例來說，追溯矩陣在 CMMI 中是很重要的，可以用來追溯需求與需求之間、需求與設計之間、需求與測試案例之間… 等等的關係、但是卻沒有一個工具能夠好好的把這件事情做好。結果，為了符合 CMMI 的要求，同仁們就很辛苦的把追溯關係用 Word 寫下來，哈! 什麼時候用呢? 方便嗎? 如何維護與更新呢? 10 個需求很好維護，50 個、100 個需求要怎麼辦呢?
如果貴公司對 CMMI 是玩真的，那麼理論上，管理階層應該早有如我前文所說「不管是在制度、教育訓練、人力配置，還是在工具上，都得投資」的心理準備，你們理應享用更具威力的工具、更充足的教育訓練、更專業的輔導顧問。像「追溯矩陣」這件事，就是很好的顧問功力考驗題。 
◤建議您一併閱讀以下文章：
著作授權方式：Creative Commons 條款。
追蹤留言回應：以 RSS 2.0 方式。
文章永久網址：
» http://william.cswiz.org/blog/archives/2006-01-09/conceptual-integrity/
引用通告 (trackback)：
» http://william.cswiz.org/blog/archives/2006-01-09/conceptual-integrity/trackback/
![[add to funP]](http://william.cswiz.org/blog/wp-content/themes/william/images/add-funp.png)
![[add to HEMiDEMi]](http://www.hemidemi.com/sticker/user/roxytom.bluecircus.net.gif)
![[add to udn bookmark]](http://bookmark.udn.com/html/help/80_20_02.gif)
本站歡迎您以合乎創用CC 的方式，將文章選錄至網路書籤或社群網站，也別忘了將您寶貴的意見（尤其是延伸的評論、補充、彙整、反駁等）留言在本站。謝謝！
2006 年 一月 11日 於 4:48 pm
記得與 EMBA 教授在談到軟體設計時，他告訴我一句話：
「對於 Design 而言，許多人都在 Concrete Design；但真正有用的 Design 是 Concept Design」
對於這句話，我深表同感。在從事軟體專案的開發過程中，資源與時程的壓力常迫使人們放棄 Conceptual Integrity。許多設計資深人員以他們的設計為自豪，但卻常讓人發現他們的設計過多的實作細節，根本不可能維持 Conceptual Integrity。
然而探究其根本問題會發現，其真正的問題是欠缺規劃的想法及對測試的迷思。系統設計人員大部分不願意放棄他們所熟悉的招式，遇到客戶所提之需求只會以自己的技術背景去 Transform，概念放在自己腦海中不會寫出來，更別奢言規劃，沒有規劃就不知如何測試，或推說沒時間測試。測試勉力為之最後卻發現開發的東西與客戶要的隔閡日深，要拉回來已很難了，所有的文件都只好玩假的，不管施行那一種 Process 或 Management 介入都是枉然。大家能想像即使導入 CMMI ML2 的組織其 SRS 卻只裝飾用的嗎？
所以，關鍵在抽象化是 Concept Design 的心法，只保留完整、足夠及重要的特性，不相關的東西一律略除，以免過度設計，使人無法運用。此即為「易則易知，簡則易從；易知則有親，易從則有功；有親則可大，有功則可久；可大賢人之德，可久賢人之業。」（周易繫辭上），好的設計令人易於理解並容易遵從，Conceptual Integrity 才有可能維持。
至於實務上如何練習呢？個人認為要多思考問題，多練習類化及隱喻的能力。即演繹（分解事物，例如人事時地物，5W2H）與歸納（關聯相關事物而整合抽象化概念）的手法交互運用，似乎沒有什麼捷徑，但見賢思齊，看多了自然而然也就慢慢學會抽象化的能力了。
2006 年 一月 11日 於 6:20 pm
設計這種事情在業界實在很難說，聽老師說故事是一套，真的做下去又是一套。
先說兩個數千萬的例子，就是你說玩真的而且請了顧問、老師（可能忘了請你）。
很大有名的精 X 資訊，他要把一個原有的程式升級，本來的程式是由我朋友一個人完成的，談不上甚麼好的架構，但是快速穩定沒出過錯。公司想要練兵，就找專人當然有傳說中的老師來幫忙設計，遵循 CMMI 出來的設計文件足足有四、五千頁，頁數和原本程式碼差不多，請大陸資源寫出來後還真的可以跑，就是慢到不行。更重要的是，User 根本不要用。
另外一個也是上市的 X 菲資訊，數年前就想做了，也是數千萬，也是台灣寫規格大陸寫程式，根本連上線都不行，因為跑不起來。
這些老闆都說很想知道 Tata Consultancy Services 是怎麼做到的。
大陸有個軟體公司，把程式設計當作業員，換工作服到電腦前，連一支筆都沒有，電腦上有今天的應辦事項、待寫程式，也不用知道 domain know-how 就是跟規格一起完成就好了。現在這公司不但賺錢而且已經有上千人了。
我公司也用 Rose，也已經花了上千萬，也請了傳說中的老師，也是玩真的。只能說沒有真正進入業界的老師根本沒有用，沒有真正被 User 罵過的人真的不能相信，我知道一個恆逸的 UML 明師就是覺得跟 User 談很麻煩，當老師比較好賺才去的。
說到好的設計，可以說 J2EE 吧。那些 tag lib, ejb 等等的真的有比較好嗎？只是把簡單東西複雜化罷了。
我比較熟前端的 Java，J2SE 中把 MVC 發揮到極致的就是 Swing 了，處處都是 pattern，都是良好的設計，設計出來很好繼承修改就是了。不過那個 Event Dispatch Thread 真的搞死人了，為甚麼會有 EDT 這東西，因為太過良好的設計需要犧牲效能，太過良好的設計很難做到面面俱到，所以搞了一個限制。我敢說市面上沒有一個 Swing 的程式是良好的，傳言中好用的都是用 Java3D 做的遊戲。現在 NetBeans 比較長進些，還是不夠水準。
每個人都想做 PM/SA（我只想當 Programmer）。我所知道的香港、新加坡沒有本科系畢業的根本不可能進入 IT 產業，台灣大都是半路出家，那些不是半路出家的本科系（我用過台大資工還有清大交大的）的人根本不想寫這些簡單的程式，到我手邊的程式根本不怎麼樣，不過因為學校，老闆很容易請他們去畫那些圖。只是沒有 domain know-how 畫的圖根本是屎一堆，最少要去看 Java Performance Tuning 吧，要用資料庫當然要知道各個參數會對程式的影響，大量資料如何運用等等，這些都是業界的經驗，那些學院知識真的不怎麼樣。
當然，我也看過你的 C++ 翻譯文件，對我當初影響很大（我可能比你大兩歲以內吧），我相信你是高手，不過我很懷疑你知道，那些沒有看到程式畫面出現就不能確認需求的 User 的想法，我想 XP 比較合用些（這敝公司也搞過，也是玩真的，也是在時程的要求下慘淡收場）。我知道有很多高手環伺，那些人都被 google, microsoft 找去了，真正需要人的是應用程式啊。
最後，一年要有數千萬的利潤是很難的，有不少公司都玩真的然後賠了一屁股，都被那些老師顧問賺走了。
2006 年 一月 11日 於 6:48 pm
同人兄和 M 兄談的範圍都很大，我先簡單挑 M 兄所講的來回應吧：
我想，這類 rapid prototyping、storyboard，甚至 XP 所講的 user story 等 requirement elicitation 技巧，與抽象思考、concept design、conceptual integrity 等議題，兩者是並行不悖的。甚至連 XP 在內的 agile 陣營，儘管在 “Manifesto for Agile Software Development” 裡宣稱 “to value working software over comprehensive documentation”，但仍然非常重視 simple、metaphor 乃至 refactoring、continuous integration 這種補救措施，莫不是為了力求 conceptual integrity。
End user 不擅抽象思考，善變，這是正常的；但 PM/SA/architect 的專長及責任，正是在此。
一方面是識人不明（哪能只憑學歷就賦予重任？名校出來的也有很混蛋的），是不是真的有料，明眼人從 modeling 去 challenge 一下就可秤出個斤兩；一方面是沒有 proposal/review/defense 制度把關（哪能天馬行空畫一畫就定案了，要別人照單全收去實作？名校出來的 paper/document generator 也不在少數呀）。如果自認 modeling 比他們好、tuning 也比他們強，何不用一點不傷感情的技巧向頭頭提案？
至於 M 最前面講的兩三個案例，以及接下來的批評：
會挑剔別人是「沒有真正被 User 罵過的人真的不能相信」，那麼，你們有當面「罵」過這些「老師」嗎？為什麼要甘於做個不麻煩老師的人，當個讓老師笑著數鈔票、直呼很好賺的人呢？
我也只能說雙方都得檢討。一方面得看看那位「沒有真正進入業界的老師」是否真能放下身段，放空一切理論，柔性如實地觀察現場；畢竟嚴格來講，沒有情境是百分之百完全相同的。另一方面也得看看動念請這些老師來的人，究竟是抱著什麼心態 ── 是迷信遠來的和尚會唸經嗎？是只想找個大師光環加持嗎？有沒有弄清楚這些老師的背景、經歷、洞見，究竟是擅長給你什麼層次的診斷及建議？是短期中期還是長期？是觀念、策略層面，還是實施細節？是改善，還是改革？有沒有弄清楚自己需要的是什麼？有沒有弄清楚自己需要的與他能給予的兩者之間差距有多少？
這些問題沒先思考清楚，實在很難說是玩真的，也別怪自己被企業巫醫騙了。對方未必存心欺騙，先問問自己有沒有騙自己。
此外，雖然不乏只會動嘴巴的「老師」，但千萬不要一竿子打翻一船人。諾貝爾物理獎得主費曼，未曾從事太空任務相關工作，卻能解開太空梭失事爆炸之謎。
2006 年 一月 12日 於 9:14 am
認同 William 提的心態問題，我認為態度是關鍵，也就是您對軟體設計的基本假設為何？
「軟體工程很多人都以為是理論，但實際上軟體工程卻是很實務的，因為它是業界所發展出來的最佳實務」
這是另一位研究軟體工程管理教授說過的話，正值此時，有一位 Data Driven Devlopemant 的信奉者質疑我的軟體工程實務，認為那只是理論（真奇怪，公司都在導入 CMMI，似乎不該質疑這個問題）。可惜的是，專案經理為了時程的壓力，只好被迫放棄工程面的堅持。當時只有我在做 SRS，SDD 及 Test Driven Devlopement，同時我的 Business Logic 已歷經三次 Refactoring。後來離開這團隊，我預期我的程式碼會被重新寫過，事後真讓我料中，當初我的設計策略是設計與實作分離，運用機制增加軟體的彈性及重用性，但那位信奉者不願了解也不願與我討論，而且認為他一切沒問題。
問題出在哪？是出在人而非出在事，人的偏見導因在心態，當您以為軟工流程或方法論是理論（的假設）時，同時您不願意深入去了解（把假設視作結論），當別人推行失敗時就把會說：「你看，我說的沒錯吧，這是行不通的！」
很多時候，我們都容易被「您不知道您所不知道的事情」所迷惑，以致造成一種限制。如果一個團隊沒有辦法運用探索的態度，去識別，去了解我們的問題在哪裡？形成了什麼概念？該如何作？背後的原理為何？（3K1C, Care what/Know what/Know how/Know why）那問題總是無法解決的，其實不是技能不夠，而是沒有運用系統性思考來觀大局。
例如，技術人員如果只考慮技術的問題，如何解決業務上的問題？不了解業務上的問題，您如何抽象化思考？無法抽象化思考，您如何讓您寫的程式可以具備彈性與重用性？管理及業務人員其實也是有同樣的類似問題。
我的結論是軟體開發要注重問題的分析（乾以易知，君子以自強不息），從問題定義，資訊收集，形成假設，找出限制，專業分工到風險控管；及團隊的發展（坤以簡能，君子以厚德載物），從順應趨勢，重視紀律，盡其職分，謹慎行事，謙虛態度到勇於變革。兩者缺一不可，但現在大多人都比較重視前者（賢人之德），但後者其實是成敗的關鍵（賢人之業）。
供參考。
2006 年 一月 12日 於 4:02 pm
我是當面罵過老師的人，那人還是名師，結果是被大家瞧不起，因為大家是來學東西的，不是聽我罵人的。
「軟體工程很多人都以為是理論，但實際上軟體工程卻是很實務的，因為它是業界所發展出來的最佳實務」
看到我寫的就知道，我是信奉那些都是理論為多的人。
我也認識很強的教授，讓我對書本教授徹底改觀，只怪我唸書的時候沒有好好選，誤解了眾多強人教授。我念台大。我也知道本科系也是有好的有壞的，只是名校的本科系有種自己都會的迷思。
在實做 framework 的時候，我們可以很容易的把整個流程放進去，完全正確的設計。在作產品的時候也可以。但是作客戶端我們俗稱 customized 的專案就沒辦法。要知道公司以賺錢為目的，沒有專案甚麼都別談，而業界的價格殺到如此低，甚至於我的一個專案，來就說最多六個月，再來談錢。POC 後最低價得標。
軟體工程我認為應該像真的建築工程，每個程式元件都是螺絲釘，要知道建築工程有多少螺絲釘的規格，也是為甚麼 Tata 可以這樣的低價競標，因為他已經有成千上萬的元件，而一般人沒有。
我們也想玩真的，我們也玩真的（都是因為 Tata）。但是總是因為時程的壓力。我曾經接過一個 IBM 的失敗專案，專案時間已經到了（一年），還都只是設計的文件，那些文件印出來嚇死人的的多，完全遵照 RUP 的流程，系統還在 prototype，就是又慢又跑不動。我接手後完全不理之前的設計，見招拆招只用了半年多就上了第一階段，當然我也設計，只是我用的是不停的 Refactoring 程式，用程式設計程式，一年半後還加了許多系統，現在系統還在跑。
我看過太多失敗的例子。問題真的出在人嗎？就像 同人 的設計真的做完了後，難道不會重蹈 IBM 的覆轍嗎？PM 有專案壓力，公司要賺錢啊。我身邊和我知道的只要作 customized 專案的很少看過設計實作徹底分離還能成功的；極少數成功的都是一人團隊，自己設計自己 coding，要知道我的專案 20 個人是基本數目，這還不包括測試的人。當然也許我見識淺薄，所以總是聽到半吊子沒有真的做出專案的說軟工多好的（完全沒有說 同人 沒有做出專案的意思）。
公司要賺錢，我遇到的公司也肯花大錢去用，去玩真的，總是悲慘的多成功的少（framework, product 與一人專案除外）。
「你看，我說的沒錯吧，這是行不通的！」
我也很不想說，事實上我沒有對外這樣說過，但是心中常常這樣想。
我很看重 William 的，我還是想玩真的，因為只有這條路才能把程式當元件，讓公司像 Tata 一樣增長，讓寫程式的當作業員。就像業界很需要 reference case 一樣，我還在尋找。
還是應該到 Tata 當間諜好了。
2006 年 一月 12日 於 9:40 pm
M 洋洋灑灑寫這麼多，若不認真回應，未免有點對不起。不過我個人並不太喜歡投入客製化類型的專案，只喜歡近距離旁觀或協助，所以個人的思考可能會有盲點及偏頗。先對這一點做個聲明及預告。
以台灣這種客製化專案的劣質環境而言，我知道大家都過得很辛苦，PCTS 四要素常被壓得死死的，因此，在趕工結案之前，陳義過高是沒有用的，也不忍苛責。不過，在對外部客戶結案之後，是否願意花點時間做個「內部結案」的收尾動作？
如果在外部結案之後，不投資些心力去檢視檢討：refactoring、元件化、模板化、automated generator 化、文件化，將深埋在腦袋裡及散落在程式碼當中的內隱知識轉化為結構化的外顯知識，那麼，核心永遠是不成熟、不豐富、不完整、散亂、脆弱、隱晦的叢集，那麼，永遠是在賺辛苦錢。更嚴重的是，即使做了 20 個專案，組織和個人的內在成熟度恐怕也只相當於做了 1.2 個專案，難以 leverage 過往經驗。
而且，人是會流動的。
我很慶幸與我合作的某公司，本身有相當強的 chief architect 傳統，也很重視事後的種種內部結案動作。
M 想看看一些 reference case，那麼，SAP 的發跡經驗很值得參考。
2006 年 一月 15日 於 5:41 am
我們公司在辛苦的專案結束後，都會花時間去檢討這些程式，在重整後去做到元件、模組化，可是如果沒有專案的磨練，怎麼知道重新組合的程式是不是真的沒有 bugs？
在我的專案（不在台灣）的經驗，只要牽扯到的部份都要全部重新測試，以程式的觀點來說模組化的東西應該沒動到就是沒問題，就算 unit test 做的多好，可是 user 還是不相信，必定要把所有的東西都重新跑過一次，還真的二十次會出一次錯，大約是 5% 的機會吧。
所以我們的問題是重組後的程式沒有經過大量的測試後沒人敢用，又沒有錢作這種事情。
人是會流動的沒錯，就如同上面寫的，你們這些高手都不願意投入客製化專案，讓我這種猴子當山大王好嗎？
我遇過一個高手（又是國外的），做了快三十年（也只有國外能給這種人作三十年，而且地位、薪水很高卻還會 coding），所有專案都要經過他審核，他就說過，你的所有東西沒有寫下來都不算是真的，用講的我也可以講出個大系統，必須把所有預見的問題都要文件化下來，而不是請些人在那邊說說解決方案就好了。我還是強烈建議高手們不要只是近距離旁觀或協助，投入真的第一線的專案來吧。
你們這些高手每天都要『設計』新的技術名詞，還讓老闆們知道，我們作專案的就要緊追不捨，我們好不容易模組化的東西，過了一年就不能完整套用新的技術架構，客戶就要新的（雖然一點都沒有比較好），別說 OO, Component base, Web Service, ESB 一路下來的 Server 端技術，光 J2SE 的 GUI 我們由 AWT (use JBuilder component, better than swing), swing 1.1, 1.2, 1.3, 1.4 每一版都加了新的元件，但是有不同的問題，客戶一定要解決問題，所以我們只能大幅度的修正，只是下一版的 jdk 會解決問題後帶來其他的問題（舉例 1.3 之前需要攔截 tab 鍵來操作 focus 的轉換，1.4 為了解決 focus 的問題，重寫了 focus 的架構，但是竟然取消了元件上 tab 鍵的 event，只能由 AWT 那層的全域 event 來攔截），這是永無止境的循環。
為了台灣，別說以台灣這種客製化專案的劣質環境而言這種話了，那大家都去寫 framework 好了。你知道 TCS 最近在台灣電信、金融業只要出手就所向無敵嗎 (前天和一個印度人聊天，他們不叫 Tata，叫 TCS，叫 Tata 是我的錯。那印度人還說十年前 TCS 來邀他的時候當初沒加入真是錯了)，他們也是一樣的客製化專案，還用比較低的報價，不過應該沒賺才是。
我想 SAP 雖然賺錢，不過我的客戶用的人都是罵的多，而且他的設定複雜度和寫新程式比起來不遑多讓，等於是學了一種新的程式語言，一點都沒有比較輕鬆。你能知道有甚麼台灣的 reference case 嗎，我想要的是 TCS 而不要 SAP 這種因為歷史因素而成功的公司，有走客製化專案的老實說我是不看好 SAP 啦，我寧願傾向 Oracle；至於 IBM 經過教訓後已經全面退出最後端一哩程式的市場，他只做 middle ware，雖然台灣還是有上百人的團隊，不過當 PM 的多，苦工還是給 ISV 來做。
2006 年 一月 15日 於 9:33 am
先針對職場選擇這點回應。
你提到「為了台灣，別說以台灣這種客製化專案的劣質環境而言這種話了」，我想，我發出的「劣質環境」之嘆是陳述事實，我不必為此道歉或感到抱歉，也不必非得自命不凡背著「與其詛咒黑暗，不如點亮光明」的十字架 ── 許多人都在抱怨政治黑暗，卻不可率爾指責這些人為何不去從政、從體制內改革；這不是單憑熱血就能成事的。
人各有志，每個人都有他認為自己最能發揮、最有貢獻，又能兼顧完整人生面向的位置。以我個人而言，我比較喜歡 80-20 法則當中的 80 槓桿部份，也自認在這個位置最能兼顧貢獻人群、自我實現及生活品質。
這無關對錯，純粹是個人的選擇、個人層次的比較利益法則罷了。我們能做的，就是認清自己的戰場，並且尊敬、祝福別人的選擇。
晚一點再另起一文摘錄劉必榮於《三頂帽子哲學》所提的觀點，這也是我私淑的路。
至於其他關於專案方面的討論，我發現其實你本來就知道正確的做法應該是如何如何，像審核、文件化、檢討、重整、元件化、單元測試、緊接在 refactoring 之後的迴歸測試云云（我好像在浪費時間重複大家都知道的常識），只是囿於現實面做了妥協。但是做了任何妥協的決定，都該清楚知道：這個「收尾」並沒有真正的收乾淨，也該預知後果是什麼（其實不必我多嘴，你也知道後果是什麼），也該預知自己能否承擔這種後果（引一句林耀珍的經驗之談：「抄捷徑，總會看到代價，只是或遲或早罷了。」）。如果在一定期間之內能夠承擔，that’s fine, go ahead；如果不能承擔，那就得正視之前抄捷徑的弊病，得忍受亡羊補牢帶來的短期陣痛。
就像在學生時代，書唸不完時，我們都會考前猜題、找考古題，賭一賭老師的出題方向；答是非選擇題時，若倒扣風險不高，我們也會碰碰運氣，憑直覺或憑機率分布去猜答案。這些都不必羞於啟齒；但重點是：即使一時僥倖過關了，事後仍得認真檢討補救學習上的漏洞，否則遲早得承擔根基不穩的後果。
現實沒有完美，本來就是一連串的選擇與 trade-off。最怕的是不知道取了什麼、捨了什麼，又為什麼取此捨彼。
有些事情很殘酷，沒有做到一定的地步，沒有超過一定的門檻，效益是出不來的，流於做白工。管理者也必須瞭解：delayed feedback 現象，遍佈整個婆娑世界；「患難生忍耐，忍耐生老練」，或許正是這個世界的原罪吧。
而且我也開始懷疑，我並沒真正實地全盤了解貴公司的狀況，僅憑你逐次留下的片斷陳述就大肆議論，豈不又是另一個企業巫醫？不如從事比口舌之辯更有意義的事。
2006 年 一月 15日 於 9:22 pm
在替前一篇文章寫留言時，寫著寫著，腦中一直縈繞著劉必榮在《三頂帽子哲學》書中所自剖的職場選擇思路。對於這私淑的路線，似乎摘錄於此，不僅可以澄清一些看法，也可自我勉勵及警惕。 [...]
2006 年 一月 15日 於 10:44 pm
一串看下來，有點迷失掉了，說真的我對那些縮寫字都不太熟。
我只想問兩件小事。
1. 各位真的覺得軟體能當製造業看待嗎？
2. 然後，不管是不是名校本系，如果沒人教過怎麼用版本管理、單元測試、事項追蹤之類的工具，有多少學生會自己去學，而且還很熟練？要是上面這些東西用都沒用過，設計與規劃要怎麼驗收？
2006 年 一月 15日 於 11:44 pm
b6s:
第一個問題，請恕我抓不出你提這問題的脈絡為何，是從哪一段文字、那一則留言回應所引申出來的。
第二個問題，某些老師的軟體工程課程會出這類作業，某些實驗室會有內規制度及系統建置，有資深學長提點，有自發的讀書會及新知分享風氣，甚至私底下就承接了許多委外專案、競賽，參與 open source 社群，都不乏這類視野。熟練二字或許不敢說，但至少知道該怎麼用，至少夠用。
如果在校沒有機緣，私下又沒體認重要性，又欠缺群體學習的激盪，就只能去職場接受做中學的震撼教育了 ── 如果這家公司也重視這些。
很抱歉，沒有正面回答你所問的「如果沒人教過怎麼用版本管理、單元測試、事項追蹤之類的工具，有多少學生會自己去學，而且還很熟練？」，畢竟國內似乎沒有這方面的調查研究。不過，以我有限的抽樣推測，實際數據應該很悲觀。
這是很好的資訊教育研究題材。有人有興趣嗎？
2006 年 一月 16日 於 12:26 am
這次不要寫太多了。
軟體工程的目標，也是 CMMI 的目標就是工程兩個字，比較是把軟體業當營造業（製造業也可）。當然這可能又要寫很多了。
我已經是山大王的猴子，所以那些工具都是我自己利用『下班時間』測試為主，然後用到公司上請大家使用。我的老師只有網路，可能是那些名師總是令我傷心。
我每天要花數個小時看新的趨勢文章，有時間也會作測試（大多數是沒時間啦），我相信有『很多人』比如說來這裡留言的人都這樣。可悲的是我公司的人（尤其是那些 1977 以後的），上班時間以 MSN 為多，留下來加班才認真做事，想是因為 MSN 上面沒有人了。我則是利用下班後寫這些雜文。
2006 年 一月 16日 於 12:06 pm
問題當然不只出在人上面，只是人的因素是最難處理的，只要先把人弄對了，剩下的問題就簡單多了。
M 君在軟體開發中很有經驗，可能認為所謂的專家或學者說的只是理論，實務上運用是有問題的。我可以理解這一點，事實上我所接觸的專家及顧問，動手做的很少（不是沒有），真實世界比他們說的還要複雜；但在此我只想提醒 M 君一件事，專家學者只能教我們原理及原則，與實務的結合是我們的責任。但我卻看到許多人因為主觀抗拒而無法相互整合，因此失敗並不是因為原理原則不適用，也不是實做的技術問題，而是雙方整合的問題（也就是說務虛與務實無法有效整合）。
所以軟體專案的成功關鍵並不在於有沒有良好的開發製程，而是在於開發團隊是否能充分合作及有效溝通，如果大家各作各的，而且沒有事前規劃，過程中按規劃確實執行，事後檢討改進的話，（第一次的）成功將會變成偶然，（往後的）失敗將成為必然。所以良好的軟體開發流程必須要先建立優秀的團隊為基礎，這點可以從 CMMI 的階段模式可看出一個端倪（ML2 for Project Management，ML3 for Engineer Management）。
再來討論客製化專案的問題。個人倒是認為，愈是客製化的專案，更要專精於設計，只不過複雜系統的設計策略要對多變的環境要有所適應。過去大量生產的方法是由開發者決定使用者的需求，但大量客製化後是否還要用同樣方法來開發軟體？答案呼之欲出，延緩策略 (Postponement Strategy，DFx，Design for xxx）是很重要的概念，設計減震點，讓需求改變時才開始實作，這就是設計與實作分開的基本精神。總之，產品製程（設計）模組化及客製服務（實作）差異化是客製專案的兩大重要概念。
模組化的設計需要同步工程（CE，Concurrent Engineer），差異化則需要有效地整合。過去我們習慣把工作以功能性切割的方式，在一個缺乏溝通的組織容易造成資源及時程的浪費及重製的風險，所以將工作換成任務分組的方式，可以達到同步工程的及早整合的概念，而且在過程中會獲得許多寶貴的經驗及教訓，同時也建立起團隊的紀律（心法及約規），就像 William 所提的專案收尾動作是 Project Communication Management 非常重要的 Process。當團隊形成了開發軟體的良好紀律（坤六二，直方大，不習無不利。文言曰：敬以直內，義以方外，敬義立而德不孤），執行像 UP 這種大型的 Process 也是沒有問題的。
2006 年 一月 16日 於 2:52 pm
回應 各位真的覺得軟體能當製造業看待嗎
請參考
http://tekmonkey.org/articles.php?page=Software_Engineering,_Not_Computer_Science
2006 年 一月 16日 於 3:26 pm
William:
我的第一個問題和 M 的說法相近：「軟體工程的目標，也是 CMMI 的目標就是工程兩個字，比較是把軟體業當營造業（製造業也可）。」
可說真的，總覺得這樣的看法就是痛苦的根源 :p
至於工具與教育的問題，我就是那個「某些老師的軟體工程課程會出這類作業，某些實驗室會有內規制度及系統建置，有資深學長提點，有自發的讀書會及新知分享風氣，甚至私底下就承接了許多委外專案、競賽，參與 open source 社群，都不乏這類視野。熟練二字或許不敢說，但至少知道該怎麼用，至少夠用。」
現在回想起來，要是沒有這些機會，還真讓人感到害怕。然而，如果從頭到尾都沒有一個環境會明確地提供這種訓練，我會更害怕「不教而殺謂之虐」。
正因為「沒有不 X 的系統，只有不 Y 的人」，只好想辦法弄出一個「犯錯也沒關係」的體制。嗯，最著名的例子就叫作「官僚」:p
2006 年 一月 16日 於 4:14 pm
http://blog.linux.org.tw/~jserv/archives/001435.html 提到的 http://blog.csdn.net/ai92/archive/2005/11/23/535430.aspx 還蠻有參考價值的。
2006 年 一月 16日 於 5:10 pm
每個專案都會包含三大領域，即專案管理領域、工程領域及一般管理領域 (詳見 PMBOK)，專案執行的過程需要與工程領域相互配合，使專案執行過程的任何活動及作業都是可規劃且可預期的，因為站在管理的角度「可操作」是最基本的要求，即使在軟體專案中，軟體有易變及抽象的特質，但還是必須落實工程概念，事前必須規劃，並且依計劃執行，並且監控工程的成果於必要時提出矯正措施。如果沒有工程手法，那不叫專案，因為對於專案的目標（規模，時程，成本及品質）根本無法預期，更不用提管理！一個無法管理的專案是不會有人投資的。一個專案的先決條件是必須要有可管理的目標，所以沒有工程上的規劃根本就不能稱為專案。
雖然軟體專案是服務業的成份高過製造業，但那並不代表不能用工程規劃來看待它。當您愈了解專案您就能把專案規劃得更好，有時候不是工程的問題，工程是強調把事情做對的學問，但如果缺少了專案管理的做出對的事情，縱有工程領域的高手，仍舊是英雄無用武之地。
所以痛苦的來源並不一定是來至於工程，有時候是因為來自於對專案問題的誤解及不清楚。專案失敗的主因主要有二，一是正確解答錯誤的問題；另一是錯誤解答正確的問題，原因不同但結論都是失敗，所以工程雖然重要，但不可徧廢任一方，為什麼溝通很重要，因為它讓我們有效整合工程與管理，讓我們了解如何問對問題也答對解答。
2006 年 一月 16日 於 5:54 pm
M:
感謝您提供的資訊，我相信那也回答了我的第二個問題。
2006 年 一月 17日 於 8:40 am
再提出一些補充，M 君大概是認為如 UP 的 Software Devlopement Process 在台灣是行不通的，但有沒有成功的例子？有的，我的一位朋友，他們公司只作軟體代工，他們就推行 RUP 推得很成功，並常喊出「好的軟體來自於軟體工程」。那像 M 君所提的類似的 XP 開發方法有沒有失敗的例子呢？也是有的，我曾與某位朋友在兩家公司共事（資訊業很小的），他是典型的 XP 信奉者，並常落實 Pair Programming 及 Test Driven Development 等活動，他所帶的團隊能力不錯，也確實提昇了一些對軟體開發有興趣但經驗不多的生手。但最後他並沒有成功，為什麼？因為，他的團隊自成一派，無法融入組織文化，團隊目標沒辦法符合公司的目標。
我並不想在此爭論 XP 或 UP 誰優誰劣，事實上，個人也很喜歡 XP 的精神；我只是想強調軟體開發流程沒有誰優誰劣的問題，只有合適與否的問題。如果一個專案沒有一個好團隊，並且其目標是以符合組織的策略目標，任何開發流程都是不可能成功的。也就是先以人員導向再求流程導向才有意義，這其實就是軟體專案的 80/20 原理。
2006 年 一月 21日 於 5:50 pm
解決問題的哲學…
看完 Conceptual Integrity 一連串的討論之後，不知怎麼地讓我想起《孔子家語》卷第四、六本第十五裡頭著名的那一段：
子夏問於孔子曰：「顏回之為人奚若？」子曰：「回之信賢於丘。」…
2006 年 一月 24日 於 1:38 am
[...] Porting 當然是要按照原本 function 的 behavior 改寫，按照原本程式的介面邏輯，在目標平台找尋對應 API 完整重寫。這當然是「正確」的事，可惜卻是屬於「政治不正確」的一種。Conceptual Integrity 在某些目標導向的情境下，常常是可以被犧牲的一項。以結果論英雄以證明抄捷徑才是正確的，我可以預見未來必定沒有機會補洞，但我沒有權力反對。 [...]
2007 年 一月 10日 於 3:14 pm
奇怪，不知為何這篇無法 pingback。
[...] 即使在〈Conceptual Integrity〉的討論中，有些網友認為把工程帶入軟體開發是把軟體業當成製造業是痛苦的根源，但這和組織所採用的軟體品質文化模式（曾昭屏譯，2006）有關：如果軟體專案所要解決的問題採用變化無常的開發模式，已經無法勝任時，我們是否要改變開發模式，即使照章行事的開發模式中常衍生出很多的管理問題，然而它卻可以讓我們更明白如何把穩軟體開發的方向。軟體專案的成功，其實管理與技術層次的有效整合啊！
2007 年 二月 7日 於 5:49 pm
[...] 姑且不論設計要不要與實作分開，也不要討論相依注入是不是好方法。針對真實問題來設計，在軟體開發的實際作法就是針對問題來設計界面，然後依界面來找尋適當的技術解決方案來實現。界面是一種規格，依據規格來實現技術方案，這樣才能使設計與實作達到均衡，而不會使軟體開發太抽象而無用或太僵化而無當，同時關注軟體開發的虛實之道。 [...]