軟體開發團隊 - 自我評量法 (靈感來自 Joel Test)

~~ 客戶參與部分 ~~

1. [界面模擬] 是否與客戶進行了 UI Mockups 模擬溝通，才開始寫程式？（balsamiqs)

2. [測試案例] 是否有完整測試案例，才開始寫程式？包括功能測試、使用者經驗可用度測試、速度測試、壓力測試？（測試目的、預期結果、測試結果）

3. [週優先權] 是否客戶與軟體團隊，都有專人負責安排 Weekly 調整任務優先權？讓工程師一次專注在一件事情上開發，一週內不要受到變動的干擾？(Mantis優先權控制)

4. [線上文件] 是否專案相關的規格文件，都放在網路上隨時可更新溝通，並且可以線上同步編輯？（Google Apps）

~~ 軟體團隊部分 ~~

5. [版本控制] 是否採用版本控制系統？(SVN)

6. [任務追蹤] 是否採用除蟲追蹤資料庫？(Mantis 除蟲追蹤)

7. [除錯優先] 是否先除錯才新增程式碼？

8. [最新時程] 是否有最新的時程表（不可以是過期的），並且包含信心指數分析？

9. [專職測試] 是否有專職的測試工程師？

10. [走廊測試] 是否新功能一出爐，就有進行走廊測試？

11. [自動建構] 是否一個按鈕就能編譯建構，並部署整個專案，採用自動化Script？

每題一分，及格分數： >=8 勉強及格

由 "先進搜尋引擎" 的寫書邀稿內容，洞悉未來趨勢

各位親愛的同學們好 :)

外國的技術書籍，有很多時候是集結了一堆博士編輯，先開出大方向之後，再邀稿請大家集思廣益，把最新的研究成果用書籍的方式發表，好處是可以融合很多作者的知識精華，並且光是從邀稿內容就可以看出未來趨勢。

搜尋引擎技術的發展，從關鍵字之後，已經演進到語意網分析、推薦引擎排序、異質來源整合、異質格式整合。以下介紹一篇 2010 年 5 月的寫書邀稿內容：

*Introduction*

Scientific and economic organizations are confronted with handling an abundance of strategic information in their domain activities. One main challenge is to be able to find the right information quickly. In order to do so, organizations must master information access: getting relevant query results that are organized, sorted, and actionable. (資料檢索之後的呈現已經不再只是條列，必須要將類似主題的內容組織起來，經過推薦引擎排序，並且允許社群基於資料進行互動)

Recent technological progress in computer science, Web technologies, and the constantly evolving information available on the Internet has drastically changed the landscape of search and access to information. Current search engines employ advanced techniques involving machine learning, social networks and semantic analysis.

*Objectives of the Book*

The main goal of this book is to transfer the new research results from the fields of advanced computer sciences and information science in order to master the access to information. The readers will be able to have a better idea of the results in applied research. The achievement of relevant, organized, sorted and workable answers -- to name but a few -- from a search is become a daily need for the enterprises and organizations, and, to a greater extent, for anyone. It does not consist of accessing to structural information like in standard databases only; neither it does consist of searching information strictly by the mean of a combination of key words. It goes far beyond that. The information sought must be able to be identified by the topics covered by it, that is to say its textual, audio, video or graphical content. (異質格式整合呈現，如何以設計良好的GUI, 創造優質使用者經驗?) This is not a new issue. However, recent technological advances have totally changed the used techniques. The new Web technologies, the emergence of Intranet systems and the abundance of information on the Internet have created the need for efficient search and information access tools.

*Recommended topics include, but /are not limited to/, the following:*

. Semantic Web

