Sunday, September 27, 2009

書摘:與熊共舞—軟體專案的風險管理

在漸進交付計畫這一節當中,有一段是這麼說的。

The second constraint is that the design blueprint must show the entirety of the design partitioning, down to the lowest level. It's common practice to do some hand-waving at what seems to be an upper-level design, declare the design complete, and leave the rest of the design partitioning to be done as a by-product of coding. When this happens, all the advantages of the closure metrics derived from the incremental delivery plan are lost.

翻譯一下,大意就是說若在”漸進實作“開始之前你只有一份草率的High-level Design,那麼你的完工度指標就沒有意義了。

我認為DeMacro所認定的漸進式的哲學又和“設計一點,實作一點,測試一點”不一樣。工程師透過設計來分解出實作的最小單元,可是設計本身是不可分割的過程,尤其當經理人認真的想追蹤專案進度的時候。

專案管理的最大敵人就是不確定性,在專案初期就把設計做確實,在某個程度上就消除了許多不清楚的地方(尤其是語意上的模糊,需求書的內容被各自表述)。這是風險管理關鍵的一步。

不過,該花多久時間進行設計,該如何有效率的設計,又是另外一個主題了。

Friday, September 04, 2009

軟體除錯《Cross-DLL Hazard: Multi Copies of Template Class》

在編譯 DLL 的時候,Template Class 的 Code 都會被編譯 DLL 當中。因此若整個專案裡面有數個 DLL 分享同一份定義在 .hpp 的 Template Class,那麼你就有可能會有好幾份同樣 Type 的 Template Class 的 Code 落在數個 DLL 中。如果把物件轉成指標 Cross DLL 互傳,可能會遇到底下幾個問題。

不同的DLL可能使用不同版本的 .hpp。如果在這種情況下,Template Class 沒有做到 Binary Compatibility,那麼 A DLL 傳給 B DLL 的物件,操作一定會有問題。

就算不同的DLL使用同樣版本的 .hpp,還是會有問題。舉例,A DLL 傳給 B DLL 的物件之後,最後 A DLL 先 Unload,而 B DLL 手上握的物件洽好有參考到 Virtual Method Table,那麼此時對物件做動作,會嘗試去執行 A DLL 中的程式碼,然後位址早已被 Unloaded,操作也一定會有問題。

基本上 Cross-DLL 還是秉持一個原則,只 Export C Linkage 的函式。雖然這樣做還是不能一勞永役,不過能讓事情簡化。

 

用簡單的方式來做事,永遠都是一個 Good Practice。

註:最近在用 boost::shared_ptr 就遇到這類的問題,shared_ptr 裡面有參考到一個 Template Base Class,踩到了第二個地雷。