優秀程式設計師必備的23條好習慣

十五樓亮哥發表於2015-05-28

           程式設計是一項聰明人玩的遊戲,它既是對智力的考驗,也是對習慣的考驗,智力的好壞取決於父母的基因,人們無從左右,但習慣的好壞卻是可以不斷培養。一項由美國芝加哥大學國家研究組織進行的綜合社會調查,公佈了“十大最痛苦工作”排行榜,其中IT主管成了最讓人痛苦的職業。程式設計師如何才能讓自己的“痛苦”的職業不那麼痛苦呢?

世間少有天才,所謂天才,只不過是把別人喝咖啡的功夫都用在工作上了。所以,對於絕大多數還稱不上天才的程式設計師而言,以下這些程式設計的好習慣都是無數前人智慧的結晶,具有相當意義的參考價值。

(1)估算解決問題所需要的時間。為自己定一個時間限制,如果在這期間未能解決問題,那就去尋求幫助,或到網上找答案,而不是嘗試去做“超級堆碼員”,因為很多問題,你很少會是這個世界上唯一一個遇到的人。站在別人的肩膀上,會讓你的形象變得高大、偉岸。

(2) 理解程式語言的原理。三流的人才懂應用,二流的人才懂開發,一流的人才懂原理,要想學好一門程式語言,掌握語言的原理是必不可少的。各種語言之間存在相似之處,你所選擇的語言,你應該覺得“舒服”,並且能夠寫出有效(而且簡潔)的程式碼。最重要的,讓語言去適應專案,反之亦然。

(3) 重視,但不過於注重程式的設計模式。在大中型系統中,引入設計模式,往往能極大地提高系統研發的效率。但設計模式並非萬金油,有時候,寫一個簡單的演算法,要比引入某種模式更容易。如果一個100行就能寫完的指令碼,最終卻使用了8個類,10個介面,外加一大堆正規化和標記符,結果導致97%的程式碼不做任何事情,這種優化又有什麼意義?在多數情況下,程式程式碼應是簡單易懂,而不應該是老太婆的裹腳布—又臭又長。

(4) 做好版本控制,並及時備份程式碼。編碼時,最痛苦的事情不是有多少bug沒解決,而是突然停電了,一天的工作卻沒有儲存。版本控制時,最好使用版本控制軟體。無論什麼時候改變自己的程式,它們都會將其儲存為.bak檔案。

(5)  對專案檔案歸類儲存。可以把專案檔案放到SOURCE、HEADERS、MAKE、EXES等不同的資料夾中。如果工程包含多個原始檔,則可以建立一個README檔案,註明每個原始檔、資料檔案、臨時檔案以及日誌檔案(如果有的話)的作用。還可以註明編譯和執行步驟。

(6)動手編碼之前,先做好分析和設計。專案開始之初,不要急於編碼,而應該做好詳細的需求與設計。做需求確實很難,不然也不會有程式設計師發出這樣的牢騷:需求無非兩種,一種是“你妹的,這還用做?”,另一種是“你妹的,這也能做?”不僅如此,實踐和分析設計過程也可存在很大的矛盾,但是好的分析會避免過早走向一個錯誤的方向,好的設計可以避免混亂,否則,很有可能忙活了很久,最後發現方向錯了或是架構錯了,需要不斷的監測、修改與除錯,甚至是完全推翻以前的工作,重新設計,工作的成果看起來更像一個三歲小孩的塗鴉,而不是意見藝術作品,“撿了芝麻卻丟了西瓜”。永遠不要在沒有任何設計的前提下就開始編碼,除非所編程式碼不重要。

(7)多向其他優秀程式設計師學習。你有一個蘋果,我也有一個蘋果,我們交換蘋果,你我還是有一個蘋果;你有一種思想,我也有一種思想,我們交換思想,你我就有了兩種思想。其實,一個人能走多遠,要看他與誰同行;一個人有多優秀,要看他有誰指點;一個人有多成功,要看他有誰相伴,更何況“一山總比一山高”。休息放鬆固然重要,但需要適可而止,生命不息,奮鬥不止,尤其是年輕的時候,更是如此。時間的強大是不可逆轉,再繁華的都會歸於塵土,與其把大把大把的時間浪費在打dota、玩三國殺或是無聊發呆上,還不如與其他優秀程式設計師坐在一起邊喝咖啡邊交流或是研究他們編寫的程式碼,吸收他們的經驗轉化為自己所用。在與這些人的溝通中,學習他們解決和自己相同的任務時所使用的方法,在此過程中所學知識可能會幫你省下幾個星期的時間。我們不贊成與臭棋佬下棋,棋會越下越臭的觀點,但不可否認這樣一個事實:和什麼樣的人在一起,就會有什麼樣的人生,和勤奮的人在一起,你不會懶惰;和積極的人在一起,你不會消沉;與智者同行,你會不同凡響;與高人為伍,你能登上巔峰。

