Posted on 2010-10-19 00:18
瘋狂 閱讀(2243)
評論(4) 編輯 收藏 所屬分類:
java 、
項目管理 、
方法論
一個關于移動的項目，現在做了快兩年了，項目越來越大，其中有的表數據加上歷史數據都到10億級別，由于這兩年團隊成員流動大，導致代碼越來臃腫，前期項目代碼的管理不善，除了較大的版本，一般的小修小改都不經過代碼評審，本地測試通過后，直接hotfix，有時候很順利，但是偶爾導致較大問題，有時候甚至影響客戶使用，導致公司虧損。現在領導發現問題就直接罵工程部，導致現在每當有一點點修改，工程部都要求AQ按照測試用進行全用例測試，測試非常的不易，光是功能測試幾乎5個測試人員一天時間，還要兼容幾乎所有瀏覽器（ie6~8,火狐，遨游，TT，360，google,搜狗）。工作量巨大。沒辦法現在我們的做法如下：
1 加強代碼的版本控制，對每次代碼的修改，都直接聯系到個人，代碼的修改都要寫修改說明，包括：修改內容，修改前效果，修改后效果，對其他接口或功能的影響，回滾策略，測試用例。
2 代碼評審：代碼評審的標準我們也在不斷修改完善，過一段時都會對評審標準進行評審。評審前參會人員都會拿到 上一步相關人員寫的修改說明，會前2小時閱讀，會中，有相關人員對代碼進行流程講解，并進行效果演示，評審內容包括，代碼評審（是否符合代碼評審標準），效果評審（是否達到產品需求效果），用例評審(是否可以覆蓋當前修改)，回滾評審（出錯后是否可以及時的回滾到前一版本）。
3 總結每期評審結果，必要時間進行討論，提出問題：包括項目中遇到的難題，和大家對評審的看法，總結經驗，并對公認的技術問題進行歸類，由對此熟悉的人員（架構師，開發經理，個人）在周一進行技術講解（我們是每月2次的技術培訓，沒有公共話題的情況下，如果有人想分享個人經驗的話，可提前準備，現在為了鼓勵大家，根據培訓效果，對培訓講解人是有償的，獎勵多少不公開，會中很活躍，一般不會刻意打斷你，除非公共話題，這一點我是比較喜歡，每天都會去翻大量的文章，書籍去了解話題）。
4 和績效掛鉤，這一點大家都不喜歡啊，不過沒辦法，領導意思，每次上線都搞得心里惶惶的。
這些工作我們做了半年，也是有成效，有時候評審會叫上工程部的人來看，工程部也承認我們的工作，也不怎么要求全用例了，但是好多都慢慢形式化，包括評審，主要還是有時候項目特別緊，大家都加班加點干項目，為了上線，項目都改了好幾個版本，還沒評審一次，結果可想而知。有時候也想過自動化測試，但是離開了人為的控制任然問題多多啊，主要是自動化測試這方便經驗不足。
不知道大家在開發大型項目的過程中，都是如何保證產品質量的，主要是如何在項目比較將緊的情況下防止全用例測試，不要說你們每次修改都全用例測試，都是綠燈才上線，全用例測試對我們來說那簡直是要命啦，也不要說剛招聘的一個新人他寫的代碼你就放心不用測試評審。
我個人認為是可以避免少量修改導致的全用例測試的，主要的問題就是修改帶出來的新問題，如何防止修改老問題帶出新問題，個人認為有以下因素導致：人的積極性，人的責任心，人的上進心。人的積極性需要領導層共同解決，如何在緊張的項目下給員工舒適的環境和心情，人的責任心和上進心是就是自己的素養，不管多么沒意思的工作你是否愿意去做好，還有就是你是否愿意提高你的技能來防止這些問題。 但是這每一點都不是嘴上說說就能做好的。