如果引用或轉貼,麻煩註明出處與本網誌連結,否則視為侵權。

2005年7月29日

程式設計功力提升的方法與Joel on Software網站

作者 : Fred (Hainchu-Taiwan) 日期: 2005/7/29


每天沒日沒夜的寫程式, 這樣過了幾年, 程式設計的功力, 真正就會自然提升嗎?
我想這是很困難的, 如同每天造橋鋪路, 過了幾年就可以蓋大樓了嗎? 砌磚久了就可以變成建築師了嗎?

我想提升程式功力, 不外乎幾個方向 :


1.實作中學習, 解決實作過程中的任何問題, 但是成功的完成每個專案, 不表示您的程式品質就好
 

2.深入的程式技巧學習, 例如Design Patterns, Programming styles, Refactoring Technology等等, 多看書, 多練習, 將這些東西真正變成您程式設計的習慣
 

3.縱向的學習, 程式設計的上下游的東西, 如系統分析, 架構設計, 細部設計, 資料模型, 系統測試, 軟體品質衡量, 軟體專案管理, 等等, 為什麼要了解這些東西, 例如: 架構設計, 架構的選擇將影響程式設計很大, 軟體品質的程式再用性,可擴充性, 可移植性, 甚至使用者要求的系統效能需求, 都可能牽涉到非常複雜的程式設計技術與技巧. 如果能夠提升縱向的視野, 當然有助能力的提升

另外推薦Joel on Software網站, 好好看看, 有助程式設計素養的提升

內容有:
程式師的使用介面設計手冊
讓錯的程式看得出錯
無痛錯誤追蹤
無痛功能規格
約耳測試: 邁向高品質的12個步驟
無痛軟體時程
軟體人員面試教戰守則

2005年7月25日

SAP Web Dynpro 專案開發程序

