Posted by: jim yeh in 品質文化, 問題解決, 寫作, 專案管理, 思考, 生活感觸, 職場, 設計原則, 軟體審查, 開發流程, 領導
在 1/9 在新竹舉辦的敏捷開發方法分享會，當同人分享到 XP Refactoring 實務的經驗時，台下有一位聽者剛好也是我目前的同事提出一個問題：該由誰來決定何時應該重構的問題。同人當時回應重構多半發生在軟體架構的設計上，一般開發應用程式的程式員通常比較不太會有機會重構。在專案每天早會上，團隊各個成員會報告他們目前進行的工作狀態，當同人發現他們遇到架構面上的問題，我便會著手進行架構的重構以避免系統發生疊床架屋的現象。
同事好奇重構的決定是否有客觀的標準，同人表示這部分多半還是個人主觀的經驗居多。在同事後來開車載我回台北的路上，我們再次談到決定重構的時機。同事覺得重構的時機似乎不是一件容易掌握的事，同人進一步地解釋，當時我們在應用程式的開發沒有太多重構的機會最主要的原因，是因為在架構上力求簡潔而單純的設計概念，使得應用程式的開發已經變得很簡單，實在不太需要運用重構用來增加設計的彈性。
趁這個機會，同人向同事強調架構的彈性不應該以需求不得改變為前提，而是要能夠因應「有限度」的變化而發展而不斷地調整及演進。也就是好的架構並非從恒久不變的核心來出發，而是要先去識別出問題的輪廓才找得到適用的核心。同人經常在軟體開發的實務中看到，人們花費了太多的心力來堅持不變的核心，到最後才會發現原來問題是出在自己對問題假設錯誤。
那麼，在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。 Read the rest of this entry »
MaoYang 兄看到我分享〈技術經理的教練角色〉之後，他在噗浪河道上回應他對我文章觀點的看法。他說：
我常在做的 『教練』 工作大部分是在講一些基礎的東西與衍生的技術, 但是倒沒有想過要將團隊變成 『一致性』 , 試想, 你身為經理確發現實作的工程師缺乏某些觀念時, 你不得不著急,但是這種狀況出來的時候, 產品也開始出現許多問題, 這是技術經理面臨最大的挑戰。但是當技術經理開始當 『教練』 已經離開工程師角色一段時間, 這又是另一個挑戰
同人很高興 MaoYang 能夠針對這個主題提出討論。對於他所提到的問題，我常看到的是技術經理不能因材施教，所以究竟來看也是身為教練本身指導的彈性不足，也是多樣性的問題，尤其在軟體開發專案更為常見。
而且有時候工程師不是不懂那些概念，而是他們碰到一些技術經理不重視或忽略的問題，但如果沒辦法幫他們解決那些問題，如何讓他們接受那些觀念。教練就只會流於說教的自說自話。 Read the rest of this entry »
石頭成在〈與 metavige 和 alexchen 對話 Java 語言〉這篇文章中，直言他對 Java 語言泛型的批評：
我不認為 Java 讓我們「慢工出細活」，我覺得它帶來的是「冗餘的複雜性」。就算以 C++ 的觀點來看 Java 程式碼，我仍覺得 Java 程式碼有許多不必要的複雜度。Java 把類別變成施加在程序員身上的束縛，而是不是幫助我們進行抽象化資料處理的工具。
我個人認為，所謂「更強化的靜態型態」是跟 C++ 樣板相比， Java 泛型比起 C++ 樣板是在走回頭路。就我到目前為止的 Java 使用經驗來看，我幾乎以為泛型只是 Java 專門用來重新設計容器類別的特殊語法。在那以外的場所，你大概不會想用泛型來重構你的程式碼。
metavige 就說會想用 Strategy Pattern 來重構我在〈從 C++ Template 到 Java Generic，一步一步來〉舉的例子，而不會用泛型。但是泛型難道不是用來處理這個問題的直覺想法嗎？ Java 沒有足夠理由說服我們不要用泛型來做，但是用泛型來做… 呃，似乎更困難。
石頭成用泛型來重構程式碼，是不是處理他的問題之直覺想法？我想石頭成比較偏好動態型態語言的自由，比較不欣賞「更強化的靜態型態」的做法。或許是因為 C++ 用 template 實作不會受到參數型別類型的限制，自然會讓他比較想用泛型來重構程式，以去除資料型態與演算邏輯的相依性。然而，看過石頭成所舉的實例，同人認為用泛型來實作的想法未必是直覺的做法。
表面上看起來好像實作泛型可以讓某一段程式碼重複使用，但 Java 在泛型的限制，也增加他重構程式碼的困難度與複雜度。這麼說來，假如石頭成的想法是正確的，用 Java 的泛型來重構程式碼，只會讓程式員沒事自討苦吃。然而，同人在仔細研究他的程式碼之後，發現可以用更簡潔的方式來使用 Java 的泛型。不過，還是讓我們先來看看石頭成的程式碼： Read the rest of this entry »
世界愈複雜，我們就更需要簡單。簡單讓我們看清楚事物的脈絡，掌握重點，以協助做出選擇，並在適當時機採取行動。然而，簡單其實是困難的，因為要做到簡單，意味著我們必須清楚事物的全貎，行動必須要更有原則。尤其是在複雜多變的環境當中，簡單不能只靠直覺，而是有紀律的思考與行動。
那麼，用有紀律的思考與行動，以做到簡單，我們該怎麼做呢？前一陣子，同人閱讀了《越簡單越有力量》，我覺得這本書的觀念與方法，剛好可以提供我們複雜世界簡單之道的思考方向與指引。 Read the rest of this entry »
朋友在 MSN 上問我用 vb.net 和 c++ 開發程式有沒有很大的不同，因為她的主管要她加入一個使用 vc++ 開發系統的專案。她很怕接下這個任務會很難上手，但主管告訴他用不同的程式語言，只是工具的差異而已，她只需要依主管給的程式範例照著做就沒有問題。朋友不大相信主管的說法，於是想聽聽我的意見。
同人直覺感到不妥，並非因為朋友並不諳 c/c++ 這種程式語言，加上它與 vb 之間，存在根本的程式語言差異。我認為比較嚴重的問題還是溝通過程出現不精確的語言，這代表她們公司的品質文化，對解決專案的問題是沒有效果的。
學習 c++ 當然並不輕鬆，尤其如果沒有 c 語言基礎的話，學起來更是會格外吃力。因為 c++ 語言特性與 vb 的差異很大。比如 c/c++ 特有的指標，就很容易讓初學者混淆，如果觀念不清楚，常會讓程式產生記憶體衝突甚至是當在不明所以的地方。但程式語言或是程式設計的技術，這些都還可以藉由學習成長，對於積極進取、追求自我成長的開發者而言，這些並非是大問題。
誠如我在 facebook 的好友，也是以前在點空間聚會有一面之緣的仁傑兄，看到我對這件事情的分享，他建議：
If you want to encourage her, you can said that. Let her have a confidence to do it.But you have to keep coaching, monitoring and reviewing her codes.
然而，這件事情我覺得讓人擔心的並不是朋友的能力夠不夠。我注意到的是她們公司的品質文化，品質文化的問題並不在技術，它多半不會是專案成敗的關鍵，而是專案管理者的態度。 Read the rest of this entry »
本周一同人在新公司 on board，公司事先訂好餐廳為我舉行迎新聚餐。在這場聚餐當中的一道菜，讓大家開啟談論品質流程的話題。 Read the rest of this entry »
在〈開發者的 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 字眼才知道是訊息格式的問題，那改天換了另一種交易訊息的實作方式，我想大概他腦筋又要轉不過來了吧。
以上網友的三種批評，表面上看起來好像是不同的問題，但其背後都存在同樣的本質，那就是從交易訊息的問題中可見一斑，他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢？ Read the rest of this entry »
元旦假期到高雄遊玩，我們搭乘高鐵到高雄，然後以高捷做為連結各個景點的主要交通工具，最後再搭乘台鐵回台北。藉著這次機會，讓同人有了第一次體驗乘坐高捷的經驗，本來對服務人員的悉心解說、與親切的服務態度，讓我對高捷有很好的印象。但可惜在最後，搭高捷到火車站卻因為服務人員的一句話，改變了我對高捷系統的服務評價 Read the rest of this entry »
喲哪桑學長最近寫了一個有趣的故事，並在故事的後面問讀者「Feature Request, Or Bug Fixing?」這個故事引發了許多人進行廣泛的討論。
有人站在專案經理的角度來與故事中的 M 持相同的看法，只要加強 Error handling 改掉 bug 就夠了，不需要再多花工夫來回應 feature reguest。但也有人站在工程師的角度主張支持故事中 Q 的想法，解決問題本來就是 bug fixing，而修改問題所採用的做法只是 work around，而不是故事中 M 所說的這是 feature request。
不過同人覺得這個開放式的案例討論最有趣的部分，倒不是誰的看法才是正確的討論，而是看到 scarfman 「開版圖就已經說明了，bug 穿上衣服就變成 feature 啦！」的回答，這促使同人進一步地思考到一個新觀點；也就是軟體缺陷的信用創造。 Read the rest of this entry »
本篇文章是投稿 ZDNet 的文章原稿，並以〈新官上任三把火〉與〈新官上任三把火(下): 建立團隊的創新文化〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。
新政府能否為台灣開創新局還有待觀察。但從馬蕭辦公室與府院籌辦五二○就職典禮，卻出現許多的問題，加上當天的慶典南北奔波，被稱為有史來最複雜的就職典禮看來；新政府團隊似乎想要在就職典禮的活動上，改變舊制以發揮新創意，營造出耳目一新的感覺。但實際上卻反而把問題複雜化，造成一團混亂。這讓筆者想到在軟體開發過程中，也經常出現同樣的情況。
許多主導專案改變的領導者總是新官上任三把火，認為專案應該要進行改變以展現出自己的決心與魄力，因此要求團隊改變開發流程。然而，專案時間與資源的限制多半很難讓團隊有足夠的時間來調適或熟悉改變後的開發流程，結果總是令專案團隊倍感艱辛。
改革的困難正是考驗著領導者的領導能力，他更需要懂得如何讓團隊發揮創意與執行力來實現改革的目標。領導者應該如何領導團隊來進行成功的改革呢？筆者認為從領導者的價值觀、流程方法的改變、以及團隊的創新文化這三方面來看，我們可以從中體會到專案成功改變的箇中三昧，以助於掌握改革重點，有效地組織資源來幫助團隊實現改革目標。 Read the rest of this entry »
