老闆只要軟體上線前要有另一位QA人員QQQ~~

最近被問到這樣一個案例:

因應系統穩定性, 不要有臭蟲的出現, 老闆要求系統上線前一定要有另一員工把關QA, 但是這位把關的QA人員根本不知到完整詳細的規格, 造成大家的困擾, 緊張.

我想這是老闆的本能, 老闆本來就這專門下這種指示, 細節就要看看下面的人怎樣制定與實作了, 至少老闆已經清楚的表達他要做到的事, 細節的部份當然要有員工去想.

問題的解法很簡單, 我們必須先將遊戲規則制定出來, 與老闆確認一下, 然後去執行即可. 但我想有幾個點一定要說說清楚.

1. 初次上線的軟體系統是不大可能保證沒有臭蟲的.  (如果要硬ㄠ可以做得到, 我也承認是可以做得到, 但這是一個具風險及成本問題.  以及不能說的秘密), 

2. 身為開發者可以做的是什麼? 要減少臭蟲的產生, 以其避面臭蟲的再現. 這是很重要的, 如果可以做到這兩點我想已經很了不起了.

3. 要有所本, 有所依據, QA要怎樣把關, 不是讓 QA 人員以自由心証的方式去做這件事就可以的, 但是不可缺少的. 就好比 微軟的軟體測試方法中所說的一樣. 除了要有明確的說明要測試哪些, 還要加上一些經驗法則.

一個系統可以沒有Owner嗎?

一個系統可以沒有Owner嗎?

系統大又多, 一個團隊有七個人的組織, 卻想要所有的人都要懂所有的系統細節, 這到底是好事還是痴人說夢話.

以事有專精, 效率的出發點來看, 這就是不被允許的, 事實就是這樣, 但卻又不敢面對, 如果目標是這樣, 那為何每次問不同的問題, 總是會早不同的特定人來問, 這不是心裡就擺明了, 也很清楚.

所想只有一個答案, 因為不願意面對自己錯誤的決策.

如果要達到, 所有的人都可以維護所有的系統, 只有一種方式可以達到, 就是把商業營運放一旁, 以學習為重.

印象中的零用錢來自

在我的印象中, 我只有和媽媽要過一次零用錢, 隱約記得是要去買冰棒, 僅此一次.

我的零用錢都是自己賺來的, 其實究類似打零工, 像是...

1. 挖荔枝或龍眼仔. 在荔枝或龍眼大量產出價錢不好的時候, 就會有工廠的人載來一籃籃的荔枝或龍眼在一些廣場或是廟前, 要把這些荔枝或龍眼剝殼挖出裡面的仔, 然後工廠帶回去加工. 奶奶總是很喜歡帶著二姐和我一起去, 我記得一籃約有十斤, 約要發費一小時的時間才可以挖的完, 所取的報酬10元, 一天大約只可以挖6-7籃吧, 而且回家時都是腰痠的要命.

2. 撿蝸牛. 無論是好天氣或是雨天, 都可以撿蝸牛, 當雨天是比較的時機點, 雨天可以撿比較多, 只是麻煩了一點, 要穿雨衣與雨鞋. 在我的家鄉有很多人種植檳榔, 檳榔葉子是蝸牛最喜歡棲息的場所了, 必須將一片片的檳榔葉翻起來, 仔細的檢查過有沒有蝸牛. 當撿拾完畢後如果數量夠多, 就會拿到隔壁相去一個專門收集的地方賣給收集人, 如果數量不多就會暫時用家裡養雞的雞籠關起來, 怕蝸牛沒有東西吃還會去摘地瓜葉給蝸牛吃. 這些蝸牛後來我才知道其實是被食用的.

3. 摘毛豆夾. 這是最好賺的零工, 摘一斤價值四元, 一天可以輕鬆摘到200~400, 但是要很早起床, 可能是太好賺了, 大家搶著做. 我不知道這背後的運作邏輯是怎樣的, 然而我們摘毛豆夾的模式是這樣的. 前一天我們可以得知明天要到誰家的毛豆田裡摘毛豆, 一大早到了田裡後, 先將準備要摘取的毛豆收割好一堆, 然後開始摘取, 摘取沒過多久夏天的太陽就曬的我們感覺熱了起來, 有些人會戴斗笠或是帽子, 厲害的人會準備500萬的那種大傘立起來, 也許是太好賺了, 我們中午的時候幾乎不會休息, 母親會回家煮好飯帶過來給我們吃, 這樣利用一點時間飽足一頓後繼續摘取.

