編程是一項聰明人玩的游戲，它既是對智力的考驗，也是對習(xí)慣的考驗，智力的好壞取決于父母的基因，人們無從左右，但習(xí)慣的好壞卻是可以不斷培養(yǎng)。一項由美國芝加哥大學(xué)國家研究組織進行的綜合社會調(diào)查，公布了“十大最痛苦工作”排行榜，其中IT主管成了最讓人痛苦的職業(yè)。程序員如何才能讓自己的“痛苦”的職業(yè)不那么痛苦呢？

世間少有天才，所謂天才，只不過是把別人喝咖啡的功夫都用在工作上了。所以，對于絕大多數(shù)還稱不上天才的程序員而言，以下這些編程的好習(xí)慣都是無數(shù)前人智慧的結(jié)晶，具有相當(dāng)意義的參考價值。

 

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

 

（2）理解編程語言的原理。三流的人才懂應(yīng)用，二流的人才懂開發(fā)，一流的人才懂原理，要想學(xué)好一門編程語言，掌握語言的原理是必不可少的。各種語言之間存在相似之處，你所選擇的語言，你應(yīng)該覺得“舒服”，并且能夠?qū)懗鲇行Вǘ�且簡潔）的代碼。最重要的，讓語言去適應(yīng)項目，反之亦然。

 

（3）重視，但不過于注重程序的設(shè)計模式。在大中型系統(tǒng)中，引入設(shè)計模式，往往能極大地提高系統(tǒng)研發(fā)的效率。但設(shè)計模式并非萬金油，有時候，寫一個簡單的算法，要比引入某種模式更容易。如果一個100行就能寫完的腳本，最終卻使用了8個類，10個接口，外加一大堆范式和標(biāo)記符，結(jié)果導(dǎo)致97%的代碼不做任何事情，這種優(yōu)化又有什么意義？在多數(shù)情況下，程序代碼應(yīng)是簡單易懂，而不應(yīng)該是老太婆的裹腳布—又臭又長。           

                     

（4）做好版本控制，并及時備份代碼。編碼時，最痛苦的事情不是有多少bug沒解決，而是突然停電了，一天的工作卻沒有保存。版本控制時，最好使用版本控制軟件。無論什么時候改變自己的程序，它們都會將其保存為.bak文件。

 

（5）對項目文件歸類保存。可以把項目文件放到SOURCE、HEADERS、MAKE、EXES等不同的文件夾中。如果工程包含多個源文件，則可以建立一個README文件，注明每個源文件、數(shù)據(jù)文件、臨時文件以及日志文件(如果有的話)的作用。還可以注明編譯和運行步驟。

 

（6）動手編碼之前，先做好分析和設(shè)計。項目開始之初，不要急于編碼，而應(yīng)該做好詳細(xì)的需求與設(shè)計。做需求確實很難，不然也不會有程序員發(fā)出這樣的牢騷：需求無非兩種，一種是“你妹的，這還用做？”，另一種是“你妹的，這也能做？”不僅如此，實踐和分析設(shè)計過程也可存在很大的矛盾，但是好的分析會避免過早走向一個錯誤的方向，好的設(shè)計可以避免混亂，否則，很有可能忙活了很久，最后發(fā)現(xiàn)方向錯了或是架構(gòu)錯了，需要不斷的監(jiān)測、修改與調(diào)試，甚至是完全推翻以前的工作，重新設(shè)計，工作的成果看起來更像一個三歲小孩的涂鴉，而不是意見藝術(shù)作品，“撿了芝麻卻丟了西瓜”。永遠(yuǎn)不要在沒有任何設(shè)計的前提下就開始編碼，除非所編代碼不重要。

 

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

 

