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