4. 放青蛙或釣青蛙. 這是我最喜歡的一種賺取零用錢的方式了, 因為過程充滿了熱趣, 放青蛙的方式是先準備好放青蛙的道具, 這種道具其實很簡單, 只要一個魚鉤, 魚線, 竹子這三樣即可, 當然也要有蚯蚓作為餌, 不然青蛙不會自己上鉤的, 當道具準備好後就是到水田裡, 將這陷阱插在水田裡, 等隔天再來收取這些陷阱. 此外還有一種我最喜歡的釣青蛙, 釣青蛙的工具有點像放青蛙陷阱的加大版, 也可以想像是釣竿, 但是沒有魚鉤, 而是直接綁一條蚯蚓, 重點是在要怎樣釣? 不向釣魚一樣放這等魚上鉤, 而是必須讓蚯蚓餡上下跳動, 這樣可以吸引青蛙的注意, 增加釣到青蛙的成功率, 但還有一個重點就是要有耐心, 不是當青蛙一口吃下蚯蚓餡就急著拉起來, 必須等一下子, 等青蛙將餡吃進去一點才拉起, 如果沒有就會於心喜拉起青蛙在半空中時就婉惜的看見青蛙掉下去了.

軟體專案準時達交的風險控制

最近金融風暴席捲全球, 驚嚇中對於風險控制的討論逐漸變多了.

但今天我要想的是【軟體專案的風險控制】, 記得曾經有位大師說 : 專案永遠一定是延遲的, 不可能有提早或是準時的, 不是因為能力問題, 而是因為策略或運作面的問題. 問題是這樣看的, 今天老闆給100元的成本執行專案, 可是你最後只使用了90元就完成了專案, 下一次再一個新的專案成本需要200元, 這時老闆會允許給你200元或是只給你180元, 這就是一個很玩味的問題.

其實軟體專案的風險問題, 不管是在 Software Project Management, PMBOK 裡都有詳盡的說明, 主意大約是這樣的【透過管理，正視風險，預先規劃，過程監控,  並依據重要程度處理事件】.

我想作法大約就是 : 

1. 專案進行前, 先建立一個可能面臨的風險表格, 內含風險事件名稱, 風險等級, 處理方式. 

2. 專案進行中, 隨時依表監控, 當有表徵出現時, 依循處理.

3. 再來就是看看要不要定時或偶而來一個應變演練.

4. 當然所有事請過後一定要來個撿討與改善, 以便使得風險控制可以做的更好.

哎呀, 講了這麼多, 心裡就怕了起來, 要做真的很多事, 這樣專案怎可以如期完成了?

不過重點還是要想想一個軟體專案, 到底會面臨怎樣的風險這倒是要好好思考的.

軟體專案準時達交常見風險 : 

1. 人員異動. 這件事軟體公司, 小公司, 小專案, 真的很常見, 不過就我所知, 現在個客戶也都意識到這一個問題了, 所以很早以前我就已經有被某些客戶要求將人員異動加入合約中(這一召有夠狠 : A. 人員離職就要拿更多的資源來. B. 人力不可挪移. ...等).

2. 持續性的需求變動. 不知道有沒有人沒有遇過這一個問題, 如果有到要請教怎樣做到的? 

3. 不實際時程及預算. 如果遇到這一個問題, 包袱打包一下走人吧. 軟體產業真的是一個極度競爭的產業, 常常遇到一個標案, 底價可以差到10倍. 是大家的認知有這麼大的差異嗎? 還是另有因素, 當然都是有的. 

4. 使用者的程度不好(好傷人的話, 本身沒有責任嗎). 軟體系統開發者需不需要了解產業知識, 這個問題也很熱門, 那功能做錯了, 是使用者程度不好, 沒有說清楚, 或者是開法者太過膚淺, 沒有挖掘到真正的需求, 沒有引導好使用者. 本人覺得見仁見智, 不多說.

5. 專案團隊/領導者的經驗不足(專業能力不足).  常常有出道才一兩年的程式撰寫者搖身一變就成了專案管理者, 而那些倒楣的專案就成了試煉專案, 客戶賠上的不只是一個失敗的專案, 還有位專案所投入的額外成本. 當然一個領導者, 也不是這麼容易的.