More and more content producers, as a result of the W3C recommendations on the semantic Web, index their databases with metadata or taxonomies (ontologies), (語意網技術不只是提供資料，還有資料彼此之間欄位意義的關連性) in order to allow the search engines to adapt to the semantic analyzers. Currently many algorithms are being developed for semantic information research systems that do not impose hit-or-miss keyword searcher on the user.
. Generation of large-scale search engine index
. Video, audio and graphics indexing
. Query user interface: Controlled natural languages, natural language query, multilingual search, etc.

. Index Data Structures: Suffix tree, tree, Inverted index, Ngram index, Term document matrix, etc. (各種索引資料結構，都有助於將檢索速度增快到瞬間得到答案，這是一個很好的技術導引關鍵字列表，可以由此學習到 搜尋引擎 index 技術的專有名詞)

. Multi-sources and multi-formats (異質來源與異質格式整合呈現，將會是未來優質搜尋引擎的關鍵) indexation: Most recent search engines can index many different information sources, such as:

- FTP servers,
- files systems,
- Web pages,
- DBMS such as Oracles, Sybase, DB2, SQL Server and others.
- Document-oriented databases such as Lotus Notes.
- Desktop applications files such as Microsoft Office suite (Word, PowerPoint),
RTF format, ...
- Adobe's Portable Document Format (PDF)
- PostScript (PS)
- LaTex
- The UseNet archive (NNTP) and other deprecated bulletin board formats
- XML and derivatives like RSS
- SGML (this is more of a general protocol)

. Emergence of new axis in the Next Generation of Search Engines
- Real-time search, (目前搜尋引擎多是 batch 有時差，如何做到 0 時差的搜尋? 在特定少數資料下即時搜尋，才有辦法平衡搜尋時間與實用度)
- Local search,
- GPS sensitive search, (結合手機GPS的LBS搜尋，目前 google map 已經在手機上製作出非常精良的搜尋引擎，可以立刻找到附近的店家，在台灣也很容易使用，我採用Nokia N97 mini安裝額外的 google map 軟體，就可以瞬間找到我附近的 IKEA 地圖，以及如何驅車前往的方法)
- Mobile search,
- Search in the Cloud,
- Search using Hadoop,
- Map reduce, etc.

Tiny Program用"獨立小程式"增添新功能

為大專案增添新功能時, 務必使用Tiny Program技巧
建立一個全新的Project並且只是為了單一新功能配置好編譯與執行的環境

開發流程如下:
1. Text UML規劃
2. Unit Test
3. 為新功能建立Tiny Program(小程式)
4. 合併到大專案的CVS

使用Text UML進行Refactoring

打破類別相依 (依賴穩定不變的Interface比依賴時常修改的具體類別更好)
A->B (A引用到B)
to
A->I<=C, B (A引用Interface I, 而C與B實現I)

打破循環相依 (循環相依會造成動一髮牽全身的副作用, 一定要打破)
A->B->C->A
to
A->B->C->D
A->D

打破繼承關係 (委託關係比繼承關係鬆, 應該多用委託少用繼承)
A<=B
to
A<-B

A只用到一部分B, 想打破A,C之間的關係
A -> B -> C
to
A -> B1 <- B2 -> C

只有A的一部分用到B
A -> B
to
A1 <- A2 -> B

B只是需要部分繼承A(部分Method放空萎縮不用)
A <= B
to
A1 <= A2, B

B其實不需要繼承A,但是C需要繼承A與B的特性
A<=B<=C
to
A<=C=>B

Text UML的優點

UML圖形對分析類別相依性有著不可抹滅的貢獻, 舉例來說, 在Class Diagram當中, 即使是錯綜複雜的線條加上數十個類別, 我們仍可以順著箭頭所指的方向與密集程度, 瞬間了解某個類別是否嚴重相依於其他類別. 而Text UML也擁有許多UML圖形所無法達成的好處, 兩者可以相輔相成.

以下為Text UML的幾個優點:

採用直接閱讀文字就可輕易理解的格式

運用文字取代輕易打破相依關係

使用文字編輯器就能輕鬆編輯或重整設計理念

