如何提高代碼質量意識

seailove 14年前發布 | 2K 次閱讀

在接下來的文章里我會講到如何提高代碼質量,會講到一系列措施和工具,比如codereview、重構、findbugs、敏捷等等,這些東西對代碼質量非常有用,但取決你是否行動了,你和你的團隊是否具有強烈的代碼質量意識,如果沒有強烈的代碼質量意識,這一切就像是在看我這個小丑在上演一場杯具,過往云煙,看過了就忘記了。學習一項技術很容易,但是學習一種意識,或者說改變一個人的習慣,很難!

誠然,意識和習慣是自身的覺悟,要改變的確很難,更何況眾口難調,那我為什么要寫這篇文章呢?我自己多少也有一些迷茫,大的環境是浮躁的,要改變就要付出代價。

============================================================================

當你跟別人合租房子時,你會主動把廚房打掃干凈嗎?如果是你自己的房子呢?

 

當你要寫一份給自己看的心得是,你會把它寫得很漂亮很有深度嗎?如果早知道這份心得會抄送給全部門看呢?


當你在修復一個
bug時,你是否會首先確定這個bug的來源,如果是自己發現的?能解決就解決,不能解決或者太麻煩就這樣吧,反正別人也沒發現;如果是QA部門發現的?盡量吧,實在不行就推遲解決;如果是客戶反映的,而且被領導盯著的?全力以赴,加班加點的干。

 

當進公司第一天寫代碼,是否有種要把自己的代碼打造成完美的沖動?是不是敲入的第一字符不是代碼而是自己的名字?是不是連一個變量名,怎么寫注釋都要糾結半天?不過一年之后呢?當你團隊沒有任何質量改進時,你是否還會這樣嚴格要求自己?

 

主人翁精神

當你的努力能立馬換來客戶的贊揚,老板的賞識,更重要的是產品質量的日趨穩定,我們是不是有很大的成就感?我們是不是為自己的負責的產品或項目更加感到驕傲和自豪,我們需要這樣的人,這種人會主動去干一些事情,最大的發揮程序員的生產力和創造力。

擁有主人翁精神的人會把自己發現的問題及時解決掉,但是要樹立這種精神,會牽扯很多管理方面的科學,小而精悍的團隊正是主人翁精神最大的受益者,它們會把自己的產品和項目上升到人生的高度,它們能立馬看到它們負責的產品改進的效益,這是一個持續改進過程,良性的循環。

 

激勵機制

我堅信,程序員是一個偉大的職業,它們在代碼的世界里任意馳騁,構建屬于自己的羅浮宮,我不知道有多少人認為程序員最大的成就感來源于它所負責的軟件被用戶所認可、被廣泛的使用,但至少我是如此。

程序員希望被認可,不是通過悅耳動聽的歌聲,不是通過優美的詩歌,而是通過通宵達旦坐在電腦邊日夜奮戰編出來的代碼,我們需要通過codereview得到同事和老板的認可,需要通過可運行的程序得到客戶的贊揚,試問,如果連這些基本的途徑都不具備,我們還有什么方式來表達我們心中的成就感?第一次挫敗,第二次不會再像第一次那么努力和認真了,如果第二次也挫敗,那么第三次,我們寫代碼還有什么期待?

 

問題所有化

大家有沒有這樣的經歷?

發現有人早已經解決相同的bug;某些bug再次復現時,自己已經忘記了當初是怎么解決的;我們依賴其他的團隊成果,他們改變了實現方式,但并未告知我們,等到QA部門發現問題并費了半天時間追查到底是什么原因時,才發現是這個原因。

每次我發現一個很詭異很復雜很有趣的問題并解決之后,就會發郵件全組告知,還可以在周例會上一起討論更加完美的解決方法,我之所以這樣做,一方面是讓大家有個印象,另一方面是留一個記錄,更重要的是,在這個過程中,大家一起討論,一起出謀劃策,不但徹底解決了這個問題,而且也提高了團隊整體對項目代碼的熟悉程度。

其實,最最重要的原因是,每當我覺得這就夠了,我做的已經夠多了,準備忍耐著不共享不舒服的煎熬時,我會對自己說,你要寫一份心得發給全組哦,更加完美的解決這個問題吧。

 

團隊代碼質量氛圍,破窗效應

相信大家小時候都發出過“豪言壯志”什么的吧,說什么要改變世界,可是絕大多數都是被世界所改變了。不是我們不堅持,只是長大之后才發現當時的幼稚,也發現了,人和社會是分不開的,我們經常在受別人的影響,也經常無意中影響著別人,特別是我們程序員。

我時常在想,如果從一開始,代碼風格命名規則是嚴格統一的、每個字符都是通過了codereview的、單元測試覆蓋率是100%的,誰還敢不按規范出牌?寫bad code很容易,寫good code就很難,只要有一個人不按規范出牌,規律就會向著破窗效應發展。

========================================================================

snake1987同學總結的很好:

1.決定這個項目的人就是一個注重代碼質量的人,項目緊?沒事,他頂著,有破窗份子?沒事,他處理(或許是通過影響,多數人影響少數人)
2.在1的前提下有三種情況
a.新項目,從0開始,那太簡單了,一切按正規來辦
b.已經進行了一段時間的項目,這也簡單,重構,每個人都要參與
c.如果是已經維護了很久的項目呢?外企過來的同事說了一個很好的例子:外聘,該外企請了幾個很專業的人來把代碼一點點地重構了,然后帶著以前那伙人扎扎實實培訓了一通

 

希望那些以時間為借口但對軟件質量和代碼質量又要求很高的管理者或者項目經理應該好好看看這段話。

轉自:http://cantellow.iteye.com/blog/1040261

 本文由用戶 seailove 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!