軟體設計：給Developer的四個好工作習慣提案

在我的工作環境中，Developer和QA是兩個不同的腳色。在開發的過程中兩者就不斷的在Coding-Testing-Debugging的反覆循環中讓事情繼續前進。就因為這個生產線般的過程，Developer所做的事情都會直接影響QA的工作效率。

所以，如果你是Developer，在你提交你的程式碼以前，請保持以下的好習慣：

• 至少測過一次：
  不管修了多小的Defect，請在自己的機器上測過一次，然後再交給QA。如果你聲稱解決了某個Defect，QA卻驗證失敗，除了浪費了QA的驗證時間（人家也是要在很多Test Case之間Context-Switch的...），也會讓QA對於Developer的程式碼失去信心。
• 確認已同步最新的程式碼：
  如果你的團隊有用SCM（沒有嗎！God bless you...），在提交程式碼前，請再一次同步程式碼。如果有變動，就請再重新編譯一次。如果你的專案編譯一次就是好幾個小時，編譯失敗的成本就是浪費N小時乘上QA人數的時間。
• 和QA討論你的變更：
  Developer專注於單獨的設計或是獨立的Bug Fixing，可是QA卻是要保證系統整體的品質。所以請和QA討論你的變更在哪的元件，在架構上和這個元件相關的其他部分又有哪些。這些資訊都可以幫助QA在有限的時間內安排最合適的測試案例。
• 重大變更請提交到一個獨立一個Build：
  如果你的團隊有在使用Daily Build，對於任何重大的變更，例如：共用元件的變更，升級某個第三方的元件。這些可能對於軟體系統的風險影響較大的改變，請留到下一個Build（或是這個Build就只進這個重大改變）。如果QA在Regression Testing中真的發現了影響，Developer可以直接比較Build-to-Build的改變，快速地隔離出可能有問題的變更。

要讓QA對團隊做最大的貢獻，就是不要浪費他們的時間。留給QA更多時間去設計複雜的測試案例，就更有機會在早期發現問題，早期治療。身為Developer也就少一點機會成為下一個在版本釋出後才出包的苦主。XD