可使用文字方式將設計理念嵌入原始程式碼

可由CVS, Diff進行Text UML文字檔案的版本控制

30分鐘就能做出屬於自己的Text UML工具

由Sequence Diagram可全自動產生Class Diagram相依關係

由Sequence Diagram可全自動產生Class Diagram類別與其擁有的方法

可自動計算類別間的相依性是否由不穩定到穩定

不受程式語言的限制, 可運用在各種設計場合: Python, Java, C#, C++

Text UML展現文字的力量

如果你經常需要畫流程圖或者方塊圖, 一定有跟我一樣的體驗, 明明幾個箭頭就可以解決的東西, 偏偏要開出作圖工具來拉線, 實在有夠麻煩, 製圖工具的啟動 時間緩慢之外, 人類通常都有浪費時間在調整框框位置或大小的癖好 (天啊! 程式已經寫不完了... 別再調啦!), 如果可以用很簡單的文字來表現UML圖形, 開發者就能夠更專注在改良類別設計. 舉例之前我們先定義Text UML中兩種文字箭頭的意義:

=> 代表 繼承/實現 關係 (Inheritance, Generalization, Realization)

-> 代表 引用/使用/擁有/依賴 關係 (Association, Dependency)

為什麼每種文字箭頭都代表了多重意義? 因為簡單勝於一切, 若要精確的呈現類別關係, 使用精準的UML圖形會比Text UML佳, 我們使用Text UML就是貪圖簡單的力量:

MailClient->SqlStorage

以上Text UML說明了電子郵件客戶端類別MailClient使用資料庫類別SqlDatabase來儲存郵件, 一旦SqlStorage改變, 因為MailClient相依於SqlStorage所以可能必須跟著改變.

利用Text UML的簡易性, 我們可以在十秒內將上述相依性打破, 讓MailClient可以自由選擇將電子郵件儲存在檔案FileStorage或資料庫SqlStorage:

MailClient->IStorageService<=FileStorage, SqlStorage

上述Text UML是讓MailClient相依於Interface IStorageService, 再讓FileStorage與SqlStorage實現IStorageService當中宣告的方法, 這樣一來MailClient就可以任意選用檔案或資料庫的儲存方式, 這是典型Strategy Pattern的手法.

然而文字Text UML為我們帶來什麼樣的好處? 有個很明顯的優點是: 可以利用字串替換的方式打破相依性, 我們完全不需要管類別真正的意義, 就可以運用單純的字串替換達到更有彈性的設計. 假設我們有A, B兩個類別, 而A相依於B, 則在Text UML表示如下:

A->B

若想運用Strategy Pattern將類別A與B之間的相依性切開, 只需要將"I<=C,"字串插入原本B的前面如下:

A->I<=C,B

其中I相當於郵件範例中的IStorageService, 而C與B相當於上述郵件範例中的FileStorage與SqlStorage. 這麼簡單的字串取代就能完成Strategy Pattern的設計, 完全不用管你實際類別到底有什麼作用, 文字的力量表現無遺. 這種字串取代很容易可以利用程式自動化, 熟悉文字處理的開發者, 只要幾十分鐘就可以做出好用的Text UML工具, 輔助進行各種複雜的設計.

捨棄白板崇拜

很多程式設計大師與書籍都鼓勵程式設計師使用白板交換對Class Diagram的心得, 因為白板可以迅速擦掉修改, 加上大家站在白板面前熱烈討論的氣氛, 確實讓白板成為吸引人的工具, 但是我發現使用白板有幾個缺點:

1. 白板筆時常寫到沒有水 (奇怪的是明明沒水了大家還是不斷用力的塗)

2. 圖形很難Email給所有與會者 (真希望白板內建Outlook Express)

3. 白板筆很臭 (應該屬於有毒氣體)

4. 有些人用白板作畫, 明明就是超級簡單的方塊也會醜到無法理解