6. 時程安排過於樂觀.

7. 軟體的可靠度、成熟度不理想.

8.資源的過度使用.

9.問題隱藏在良好的表象內.

10. 錯誤的功能及即時處理.

好的就到此為止, 在寫下去, 身為IT的我也要被唾棄了.

我們家妹妹也腸絞痛

那到底甚麼是嬰幼兒腸絞痛呢？又怎樣會腸絞痛就不多說了, 直接說妹妹的狀況.
大約是妹妹一個月大的時候, 這種狀況維持約有3星期, 每天到下午都會哭鬧, 但不是很嚴重, 還可以安撫的狀況, 只是動不動就哭, 很難餵奶, 不是喝不完就是要分很多次餵; 至於晚上就嚴重多了, 大概要哭到三點才會入睡, 在沒有入睡的這段期間, 幾乎都是在哭, 不睡覺, 喝奶不好餵, 大概的狀況就這樣, 問問週遭的同事, 也沒有這樣的情況.
妹妹的狀況我們大概撐了兩個星期, 受不了只好找醫生, 醫生就說是腸絞痛, 開了藥給妹妹吃, 但觀察起來覺得只有一點點的改善, 期間因為太痛苦了, 又買了益菌, 酵素等產品.

怎樣支配時間

在<上哈佛真正學到的事>一書中提到, 對哈佛一年級的學生來說, 最重要的應該是盡快熟悉管理時間的方法, 也就是學習如何將「必須做的事」和「想做的事」均衡安排.
我想這是我們生活中的寫照, 當邁入職場時, 這更是一項重樣的議題 : 也許我們每日都非常的忙碌, 記事本裡記滿了一推待辦的事項等這處理, 可是有些事情就是一直重複的出現在筆記本裡, 但永遠的一再被埋沒, 又一再出現. 這就是典型的情況.

通膨下的基金

最近買基金的朋友們一定很傷心, 因為最近基金跌幅已經有兩成了吧, 辛辛苦苦賺的錢就這樣不見了, 到底要不要繼續持有呢? 相信這是大家心裡的一個重大疑問?

基金的投資分成兩部份 : 定期與單筆.
定期地基金就是要分善風險, 當市場下跌時, 是一定要繼續扣款投資, 這樣當景氣迴轉時, 才可以嘗到甜頭, 只是口袋一定要夠深, 因為景氣何時回轉不一定, 所以之前常聽說的以基金養基金的作法, 這時可能就會破功了, 因為當上次贖回的總金額現在還在扣款, 當金額扣完時, 可能景氣尚未迴轉? 就有點像單筆. 這是一個定期的觀念, 但不樣忘了, 買到不好的基金, 也有可能永遠沒有漲回的時候, 或者漲福永遠比別人少, 所以也要注意自己持有的基金績效平均而言是不是都是前段班?
至於單筆的投資, 其目標就是要買在低點, 像現在通膨嚴重, 就不是單筆的投資時機點.

機會就像遭小偷

機會就像遭小偷 來的時候不知道, 走的時候才知覺.
用這句話來形容機會實在貼切不過了.

資料庫管理者的工作與挑戰

1. 系統面 穩定的資料庫
2. 資料面
3. 管理面

William Hunt Gross - 債券天王

閱讀自商業週刊 :
William Hunt Gross - 太平洋投資管理公司創辦人暨投資長, 唯一贏得3次晨星最佳固定收益基金經理人. 公司總資產8,120億美元, 從1987年起平均每年為客戶賺進10%的報酬率, 開啟主動式債券交易風格.

Gross 於大學畢業那年的一場車禍, 於住院時讀到加州大學教授索普 (Edward O. Thorp)所著-打敗莊家(Beat the Dealer)一書 : 教人用記牌方式在二十一點撲克牌遊戲獲勝. 出院後, 他帶著兩百美元到賭城試身手.

一開始, Gross 受不了周圍環境的菸味和酒氣, 經常無法集中注意力天都沒贏, 因此他會沮喪的不敢回到賭桌上. 而去觀察哪個發牌員比較會帶來好運. 後來發現一直換賭桌, 根本無法記住莊家已經出了哪些牌, 也就無法預測牌盒裡還有哪些牌.