Fred Wang(http://fredwang.blogspot.com) 2005/07/25

SAP Web Dynpro是一套快速建構的Java Web Application Framework, 在SAP Netweaver Developer Studio的開發環境中提供特有Component-Based的MVC架構 。

不過,網路上鮮少文獻或討論有關使用Web Dynpro開發Web Application完整的軟體工程方法或程序。在SAP出版, Chris Whealy, “Inside Web Dynpro for Java”書中, 第27-31頁僅以五頁的篇幅描述這個程序。對於多數開發者而言,一個新的架構,需要更多的時間,更多的學習資訊協助以了解Web Dynpro如何用在真實的應用專案中。下面是筆者近幾個月開發Web Dynpro專案整理的一些心得筆記,希望對準備學習或使用Web Dynpro的人有所幫助。也歡迎先進給予指正。



需求分析

Web Dynpro開發專案的分析階段應該與Web Dynpro的技術無關,建議可採用UML的技術來描述系統需求。

架構設計

架構設計階段則與系統規模,非功能需求如可靠度,可擴充性等有關,例如: 是否使用異質資料庫,是否分散式處理,效能需求的要求如何,是否採用Design Patterns,採用何種Design Patterns,採用哪些基礎性與平台性的APIs, 例如: Logging , Exception Handling, Authentication,

Authorization, Asynchronous Processing, Scheduling, Configuration, Messaging等。 採用哪應用APIs, 例如 : Workflow, Reporting, Content Management, Transaction等。 另外使否使用JDI, 是否整合SAP Portal, 是否與其他Project互相整合等。


細部設計與實作程序

第一 使用者介面設計與系統雛形(Prototyping)

1. 根據Activity Diagram中的畫面建立View : 可以一個畫面建立一個View或多個類似的畫面共用一個View

1.1 View中進行畫面設計, 表格, 欄位, 按鈕等

1.2 建立畫面所需Binding的Context nodes and value attributes,並設定UI elements property的binding關係

1.3 若Context nodes或attributes需要跨Views來使用,則要在Component Controller複製相同的若Context nodes或attributes,並用Data Modeler(Component Diagram)建立Context mapping。

1.4 若是共用的View則應增加一些value attributes並bind到特定UI元件的read-only, enabled, visible等欄位, 來控制這些View在不同的狀況下可否輸入,是否顯示等。

2. 建立View間的Navigation關係 : 建立Window, 在Window Diagram建立View的Inbound plug與Outbound plug及連結關係

2.1 若Inbound Plug與Outbound Plug間要傳遞參數, 則兩者都需建立相同名稱的參數

2.2 找出Trigger Outbound Plug的UI元件,建立Event Handler,並指定Outbound Plug

2.3 要注意,畫面除了有進入的Inbound Plug,也應該要有返回的Outbound Plug,因此也要指定一個UI元件來啟動Outbound Plug

2.4 若View為多個功能畫面共用,則在Inbound Plug Method中根據不同的參數或不同的Inbound plug,設定畫面的read-only, enabled, visible (透過value attributes)

3. 使用者進行介面測試 : 完成上面的程序,畫面的Navigation已接近完成,此時可以與使用者進行介面測試,確認畫面樣式與畫面操作流程是否正確。

3.1 此時可以在Context node的supply function中,設定一些測試資料,以利操作過程中雛型的測試。

3.2 完成上面的程序可以提早在此階段與使用者確定規格,避免在開發的後期才更改規格, 造成專案進度更大的影響。


第二 商業功能設計與單元測試

1. 完成每個商業功能

1.1 畫面顯示前的處理, 在wdDoInit()或onPlugXXX() (Inbound Plug)中的商業處理

1.2 商業功能處理, 每一個會Trigger Event的UI元件,實作這些Event的Event Handler功能

1.3 Context Node的Supply Function,若與Data Model整合可以到後面資料模型設計階段來處理。

2. 這階段,可能有自行開發的程式,採用外界的APIs, 或自訂的公用APIs, 盡量可以讓程式高度模組化,提高程式的可再用性。

3. 如果使用者前端設計及商業功能設計為不同開發人員,則負責商業功能設計的開發人員需撰寫單元測試程式進行商業功能的單元測試,一般採用JUnit測試架構。


第三 資料模型設計與整合測試

1. 建立Database Tables

2. Data Model可以用不同的方式實作

2.1 Java Bean : 用EJB or POJOs(DAO design pattern)

2.2 Web Service

2.3 SAP RFC Function

3. 將Data Model Map到View Context Node或Component Controller的Context Node

4. 進行整合測試

4.1 此時的測試就是包含Data Model, Business Function與UI設計的整合測試。

2005年7月14日

應用系統該如何選擇使用哪些J2EE Design Pattern?

應用系統該如何選擇使用哪些J2EE Design Pattern?

Fred Wang(http://fredwang.blogspot.com)

方法如下 :
1.依照樣式(Pattern)的目的加以分類
例如Presentation Tier的樣式可以加以分類如下:
. Intercepting Filter, Front Controller, Context Object and Application Controller: 用來處理需求, 或將需求轉交商業服務來處理。都是處理需求但是實際應用上略有差異。
. View Helper, Composite View : 都是用來將回應或需求處理的結果加以呈現
. Service to Worker, Dispatcher View : 從需求處理, 商業邏輯呼叫及View的呈現的架構

2. 了解每一種樣式要解決的問題與適用範圍
例如Service Activator專門用於非同步服務的呼叫。Session Facade用於使用EJB提供遠端商業服務的狀況。

3. 閱讀每個樣式的描述, 解決方案。特別要了解其Class Diagram and Sequence Diagram。

4. 找出樣式間的關係
例如 : Session Facade, Application Service與Business Objects間的關係, Front Controller, Context Object與Application Controller間的關係。

5. 系統可變因素是甚麼? 在不需重新設計下如何讓系統有更高的可擴充性:
例如 : 設計的樣式是否考慮不同的網路協定, 使用端的環境, 是否支援不同的資料庫。簡單而言, 您的系統可否增加Rich Client, Mobile Client, 是否可以增加另一種資料庫的存取。

6. 與第5點相反的就是訂出什麼狀況會造成系統要重新設計 :
例如 : 商業處理由POJOs提供服務, 增加EJB的遠端商業服務時, 系統是否要重新設計? 增加一種後端系統(Backend)存取需求時,系統是否要重新設計? (只要增加處理的元件而既有的元件仍可再用)

參考 : Craig A. Berry, John Carnell..etc, "J2EE Design Patterns Applied"

2005年7月13日

[推薦文章]e天下: 席捲企業的新勢力!Blog Inc.


根據部落格搜尋引擎Technorati指出,部落格以每天新增2萬3,000個的驚人速度成長,甚至迫使企業必須開始改變遊戲規則。美國《財星》(Fortune)雜誌則將部落格列為2005年度十大趨勢之首。微軟董事長比爾‧蓋茲更指出,部落格是繼e-mail、BBS、即時訊息(如MSN Messenger)之後,第四個改變世界的網路殺手級應用。...

根據美國網路調查機構Perseus估計,全球部落格的數量5年內數量成長超過1,000倍,從2000年的2.95萬個,快速成長到今年第一季的3,160萬個,到今年底,預估全球部落格數量將達到5,340萬個。...
http://www.techvantage.com.tw/content/055/055082.asp