小攻城師的戰場筆記

「Visual Studio 2010 Ultimate 軟體開發生命週期管理實作營」就是以前的 VSTS 二日營，這份筆記是第一天 (2011/05/23) 的內容。

在 Visual Studio 2008 之前，Visual Studio 所提供的塑模工具只有 DSL。DSL 可以用來描述 IIS 設定等等內容，若是要繪製其他圖形，通常都會使用 Visio。一直到 Visual Studio 2010 才完整支援 UML。

沒有文件對溝通是不利的，即使你不需要和他人溝通，你也必須和未來的自己溝通。文件是最好的輔助，撰寫文件時只要達到可以瞭解的程度就好，不需要寫得過於鉅細靡遺。

若想描述多個專案之間的互動，可以使用「模型專案」。其中的「圖層圖表」與「有向圖形文件」是微軟自己的標準。

導入新技術不難，但導入團隊文化很困難。

可以在 UML 圖右鍵→「連結至工作項目」，設定與 TFS 的 workitem 的連結。但是 Visual Studio 2010 預設無法使用這個功能，要先安裝 feature pack。透過這個設定可以關聯需求來源、瞭解這個工作項由誰負責。

專案進行時，應該先發展文件、程式越晚開始寫越好。至少要先把 activity diagram 畫出來，以瞭解功能與功能之間的關聯。

《約耳趣談軟體》提到工程師們普遍有「寧可重寫也不要維護之前的系統」的心態，要減輕維護系統的痛苦感，最好的做法就是留下足資說明架構的文件。產生架構圖有兩種選擇，若選擇依組件產生，會依照專案來產生架構圖；若依命名空間產生，則是會將跨專案、擁有相同命名空間 (namespace) 的內容繪製在一起。

上課的投影片裡有展示一些 demo 影片，這些影片的來源是 MSDN 的 Channel 9。

Tier & tier 之間，最好是由上往下、或由前往後呼叫，如果有反向呼叫會相互牽動得亂七八糟，通常我們就會稱呼這樣的 code 是義大利麵式的 code。例如，我們應該從 business layer 去呼叫 data layer，但反過來就不是很適合。

Visual Studio 2010 之中，自己拉圖例進來繪製 layer diagram 時，如果遺漏了架構中真正存在的內容，可以利用「驗證架構」檢證出來，但是多畫的部分就不會顯示錯誤訊息。

• 假設正確的圖例長這樣：
  ○─→○
• 如果畫成成這樣自然會顯示出 error。（會提示你應該補上中間的關聯）
  ○　　○
• 但是如果畫成這樣就不會顯示錯誤訊息了：
  ○←→○

有學員問到 COM 能否支援自動產生 class diagram，答案是不行，要能支援 reflection 的內容才能自動產生 class diagram。（例如 DLL）

程式碼的可維護性是建立在行數、呼叫與繼層的層級之上。行數越多就越難改、呼叫一層又一層也不易維護，若是用 for & if 等內容一層包過一層或繼承了很多層下來，都不易維護。像是只有一函數在呼叫的程式，其實就不需要把它特地獨立成函數，應該是可 reuse 的程式碼才設定成 function。對 complier 而言，拆解過的函式是 stack，如果過度拆解，早期硬體不佳時會影響效能。

一定要有額外的人（非開發者本人）來進行 code review、讓不同的人來交換意見，才能看出問題來。建立了規則，developer 也一定不會遵守，一定要透過 code review 來檢視是否有按照規定來。不過，code review 的人可能不懂 domain knowledge，所以經過 code review 的程式碼可能依然存有商業邏輯上的錯誤。

只要是字串組成的內容都有可能成為任何一種 injection，包括 XML injection, DOS command injection, SQL injection...etc.

在 Visual Studio 設定的 code analysis policy 也可以成為 TFS 的 check-in policy。

通常我們會把程式裡的例外狀況用 try & catch 抓起來，但是若沒有做 log，這麼一來真實問題可能無法取得任何線索。而且，有太多錯誤無法重現，因此在 issue tracking system 上有絕大多數的 bug 之所以能 close 的原因竟然是「在開發環境沒有這個問題」。透過 IntelliTrace，可以用以檢視過程之中發生的事件。

想使用 IntelliTrace 必須要先安裝 feature pack 1 和 service pack 1，要錄下的 IntelliTrace 事件，要在 Visual Studio 的「選項」設定 (Tools -> Options -> IntelliTrace -> IntelliTrace Events)，或是修改 CollectionPlan.xml。從選項裡可以看到預設是什麼事件都不收集的（XML 就是表示為 enbale=false）。