這已經與打敗莊家的精神背離了. 因此 Gross 決定改變策略, 在同一個賭桌連賭四個月. 其間就算他輸了大注, 也從不退場, 繼續留在牌局中, 用兩美元下注, 就這樣當初的兩百美元盤纏, 竟然翻了五十倍成為一萬美元.

在這期間 Gross 建立起一套評估未來事件的機率 (也就是投資上的風險) , 將其分為長期與短期, 如果用二十一點比喻, 留在牌盒裡未發的牌, 代表的就是長期機率, 而莊家所發的下一張牌, 則是短期機率. 當你記住莊家已經發出哪些牌, 就掌握了長期機率, 你可以算出, 牌盒裡是點數大的牌多, 或點數小的牌多. 因此莊家接下來會發出什麼牌？你猜中的機率因此提高, 也可據此決定是否補牌.

Gross : 我從賭桌上瞭解, 當你看到勝利機會倒向自己時, 一定要持長期觀點. 因為短暫壞運所造成的損失, 會因長期趨勢有利於你而被攤平. Gross 悟到, 即便出錯只要對的次數加起來多於平均, 你就可以打敗莊家.

帶著長期觀點的思考架構, Gross 第一份工作是太平洋保險公司的債券分析師, 並於進公司六個月後提出 : 把債券當成股票, 在市場上買賣的做法.

融資金額是一種散戶的指標

傳統的觀念裡, 融資是一種散戶的指標, 融資的快速增減, 被解讀為行情轉強弱的關鍵因素.
融資如果單日增加達到30-50億, 就要小心行情拉回的情況.

SDLC : 軟體開發生命週期

專案生命週期的四個階段.

1. 瀑布式

發展階段一段一段往下推, 一定要一個階段作完才能往下做, 因此要準備的文件相當多, 不適於小型專案開發.

2. 漸進式

每個階段的產出都是產品, 所以每個階段產出都非常明顯, 但完成的產品會一直因為上一階段的產出而有所變動. 可以減少產品需求更動的影響, 開發成果較易顯現.

3. V型

每個階段都有對等的關係, 從當初的設計, 開發, 架構…等, 都會對應到一個方法來驗證. 強調品管是最有助益的方式, 確保所開發的產品符合設計規格.





4. 原型快速開發
但每個階段都有強烈的回饋, 需求上的溝通確認較容易.






5. 螺旋型
將瀑布模型的最終結果導回源頭, 成為一個往復式的圓圈, 使整個流程具備回饋與檢驗機制, 改善傳統瀑布式的需求更動影響缺點, 結合風險管理與原型快速發展的觀念.
6. Extreme Program (XP)

從人的本質考慮如何讓程式設計師, 可以提高品質的軟體 . 主要的精神是『在客戶有系統需求時, 給予及時滿意的可執行程式』.

4 個核心價值觀, 5項最優先的原理及 12 項的基本實務作法.
4個核心價值觀 : 溝通, 簡單, 回饋, 勇氣.

5項最優先的原理

1.提供迅速的回饋
2.簡化,不為未來的可延展性而使程式架構變複雜
3.漸進式改變
4.擁抱改變
5.做有品質的工作

12 項的基本實務作法
1.規劃
2.小量發行
3.簡化設計
4.測試
5.持續性整合
6.程式碼重構
7.雙人程式設計
8.程式碼共享
9.每週40 工時
10.客戶駐點
11.客戶與程式人員使用相同術語
12.遵行程式碼慣例

7. Unified Process(RUP)
由 IBM 提出, 具三大特點, 四個階段和九個核心流程.

主要精神為：1. 專案進行採用 Iterative 程序分階段漸進地完成專案功能；2. 廣泛使用 Visual Modeling 於商業需求分析、系統分析與系統設計；3. 強調架構設計；4. 對每項工作所需要的技術、工具、做法、範本、檢查項目均有詳細的定義，架構完備且具有可調整的彈性。

三大特點

1. 軟體開發是一個疊代(Iteration)過程.
2. 軟體開發是由使用案例(Use Case)驅動.
3. 軟體開發是以構架設計(Architectural Design)為中心.

四個階段

1. 起始階段(Initial phase)：進行可行性研究, 定義專案大小及涵蓋範圍, 評估專案所需的能力, 時程與經費, 及資訊系統預期達到之效益, 了解商業模型及需求.
2. 精細規劃階段(Elaboration phase)：擬定專案計畫, 系統特性與架構, 確認商業模型及需求, 進行系統分析與設計.
3. 建構階段(Construction phase)：建構產品並進行單元, 整合測試.
4. 移轉階段(Transition phase)：將產品分批交付給客戶驗收測試, 並進行使用者訓練.