(8)優化程式碼。優雅的程式碼非常的易讀,所以如果時間允許,應該儘可能地優化程式碼,對時間和空間進行合理分配與使用。之前宣告的一些變數,現在可能沒用了。同樣,並不依賴迴圈的一些宣告可以移到迴圈模組之外去。否則後續開發或是技術提供會比較困難。但也需要注意,優化後的程式碼並不是越簡短越好,用的語法越偏僻越好,因為晦澀的程式碼,維護成本會非常高,而且好的程式碼不但要實現功能,更要好維護,最好是A寫的程式碼讓B能很輕易的理解和修改。

(9)加強測試。測試的重要性並不亞於開發,所以要非常注重程式自測試。測試時,一般使用工具為主,人工為輔的策略,工具包括用單元測試,assert語句,程式碼測試容器,人工指用 print 和debugger 一行一行跟蹤。

(10)使用輸出日誌。列印輸出函式可以跟蹤變數的執行,但頻繁地插入列印會使得螢幕的輸出很亂,而寫一個日誌函式,可以保證 Debug 的時候的輸出以一種統一的,可管理的方式出現,這樣在最後釋出穩定版本的時候,只需要簡單的幾行命令就可以從程式碼中剔除所有的日誌列印行。

(11)檢查程式碼。程式碼要經常檢查(包括自查和其他同事檢查)。在提交程式碼前,找個同事一起坐下來,向他解釋程式碼做了哪些修改。這樣做的過程中通常能夠發現程式碼中的錯誤,而不需要同事說一句話。這比自己審查自己的程式碼要有效的多。將程式碼的bug發現的越早,成本越低。

(12)回顧程式碼。在看到自己以前的程式碼時,通常會有兩種矛盾不同的想法:第一種:我怎麼寫了這麼爛的程式碼;第二種,我寫的程式碼還是挺有成就感的。其實,經常回顧以前的程式碼,往往會觸發新的想法,以及對以前編碼更深層次的思考。

(13)編碼不能想當然,任何時候都要嚴謹。一個簡單的專案,表面上看可能可以輕鬆完成,其實不然,一個使用Microsoft Access的、只有3個頁面的網站,最後很有可能會變成一個有30個頁面並使用SQL Server作為資料庫的網站。所以除非有一個類、元件或者一段已經寫好的程式碼,並且在現有的專案已經測試通過,否則,切不可掉以輕心。

(14)任何軟體都會有BUG。BUG像幽靈一樣,它是永遠也改不完的,所以關鍵是要修復嚴重的、影響業務的、顯眼的Bug。一個軟體專案,參與的人數越多,並不代表軟體可靠性越好,相反,“人多手雜”,而且需求越變更,潛在的Bug會越來越多,很多時候,也許只是修改了一行程式碼,其很有可能影響到很多關鍵流程的執行。

(15) 養成耐心、冷靜的好習慣。作為一名程式設計師,不能像普通人一樣被計算機掌控,而應該作為計算機的主人,去掌控計算機。所以,一定要有足夠的耐心,當程式執行不正確時,要冷靜下來,站在計算機的角度去看問題、分析問題。

(16) 遵循程式設計規範。例如“==”與“=”的區別;合理使用縮排;使用迴圈和條件語句時,先把左右括號對應起來,然後再在裡面寫其他語句;避免使用幻數(magic numbers);使用有意義的變數和函式名稱,例如,使用‘radius’來代替圓的半徑,而不是用‘r’來表示。

(17)瞭解底層知識。優秀的程式設計師不會只關注程式如何實現,而會深層次地剖析其實現機理,所以,程式設計師要對自己的作業系統和硬體要有足夠的瞭解,從CPU的執行方法,到作業系統的運轉,到程式的編譯連結,到程式碼的載入與執行,到程式的除錯,最後到實現的功能這一整套的內容,只有做到這樣,才能真正提高。