5. 白板沒有辦法列印出來放在電腦旁參考

我原本對白板充滿了幻想, 覺得這應該是很好用的東西 (沒辦法, 眾家大師推薦, 我又很喜歡趕流行, 你只要看看XP相關書籍就知道他們對白板的崇拜), 但真正運用在實際生活上面, 白板對程式設計師就是不太夠.

所以我極力推薦大家挑選任何一種順手的UML製圖工具 (例如免費的JUDE,或是Borland Together, Rational Rose都很好用) 加上19吋LCD大螢幕(現在已經比五年前便宜到超乎你想像), 就可以在辦公室或會議室進行討論, 有幾個優點很顯著:

1. 用滑鼠拉各種線條非常快速並且整齊, 不會因為同事美術不及格而打壞心情 (帥手, 我真的不是有意把你的事蹟供出來...)

2. Class Diagram可以任意調整Class位置, 迅速拖拉可騰出空間放新產生的Class (白板經常畫到沒有空間, 在邊邊角角越畫越小...)

3. 儲存為PNG格式很容易使用Email流通, 或插入Word文件

4. 使用列表機印出來放在桌邊隨時參考, 又可以用原子筆迅速塗改

5. UML工具很容易可以把細節隱藏起來, Class Diagram最重要的是分析類別之間的相依關係(Dependency), 所以單單有Class名稱與線條就夠用了, 把Method與Attribute隱藏起來, 才不會因為圖太複雜迷失方向

6. 若工具是使用Borland Together有額外的好處, 程式碼可以與UML即時同步

很多程式設計師把UML當成是"設計草稿"在使用, 這種觀念有其價值, 因為最終是Source Code主宰結果, 太認真想要畫出巨細靡遺的UML圖形, 便失去了利用圖形進行抽象設計的意義, UML圖形是要讓我們節省設計時間, 因為塗改UML圖形比改Source Code容易, 現實生活中的程式設計師是有時程壓力的, UML應該挑最重要並且容易混淆的地方特別畫清楚就好, 剩下的應該讓風格一致並且容易閱讀的Source Code自我說明.

只要兩種UML圖形

UML發展的精神, 是為了讓軟體開發者有共同的設計語言, 以便有效縮短大家溝通設計理念的時間, 現在幾乎各種物件導向程式語言 (Python, Java, C++, C#, Delphi...) 都有專屬UML工具可以使用, 而我們可以看到一些與設計相關的文獻如 Design Pattern, Refactoring, Agile Programming等領域, 作者們也都習慣使用簡煉的圖片指出設計關鍵, UML圖形已是軟體設計必要的基礎工具.

完整的UML規格龐大而複雜, 常導致許多初學者裹足不前, 不知從何著手將UML帶入日常的程式設計流程, 其實UML跟所有語言特性一樣, "敢講不怕錯" 就很容易可以上手.

撇開各種複雜的UML規格先不看, UML裡與程式設計關聯最緊密的兩種圖形為: Class Diagram與Sequence Diagram, 前者分析類別間的繼承關係與引用關係, 後者則清晰的將物件之間的互動順序呈現在眼前, "每個"程式設計師都應該精通這兩種圖形. 無論是將自己的設計架構文件化, 或為了與同事做Design Review / Code Review, 或想看懂設計相關文獻中的架構討論, 這兩種UML圖形都可在短時間內讓人抓住開發者的設計理念, 進而通過討論溝通而得到更好的改善建議.

捕捉不變的原則

無論是Python, Java, C++, C#, 這些程式設計語言都有共通的原則, 掌握這些原則, 可以應用在Mobile Phone Programming, Web Programming, Client/Server Programming. 身為程式設計師, 若要在瞬息萬變的資訊世界立足, 探索並捕捉這些不變的原則, 是累積我們個人價值的方式, 學會一個新的技術可以時髦一陣子, 但掌握了一個不變的原則卻可以用很久很久.