九個核心流程
1.商業建模
2.需求
3.分析和設計
4.實現
5.測試
6.部署
7.配置和變更管理
8.項目管理
9.環境

8. Agile Process
特色有
1. 強調客戶與開發人員形成密切合作的團隊, 因為客戶無法於初期定義完整的規格.
2. 採用 Iterative 與 Incremental 方式分階段進行, 密集 review 是否符合需求.
3. 強調團隊合作, 賦予高度的責任, 團隊有自主權得以因應變化做調整.
4. 流程可以簡單, 但規劃與執行必須嚴謹.

UML 有我需要的嗎

先說明情節好了...其實就是人家說的ETL.
我的程式都很小約三,四千行以內, 每一隻獨立運作, 有時可能會有關聯, 互相影響.

我的問題情境是這樣的, URL 我要使用嗎?
想來想去, 覺得我有一個困擾, 是這樣的 -
程式雖小, 但缺少概觀性的說明, 無論是文字或是圖表. 所謂的概觀就是粗略的說明輸入/出, 處理邏輯這樣就好. 但要達到可以讓新人快速的了解, 也可以協助資深人員追查問題.

那 UML 有哪些可以協助我呢...

1. 使用案例圖(Use-case diagram) - 這不是我的主題, 我不需要 : 一個使用案例可用來說明系統所提供的一項功能, 使用案例圖主要的目的在幫助開發團隊設想系統功能的需求, 其中包含了參與者（actor, 也就是跟系統互動的人）與基本處理程序的關係, 還有不同使用案例之間的關係.
2. 類別圖(Class diagram) - 看起來也不需要 : 類別圖描述不同的個體(人, 事物和資料)相互的關係, 換句話說它表示了系統的靜態結構.
3. 循序圖(Sequence diagram) - 沒有這麼複雜吧 : 循序圖描述特定使用案例或是特定使用案例的一部份詳細的流程, 它們大多能讓人望圖生義, 並可以依照順序描述不同物件之間的呼叫關係, 也能夠詳細地描述給不同物件的各種呼叫.
4. 狀態圖(Statechart diagram) - 我們的邏輯處理中好少 State 觀念 : 狀態圖為一個類別模擬了所有可能的狀態, 還有該類別要如何從一個狀態轉換到另一個狀態.
5. 活動圖(Activity diagram) - 有時可能只有一個 Class 呢, 那這要嗎? : 活動圖用來描述在進行一項活動時,兩個或是多個類別 件之間程序的控制流程.
6. 元件圖(Component diagram) - 哎呀到底有沒有我要的 : 元件圖描述系統的實體狀況, 它的目的在於描述該系統中的軟體跟其他軟體元件的依存關係.
7. 部署圖(Deployment diagram) - 談的有點遠了, 不是我要解決的主題 : 部署圖描述一個系統要如何部署到實際的硬體環境上, 它的目的是要表示系統裡面不同元件實際上所要運作的地點, 還有這些元件要如何互相溝通.

結束了嗎?

VISTA-日本BRICs經濟研究團隊所提出

者裡的 VISTA可不是 MS 的新作業系統, 而是 Vietnam, Indonesia, South Africa, Turkey, Argentina - (越南,印尼,南非,土耳其,阿根廷)最具發展的五個國家, 也有人稱新新興市場, 這是日本 BRICs經濟研究團隊於 2006 年底所提出的研究報告.
報告指出 : 未來50年內, 也就是於2056年前, VISTA 的 GDP 將成長 28 倍來到, 268兆美元, 超越七大工業國.
不過2006年的 GDP 約 1 兆美元(約為金磚四國的1/4), 為何有這樣的結果, 其動力如下.
1. 具天然資源 - 諸如石油, 鐵, 黃金..等.
2. 外資引進.
3. 內需強勁 - 2008年這五國的人口約為 5 億, 其中印尼就佔了一半.

迴歸測試（Regression Test）

迴歸測試的目的在於測試之前(上一個版本)已經測試過的系統功能是否在系統變更之後, 仍然能夠保有運作的正常.

