快乐编程与极限编程
快樂編程與極限編程
編程是一項聰明人玩的游戲，它既是對智力的考驗，也是對習慣的考驗，智力的好壞取決于父母的基因，人們無從左右，但習慣的好壞卻是可以不斷培養。一項由美國芝加哥大學國家研究組織進行的綜合社會調查，公布了“十大最痛苦工作”排行榜，其中IT主管成了最讓人痛苦的職業。程序員如何才能讓自己的“痛苦”的職業不那么痛苦呢？
世間少有天才，所謂天才，只不過是把別人喝咖啡的功夫都用在工作上了。所以，對于絕大多數還稱不上天才的程序員而言，以下這些編程的好習慣都是無數前人智慧的結晶，具有相當意義的參考價值。
（1）?????? 估算解決問題所需要的時間。為自己定一個時間限制，如果在這期間未能解決問題，那就去尋求幫助，或到網上找答案，而不是嘗試去做“超級堆碼員”，因為很多問題，你很少會是這個世界上唯一一個遇到的人。站在別人的肩膀上，會讓你的形象變得高大、偉岸。
（2）?????? 理解編程語言的原理。三流的人才懂應用，二流的人才懂開發，一流的人才懂原理，要想學好一門編程語言，掌握語言的原理是必不可少的。各種語言之間存在相似之處，你所選擇的語言，你應該覺得“舒服”，并且能夠寫出有效（而且簡潔）的代碼。最重要的，讓語言去適應項目，反之亦然。
（3）?????? 重視，但不過于注重程序的設計模式。在大中型系統中，引入設計模式，往往能極大地提高系統研發的效率。但設計模式并非萬金油，有時候，寫一個簡單的算法，要比引入某種模式更容易。如果一個100行就能寫完的腳本，最終卻使用了8個類，10個接口，外加一大堆范式和標記符，結果導致97%的代碼不做任何事情，這種優化又有什么意義？在多數情況下，程序代碼應是簡單易懂，而不應該是老太婆的裹腳布—又臭又長。
（4）?????? 做好版本控制，并及時備份代碼。編碼時，最痛苦的事情不是有多少bug沒解決，而是突然停電了，一天的工作卻沒有保存。版本控制時，最好使用版本控制軟件。無論什么時候改變自己的程序，它們都會將其保存為.bak文件。
（5）?????? 對項目文件歸類保存?？梢园秧椖课募诺絊OURCE、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）?? 對待知識要刨根問底，要有“打破沙鍋問到底”的決心?！爸R就像內褲，看不見卻很重要”，在工作中，不能只知其然，不知其所以然，要不懈追求對細節一絲不茍的實干作風與敬業精神，而不是浮于表面，滿足于填鴨，滿足于考試交差或隨便應付，請記住，這個世界牛逼的人少，裝逼的人多，要從深層次去想其背后的思想和原理是什么。任何行業都有核心技術，掌握某一項核心技術，就可以讓你進入這個行業并在其中生存，反之僅僅淺嘗輒止，就會讓你遭遇失敗，抱怨不公。例如學會了C++面向對象程序設計，就應該弄清楚一個對象在編譯后，在匯編代碼中是如何被初始化的；就應該弄清楚這個對象的各個成員在內存中是如何存放的；就應該弄清楚當一個成員函數被調用時，編譯器在匯編代碼中加入了哪些額外的動作；就應該弄清楚虛函數的調用是如何實現的，而這些東西沒有人強迫你去弄懂，只有你自己。想得多了，自己的層次才有可能提高，如果只是停留在被動的接受，那很難有所提高。
（21）?? 盡可能復用成熟代碼。如果有現成的允許使用的經過測試的代碼或程序庫，并且有人維護或維護成本可以接受，程序員應該盡量使用現有代碼和庫來節省時間和開發測試成本。
（22）?? 多一份追求完美的執著。人是不完美的，但人們都在追求完美，程序也一樣，所以程序員要去追求完美。追求完美的人更容易出色、更具責任心，做事往往也顯得更專業。
（23）?? 不要心存僥幸，可能出錯的地方一定會出錯，偶爾發生偶爾不發生的問題就是大問題。所以，對于一些常見的問題，一定做到防微杜漸：每個變量都做初始化；每個函數都做聲明；引用每個參數都會做有效性檢查；在可能出錯的每個地方都會做邊界條件檢查等等。這樣開發出來的程序一定會穩固很多，就是出錯也會很容易修改。而一些沒經過正規培訓或是半路出家的所謂的高手，一般開發速度很快，三下兩除二的就開發完成了，結果很可能出現“功能大體實現，bug總是在變”的情況，最后花費很長的時間來修改代碼中的bug，總時間甚至會大大延期。而真正的高手，追求的境界是零缺陷代碼。
每個人的路都在自己的腳下，自己過得怎么樣，也只有自己心里明白。要想讓自己的編程變得快樂有趣，還是應該努力培養一些好的習慣。也許上面的這些好習慣，要想都能在實際生活中落實并不是一件容易的事情，恐怕只有“大?！眰儾拍芡耆龅搅?#xff0c;但只要你不斷地朝著那個方向努力，相信你也會在這個努力的過程中得到長足的進步。
總結
- 上一篇： 软件测试的常用方法
- 下一篇： 会议及作用篇--项目管理（二十一）终