最近在閱讀《程序員修煉之道–從小工到專家》，書中提出的很多實用性建議和提示，所有的建議和提示都能爲我在項目中節省很多時間，幫助我更快更高效的完成我的工作。我認爲作爲一個程序員這本書是必須擁有的。
1、我的源碼讓貓給吃了
—-在所有的弱點中，最大的弱點就是害怕暴露弱點
責任是你主動擔負的東西。你承若確保某件事情正確完成，但你不一定能直接控制事情的每一個方面。但我們犯錯誤，或者是判斷失誤時，我們應該提供各種選擇，不要找蹩腳的藉口。
不要說事情做不到，要說明能夠做什麼來挽回局面。
2、軟件的熵
—熵是指某個系統中的“無序”的集合
不要留着“破窗戶”（低劣的設計，錯誤決策、或是糟糕的代碼）不修。運行良好的系統一旦窗戶開始破裂，就相當迅速地惡化。
記得我在做一個項目需求時，把解析配置信息的功能實現放到了一個配置管理類中，當時【chaofan】跟我說，這樣做不合理，配置管理類的職責是負責加載和存儲配置，如果你帶頭把其他的功能實現放到該類，那麼，後續可能會有更多的人把與該類不相關的實現放進來，於是該類會不斷惡化，這就是“破窗戶”理論。
如果你發現你所在團隊和項目的代碼十分漂亮—-編寫整潔、設計良好，並且很優雅，你就很可能會格外注意不去把它弄髒。
3、石頭湯和煮青蛙
—— 做變化的催化劑
當我剛看到這個標題時，摸不清是什麼意思。石頭湯是什麼？跟煮青蛙又有什麼關係？
大多數軟件災難都是從微不足道的小事情開始的，大多數項目的拖延都是一天一天發生的。系統一個特性一個特性地偏離其規範，一個又一個的補丁被打在某段代碼上，直到最初的代碼一點沒有留下。常常是小事情的累積破壞了士氣和團隊。
【lvfei】多次跟我談到，我們做項目需求的時候不能像打補丁一樣，在項目上修修補補，這樣雖然能短時間解決需求，但卻會使項目越來越糟。就像青蛙感覺不到慢慢變熱的水，最終被煮熟一樣。
要持續不斷地觀察周圍發生的事情，而不只是你自己在做的事情。【lvfei】曾今也這麼跟我說過，多去了解別人做的需求，不要求你瞭解透徹，但你要知道該需求要達到的目標是什麼。這有利於自己對項目的全局把握。
4、足夠好的軟件
—–欲求更好，往往會把事情辦遭
現實世界不會讓我們製作出十分完美的產品，特別是不會有無措的軟件，但是我們可以訓練自己，編寫出足夠好的軟件。所有系統必須滿足用戶需求，才能取得成功。
無視用戶需求，一味地給程序增加新特性，或是一次又一次潤飾代碼，這不是有職業素養的做法。
今天了不起的軟件常常比明天更完美軟件更加可取，讓用戶及早的使用我們編寫的軟件，他們的反饋常常會把你引向更好的最終解決方案，不斷完善我們的產品。
不要因爲過度修飾和過去求精而毀損完好的程序，這有點畫蛇添足的味道，適得其反。
給你做一個選擇題
某公司有一個不完整的軟件，作爲用戶，你會：
A、等着他們清除所有bug，使用最完美的軟件
B、允許有某些bug，但是使用起來比較複雜
C、有缺陷，使用起來比較簡單。
5、你的知識產權
—– 知識上的投資總能得到最好的回報
早起的鳥兒有蟲吃，那早起的蟲子呢？
你的知識和經驗是最重要的職業財富。但是它們是有時效的資產，會變得過時的。
管理知識資產
（1）定期投資（作爲習慣）
（2）多元化投資 ———你知道的不同事情越多，你就越有價值。今天的熱門技術明天可能變得幾乎無用。不要把所有的技術雞蛋放到一個籃子裏。
（3）利用自己的資產獲取最大的回報
（4）週期性地評估和平衡資產
目標：
（1）每年至少學習一門語言。不同的語言以不同的方式解決相同的問題，通過學習若干不同的方法，可以幫助你拓寬你的思維，並避免墨守成規。
（2）每季度閱讀一本技術書籍。
（3）多閱讀非技術書籍
（4）試驗不同的環境
（5）學習溝通技巧，加強與周圍人的交流
如果你自己找不到答案，就去找出能找到答案的人，不要把問題擱在那裏。
詢問技巧：
確切地知道你想要問什麼，並儘量明確具體
小心而具體的組織你的問題，記住你是在求助別人，不要顯得好像是在要求對方回答。
組織到好問題後，聽下來，再找找答案。
6、交流
沒有有效的交流，一個好想法就只是一個無人關心的孤兒。
知道你想要說什麼: 簡略記下你要交流的想法，並準備好幾種把它們將清楚的策略。
瞭解你的觀衆：
做傾聽者：如果你想要大家聽你說話，你必須使用一種方法：聽他們說話
回覆他人：隨時通知別人，會讓他們更容易原諒你偶然的疏忽，並讓他們覺得你沒有忘記他們。
交流越有效，你就越有影響力
7、重複的危害
可靠的開發軟件、並讓我們開發更易於理解與維護的唯一途徑，是遵循DRY（Don’t Repeat Yourself）原則。
不可信任的註釋比完全沒有註釋更糟！
8、正交性
在計算機術語中，正交性表示某種不相互依賴性或是解耦性
提高生產率：改動得以局部化；促進複用；
降低風險：更容易尋找問題，使得系統更加健壯
項目團隊的管理也與正交性相關，如果團隊的組織有許多重疊，各個成員就會對責任感到困惑。
設計，模塊化、基於組件、分層。系統應該由一組相互不依賴的組件構成，每個組件的實現都不依賴於其他組件的功能。
讓你的代碼保持解耦；避免使用全局數據；避免編寫相似的函數。
9、曳光彈
項目永遠不會結束，總有改動需要完成，總有功能需要增加，這是一個漸進的過程！
10、純文本的威力
純文本的缺點：存儲純文本所需空間更多；解釋和處理純文本的計算代價更高
11、shell遊戲
GUI的好處是所見即所得，缺點是所見即全部所得！
當你想要組合一些命令，已完成一次查詢或者其他任務時，命令行要更加合適！
12、強力編輯
精通一種編輯器，選擇一種編輯器，徹底瞭解它，並將用於所有的編輯任務！
我使用許多不同的編輯器，但只使用其基本個性。那麼我需要選擇一種強大的編輯器，好好學習它。精通一種編輯器能大大的提高生產率和工作效率。在這方面【lvfei】教會了我很多，剛進項目組的時候，他就教會我使用編輯器的各種快捷鍵，分析數據時，教我如何使用正則表達式快速獲取需要的數據。
13、源碼控制
把整個項目置於源碼控制系統的保護之下具有一項很大的好處：你可以進行自動的和可重複的產品構建。
我們項目的源碼控制就是採用的svn，項目自動化集成採用的jenkins，Jenkins從svn拉代碼進行項目構建，非常方便非常好用。
14、調試
沒有人能寫出完美的軟件，所以調試肯定要佔用你大量的時間。要修正問題，而不是發出職責。
如果你目睹bug或者見到bug報告時的第一反應是“那不可能”，你就完全錯了。一個腦細胞都不要浪費在以“但那不可能發生”起頭的死路上，因爲很明顯，那不僅可能，而且已經發生了。
要抵制只修正你看到的症狀的急迫願望。要總是設法找出問題的根源，而不只是問題的特定表現。
找出問題的原因的一種非常簡單、卻又特別有用的技術就是向別人解釋它。向他人解釋問題時，你必須明確地陳述那些你在自己檢查代碼時想當然的事情。確實，當你跟別人解釋代碼時，可能問題就從屏幕上跳出來了。
如果沒有顯而易見的地方讓你着手查看，你總是尅依靠好用的老式二分查找。
在面對“讓人吃驚”的故障時，你必須意識到你的一個或更多的假設是錯的。不要因爲你“知道”它能工作而輕易放過與bug有牽連的例程或代碼。
如果bug是一些壞數據的結果，這些數據在造成爆發之前傳播通過了若干層面，看看在這些例程中進行更好的參數檢查是否能更早地隔離它。