「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: 成功或失敗




arrow
arrow
    全站熱搜

    小攻城師 發表在 痞客邦 留言(0) 人氣()