（8）優(yōu)化代碼。優(yōu)雅的代碼非常的易讀，所以如果時間允許，應(yīng)該盡可能地優(yōu)化代碼，對時間和空間進行合理分配與使用。之前聲明的一些變量，現(xiàn)在可能沒用了。同樣，并不依賴循環(huán)的一些聲明可以移到循環(huán)模塊之外去。否則后續(xù)開發(fā)或是技術(shù)提供會比較困難。但也需要注意，優(yōu)化后的代碼并不是越簡短越好，用的語法越偏僻越好，因為晦澀的代碼，維護成本會非常高，而且好的代碼不但要實現(xiàn)功能，更要好維護，最好是A寫的代碼讓B能很輕易的理解和修改。

 

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

 

（10）使用輸出日志。打印輸出函數(shù)可以跟蹤變量的執(zhí)行，但頻繁地插入打印會使得屏幕的輸出很亂，而寫一個日志函數(shù)，可以保證 Debug 的時候的輸出以一種統(tǒng)一的，可管理的方式出現(xiàn)，這樣在最后發(fā)布穩(wěn)定版本的時候，只需要簡單的幾行命令就可以從代碼中剔除所有的日志打印行。

 

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

 

（12）回顧代碼。在看到自己以前的代碼時，通常會有兩種矛盾不同的想法：第一種：我怎么寫了這么爛的代碼；第二種，我寫的代碼還是挺有成就感的。其實，經(jīng)�；仡櫼郧暗拇�碼，往往會觸發(fā)新的想法，以及對以前編碼更深層次的思考。

 

（13）編碼不能想當(dāng)然，任何時候都要嚴(yán)謹(jǐn)。一個簡單的項目，表面上看可能可以輕松完成，其實不然，一個使用Microsoft Access的、只有3個頁面的網(wǎng)站，最后很有可能會變成一個有30個頁面并使用SQL Server作為數(shù)據(jù)庫的網(wǎng)站。所以除非有一個類、組件或者一段已經(jīng)寫好的代碼，并且在現(xiàn)有的項目已經(jīng)測試通過，否則，切不可掉以輕心。

 

（14）任何軟件都會有BUG。BUG像幽靈一樣，它是永遠(yuǎn)也改不完的，所以關(guān)鍵是要修復(fù)嚴(yán)重的、影響業(yè)務(wù)的、顯眼的Bug。一個軟件項目，參與的人數(shù)越多，并不代表軟件可靠性越好，相反，“人多手雜”，而且需求越變更，潛在的Bug會越來越多，很多時候，也許只是修改了一行代碼，其很有可能影響到很多關(guān)鍵流程的執(zhí)行。

 

（15）養(yǎng)成耐心、冷靜的好習(xí)慣。作為一名程序員，不能像普通人一樣被計算機掌控，而應(yīng)該作為計算機的主人，去掌控計算機。所以，一定要有足夠的耐心，當(dāng)程序運行不正確時，要冷靜下來，站在計算機的角度去看問題、分析問題。

 

 

（16） 遵循編程規(guī)范。例如“==”與“=”的區(qū)別；合理使用縮進；使用循環(huán)和條件語句時，先把左右括號對應(yīng)起來，然后再在里面寫其他語句；避免使用幻數(shù)（magic numbers）；使用有意義的變量和函數(shù)名稱，例如，使用‘radius’來代替圓的半徑，而不是用‘r’來表示。

 

（17）了解底層知識。優(yōu)秀的程序員不會只關(guān)注程序如何實現(xiàn)，而會深層次地剖析其實現(xiàn)機理，所以，程序員要對自己的操作系統(tǒng)和硬件要有足夠的了解，從CPU的執(zhí)行方法，到操作系統(tǒng)的運轉(zhuǎn)，到程序的編譯鏈接，到代碼的加載與運行，到程序的調(diào)試，最后到實現(xiàn)的功能這一整套的內(nèi)容，只有做到這樣，才能真正提高。

 

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

 