簡單的說就是常見的Ａ改好, 卻又另外出現了Ｂ的問題, 這種問題是寫程式的人都遇到的問題, 卻是主管最不願意看見的問題.

近來單元測試（unit test）的觀念已廣為接受, 如果單元測試的案例建立的足夠完整, 那麼進行迴歸測試的成本也就可以省起來, 這也是我認為 unit test 最大的優點, 這些案例就好比是一劑強心針濟一般, 可以讓我安心的上新版的程式.

如何確保軟體品質

如何確保軟體品質?這是每個作軟體系統的人都會遇到的問題, 但也許都還沒有時間做.
本人使用VS Studio + NUnit 已經有一年多的時間了, NUnit 其實是一個很簡單的工具.
重點還是在測試計畫這件事上到底做了怎樣才是? . 而不是有做Unit 就表示有做到軟體品質...
最近一直有一個想法, 可以不要做測試可以確保軟體品質? 如果有這樣實在太好了, 因為測試這件事真的很辛苦.
先來想想目的好了 : 簡單的一句話 : 確保軟體品質.
品質這件事所含的事太多了, 找 Google 問去, 不多說.
換個方式想, 先列出違反品質的事情, 行為, 如果這些事情我都可以避免, 那我是不是可以不要做測試了? 簡而言之 : 我有一個簡單的方式達到確保軟體品質. 哈哈~~ 這就是我最近一直想的.
或者說為達確保軟體品質, 創造一個制度, 有一定的制式步驟, 並且有防範的措施, 稽核, 但就是簡單.
...
想想目前的工作型態.
1. 維護的工作居多, 而且目前程式正確的在跑, 在被使用, 所以假設沒有Bug.
2. 既然沒有 Bug, 那我只是加一個小功能, 我夠 Quality, Careful, 我寫了程式就是一種保障.
居於以上兩項前提, 我需要做 Unit Test 嗎?
這樣的想法很像有點偏見, 再想想 Unit Test 有怎樣的好處好了.
1. 杜絕再犯.
2. 有Unit Test 就表示有一定的品質, 具有被認可性, 說服信.
3. 可以重複被使用.
4. 對於新手可以快速的驗證.
這些好處, 對我而言是好處嗎? 有其它方式可以彌補嗎?
1. 杜絕再犯. -> Review, 改善機制.
2. 有Unit Test 就表示有一定的品質, 具有被認可性, 說服信. -> 有時人就表示了, 好比信譽.
3. 可以重複被使用. -> 我需要嗎?
4. 對於新手可以快速的驗證. ->

輕鬆資產配置

1. 股債比率
債市的比率提高主要是降低資產配置的坡動性.
以2008年的狀況看來, 股債比約各半.
此外債市因為波動部大, 可以單筆投資, 定期的效益不大.
2. 區域分配平均
股票型的基金要做到防禦就是 : 區域分散, 產業也分散.
建議歐, 美, 亞, 新興, 主題產業 五等分.
3. 選擇減碼時機
選擇時機逐步減少應該要減碼的部位, 而非一次贖回.
4. 補足失衡部位

PS. 債市也會套牢
其實現在這總觀念大家都懂, 外加現況的慘狀, 從股票市場贖回的大筆資金一窩的網債市衝, 會不會行程追高殺低.
想想為何會有熱門的績金, 非常的熱賣, 這種熱賣的基金, 就好比熱門的商品, 只能短持, 是否能長抱就必須要思考清楚了.

多頭已經結束. 海外基金投資本由多頭攻擊, 轉為分散防禦投資

美國時間1/22, 聯準會主席柏南克宣佈25年來的最大減碼幅戶, 企圖拯救疲弱的美經濟. 政大金融系教授殷乃平斬釘截鐵的說 :多頭已經結束. 海外基金投資本由多頭攻擊, 轉為分散防禦投資.
這些引響短期內無法解決, 估計2-3年都屬於空頭時期, 固資產配置更顯重要. 至於定期定額的投資應作好分散區域, 股債配置, 選擇相對抗跌的市場.
美國市場應避免金融與房地產類股, 因為美國房市疲軟的情況, 至少要花上3-4年才能好轉.
英國市場因為金融與房地產占英國股市權重很高, 所以也要少碰.
日本的經濟則具有較多的虞慮, 建議出脫, 其他如印尼, 新加坡, 印度 比較有成長空間.