透過 InetlliTrace 收集資訊後，直接點兩下收集過資訊的 *.trace 檔，就可以取得錄製追蹤結果後的報告。

在除錯過程中，可以將 data tip 匯出為 XML，移到其他機器去匯入參考。

JavaScript 的效能判斷，必須要在「效能精靈」的設定選擇「效能」的前提下才能使用。（若設定為「CPU取樣」，就無法選擇「分析 JavaScript」）。如果不想透過效能精靈協助設定，也可以自行在「效能總管」修改效能評估計畫。

有學員問到能不能在正式主機上使用 IntelliTrace，胡百敬老師不確定 Visual Studio 2010 是呼叫哪個程式進行監控，在無法在正式機上安裝 Visual Studio 2010 的前提下，老師的建議是把 IIS log 匯入到資料庫裡再做分析：

1. 先把 IIS log 檔頭 "field:" 以及其之前的內容都砍掉，留下的內容匯入到 SQL server。
2. 匯入時要注意：記得 Win2000 & Win2003 的 log 還得選取「移除行尾空白」，否則 parser 結果會大亂，query & agent 的欄位寬度要給大一點（預設的欄位長度不夠用）。
3. 匯入到 SQL server 後再 select & group by，可以幫忙找出一些問題。

或在 web.config 把 trace 打開：

<system.web>
    <trace enabled="true" localOnly="false" requestLimit="1000" />

如果是傳統的 ASP.NET 網站，可以在根目錄下找到 trace.axd、觀看其收集結果（MVC 的路徑就不同了）。

「不能給他人呼叫的 service 一定是藏污納垢的 service」，建議橫向負責，例如：UI 由 designer 或前端工程師處理、service 由開發人員執掌、data tier & store procedure 由 DBA 控管，不要由一個 developer 統包所有作業。因為現在每一項技術都快速演進，橫向發展有助於每個人專精自己手上的技術，在反覆溝通討論後，東西的品質也能有所精進。

加密最好在程式裡做，不要透過 SQL server 做，以提升安全性：programmer 不能碰 DB、所以沒辦法對 DB 做壞事，DBA 因為無法自行加解密、所以也無法自己篡改 DB。

「SQL server 專案」可以透過「結構描述檢視 (schema view)」，能夠更輕鬆地檢視物件。

「SQL server 資料層應用程式」其主要功能是方便佈署。

Visual Studio 2010 可支援靜態程式碼分析，在功能列的「資料」→「靜態程式碼分析」，選擇「設定」可選取 policy、選擇「執行」即開始進行分析。例如，"select * from table" 是一種不良習慣，也能夠透過內建的 policy 檢查出來。（語義不正確的 query 則要利用 unit test 檢測）

存檔或建置專案時，SQL 專案會檢查 SQL statement 的正確性。

DBA 最好不要透過 UI 做事，就算要用 UI，也應該是透過 UI 產生 script，以利日後檢討、驗證。programmer 和 DBA 溝通時應該也寫成 script，而不是在 word 上寫「請幫我開一個 DB 和這樣那樣的 table」，這樣才能夠討論、修改 script 內容。

若想在資料庫塞測試資料，可以利用資料庫專案的 Data generation 功能：在專案右鍵→加入→資料產生計畫。可以加入亂數內容（可設定值要符合特定區間，或是「一個廠商要有對應的十筆訂單」這樣的一對多關係），也可以利用「循序資料繫結產生器」或「資料繫結產生器」透過現有資料庫產生測試資料。

• smalldatetime最小值為 1900/01/01
• datetime最小值為 1753/01/01　（←這是新舊曆法制度換曆後的基準點日期）

code analysis 會建議應該以 scope_identity 代替 @@identity，兩者差別在於後者是全域的，通常我們會想要使用這個函式是想取得 table 異動後的最新識別，因此應該使用 scope_identity 為宜。

使用 Visual Studio 進行重構，VS 會自動幫忙找出會被影響的地方，但是不要完全相信 Visual Studio 所產生的 script，尤其是資料庫，不應該採用 VS 建議的 drop & create，最好是用 alter。（因為 drop & create 後，之前做的全部授權就不見了）

應該使用 schema 為大量的 table 分類，而不是全部都使用預設的 dbo。在寫 SQL statement 時也應該養成習慣，使用 schema + object 的方式取用物件，例如 "dbo.table001"。

「資料結構比較」可以在專案與資料庫之間互相比較（專案與專案比較、專案與資料庫比較、資料庫與資料庫比較）。

測試的基本要訣是 ABC：

• A: 初始化
• B: 驗證商業邏輯
• C: 成功或失敗