（19）要有創(chuàng)新的想法。對于大型企業(yè)而言，離開了創(chuàng)新，就等于失去了生命力，對于程序員個人而言，離開了創(chuàng)新，就等于停止了進步的腳步。雖然說天下學(xué)術(shù)全是抄，儼然一副“君不見創(chuàng)新項目一大堆，都被抄死化成灰”架勢，但是不能因此而放棄創(chuàng)新，因為大地不可以因為有畜牲吃草而不復(fù)生機，山泉也不會因為有王八偷水而不冒活水。所以，無論工作有多忙，生活有多艱辛，都要盡可能地保持有一顆生機靈動的心。因為這個東西是別人偷不走的，也是最大的財富。即使暫時不具備這個東西，也要在生活中用心經(jīng)營、好好培養(yǎng)。創(chuàng)新不一定要是改變?nèi)�世界的大舉，也不一定非得是世界上第一個做這件事的人，任何一種能改善生活的行為都可以認(rèn)為是一種創(chuàng)新。例如寫一個腳本去改變重復(fù)勞動或是采用什么方式解放自己。

 

（20）對待知識要刨根問底，要有“打破沙鍋問到底”的決心。“知識就像內(nèi)褲，看不見卻很重要”，在工作中，不能只知其然，不知其所以然，要不懈追求對細(xì)節(jié)一絲不茍的實干作風(fēng)與敬業(yè)精神，而不是浮于表面，滿足于填鴨，滿足于考試交差或隨便應(yīng)付，請記住，這個世界牛逼的人少，裝逼的人多，要從深層次去想其背后的思想和原理是什么。任何行業(yè)都有核心技術(shù)，掌握某一項核心技術(shù)，就可以讓你進入這個行業(yè)并在其中生存，反之僅僅淺嘗輒止，就會讓你遭遇失敗，抱怨不公。

例如學(xué)會了C++面向?qū)ο蟪绦蛟O(shè)計，就應(yīng)該弄清楚一個對象在編譯后，在匯編代碼中是如何被初始化的；就應(yīng)該弄清楚這個對象的各個成員在內(nèi)存中是如何存放的；就應(yīng)該弄清楚當(dāng)一個成員函數(shù)被調(diào)用時，編譯器在匯編代碼中加入了哪些額外的動作；就應(yīng)該弄清楚虛函數(shù)的調(diào)用是如何實現(xiàn)的，而這些東西沒有人強迫你去弄懂，只有你自己。想得多了，自己的層次才有可能提高，如果只是停留在被動的接受，那很難有所提高。

 

（21）盡可能復(fù)用成熟代碼。如果有現(xiàn)成的允許使用的經(jīng)過測試的代碼或程序庫，并且有人維護或維護成本可以接受，程序員應(yīng)該盡量使用現(xiàn)有代碼和庫來節(jié)省時間和開發(fā)測試成本。

 

（22）多一份追求完美的執(zhí)著。人是不完美的，但人們都在追求完美，程序也一樣，所以程序員要去追求完美。追求完美的人更容易出色、更具責(zé)任心，做事往往也顯得更專業(yè)。

 

（23）不要心存僥幸，可能出錯的地方一定會出錯，偶爾發(fā)生偶爾不發(fā)生的問題就是大問題。所以，對于一些常見的問題，一定做到防微杜漸：每個變量都做初始化；每個函數(shù)都做聲明；引用每個參數(shù)都會做有效性檢查；在可能出錯的每個地方都會做邊界條件檢查等等。這樣開發(fā)出來的程序一定會穩(wěn)固很多，就是出錯也會很容易修改。而一些沒經(jīng)過正規(guī)培訓(xùn)或是半路出家的所謂的高手，一般開發(fā)速度很快，三下兩除二的就開發(fā)完成了，結(jié)果很可能出現(xiàn)“功能大體實現(xiàn)，bug總是在變”的情況，最后花費很長的時間來修改代碼中的bug，總時間甚至?xí)�大大延期�?/span>而真正的高手，追求的境界是零缺陷代碼。

 

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