(18)要聰明但不要“小聰明”。不反對走捷徑,但是一定要論證充分,否則,可能會產生很多潛在的bug。編碼中走捷徑也許能夠提高程式的可讀性以及效率,但是如果論證不充分,不能把所有的潛在問題考慮周全,很有可能犯了丟了西瓜揀了芝麻的錯誤。最好的論證方法是多和他人商量,請別人檢查自己的工作,將問題提早暴露。所以,不要為了做成某件事卻忽略過程的連帶效應,也許有一天你會為你當初的“小聰明”買單。

(19)要有創新的想法。對於大型企業而言,離開了創新,就等於失去了生命力,對於程式設計師個人而言,離開了創新,就等於停止了進步的腳步。雖然說天下學術全是抄,儼然一副“君不見創新專案一大堆,都被抄死化成灰”架勢,但是不能因此而放棄創新,因為大地不可以因為有畜牲吃草而不復生機,山泉也不會因為有王八偷水而不冒活水。所以,無論工作有多忙,生活有多艱辛,都要儘可能地保持有一顆生機靈動的心。因為這個東西是別人偷不走的,也是最大的財富。即使暫時不具備這個東西,也要在生活中用心經營、好好培養。創新不一定要是改變全世界的大舉,也不一定非得是世界上第一個做這件事的人,任何一種能改善生活的行為都可以認為是一種創新。例如寫一個指令碼去改變重複勞動或是採用什麼方式解放自己。

(20) 對待知識要刨根問底,要有“打破沙鍋問到底”的決心。“知識就像內褲,看不見卻很重要”,在工作中,不能只知其然,不知其所以然,要不懈追求對細節一絲不苟的實幹作風與敬業精神,而不是浮於表面,滿足於填鴨,滿足於考試交差或隨便應付,請記住,這個世界牛逼的人少,裝逼的人多,要從深層次去想其背後的思想和原理是什麼。任何行業都有核心技術,掌握某一項核心技術,就可以讓你進入這個行業並在其中生存,反之僅僅淺嘗輒止,就會讓你遭遇失敗,抱怨不公。例如學會了C++物件導向程式設計,就應該弄清楚一個物件在編譯後,在彙編程式碼中是如何被初始化的;就應該弄清楚這個物件的各個成員在記憶體中是如何存放的;就應該弄清楚當一個成員函式被呼叫時,編譯器在彙編程式碼中加入了哪些額外的動作;就應該弄清楚虛擬函式的呼叫是如何實現的,而這些東西沒有人強迫你去弄懂,只有你自己。想得多了,自己的層次才有可能提高,如果只是停留在被動的接受,那很難有所提高。

(21)儘可能複用成熟程式碼。如果有現成的允許使用的經過測試的程式碼或程式庫,並且有人維護或維護成本可以接受,程式設計師應該儘量使用現有程式碼和庫來節省時間和開發測試成本。

(22)多一份追求完美的執著。人是不完美的,但人們都在追求完美,程式也一樣,所以程式設計師要去追求完美。追求完美的人更容易出色、更具責任心,做事往往也顯得更專業。

(23)不要心存僥倖,可能出錯的地方一定會出錯,偶爾發生偶爾不發生的問題就是大問題。所以,對於一些常見的問題,一定做到防微杜漸:每個變數都做初始化;每個函式都做宣告;引用每個引數都會做有效性檢查;在可能出錯的每個地方都會做邊界條件檢查等等。這樣開發出來的程式一定會穩固很多,就是出錯也會很容易修改。而一些沒經過正規培訓或是半路出家的所謂的高手,一般開發速度很快,三下兩除二的就開發完成了,結果很可能出現“功能大體實現,bug總是在變”的情況,最後花費很長的時間來修改程式碼中的bug,總時間甚至會大大延期。而真正的高手,追求的境界是零缺陷程式碼。

 

每個人的路都在自己的腳下,自己過得怎麼樣,也只有自己心裡明白。要想讓自己的程式設計變得快樂有趣,還是應該努力培養一些好的習慣。也許上面的這些好習慣,要想都能在實際生活中落實並不是一件容易的事情,恐怕只有“大牛”們才能完全做到了,但只要你不斷地朝著那個方向努力,相信你也會在這個努力的過程中得到長足的進步。

相關文章