多看上看的，寫的是一些開發中常常遇到的問題以及解決方案，整理出來，以xxx個習慣的方式呈現。
命名學的是《高效能人士的7個習慣》，岔開說一句，中文讀起來很有山寨雞湯感，其實內容都是不錯的。
內容上，對於剛開始開發的人會有不錯的指導作用，如果經驗不是很多的話，先照着做，然後在實踐中一點點去體會和修正也是不錯的。
對於有一些開發經驗的人來說，對於裏面的每一個小點，可能都瞭解甚至實踐很多，但是不妨從另外一個視角來看，就是系統性，起碼我個人來說，能集中的過一遍開發中涉及的方方面面，去反思和抽象，也很有收穫。這個文章裏也就從這幾個方面來看這些：
真實和事實爲大
在實際開發中，需要一直面向真實的結果，並在點點滴滴中警惕這一點，比如文中提到的：
- 癡迷於方法，而導致空做了很多動作（甚至很多可以說是標準實踐），最後真實的項目進度沒有進展
- 使用了大量的設計模式，導致問題並沒有以最高質量最高效的解決（包括運行效率和開發效率）
- 前期收集了客戶需求，隨着時間的變化，客戶的想法變了，或者市場情況變了，但依舊沒有做相應的調整
- 隨着時間的變化，計劃受到衝擊，去沒有做到實際的調整
所有這些可以說是有無窮多的變種，實際項目中也遇到大量的失敗案例.
就個人的經驗來看，原則性的始終要保持對這些問題的敏感是不錯的：
- 當前重要的問題是什麼
- 我們是否朝着正確的方向前進，在這些方向上進度如何
看起來並不難，這背後有兩個因素需要我們去深度注意：
- 面對事實謙卑的心–不要固執己見等等，錯了就是錯了，面對事實，儘可能的讓事情向好的方向去發展即可
- 對於真實情況的洞察
- 大量經驗的積累，反思，總結，向更優秀的人的學習。。。
- 把握合理的火候，不多不少
坦率，務實與行動
團隊需要有一個務實坦率的風格，能夠做到對事不對人，這個知易行難，大部分情況，少非議別人的失誤，是一個職場生存之道，不管多少人旗幟鮮明的反對”會做人“這一點，在一個一般性團隊中，務實坦率就是非常的困難，但就個人所見這不是不可能。
引用查理芒格的反向說法：這的確是人之常情，但是如果你能克服這一點，你或你的團隊就是會有長足的進步。
所以，團隊一旦邁出了坦率與務實這一步，接下來就會迎來下一個進展，更容易面向真實的情況，比如書中提到的：
不能讓不寫代碼的人擔任架構師：實際情況中的確有，因爲種種原因，一個人掌握着項目的技術方向，但是自己卻不寫代碼，不寫代碼就會導致代碼能力和判斷力的穩步下降，再到後面，也不敢寫了，身居要職，寫出讓大家嘲笑的代碼怎麼辦？
無懼錯誤，只有不做事的人纔不會犯錯誤，大家平和的看待，理性的對待就好
行動勝過千言萬語
分而治之
分治這就是一個非常好的智慧，無需多言。
在實踐中的例子非常多：
- 持續集成，自動構建，自動測試，持續迭代
- 保持一直有一個可玩的版本（遊戲業如此，比如naughty dog，其他行業就是一個可用的版本）
- 工作中，把事情進行分解，然後一步步去實現和反饋。。。
論證分而治之爲何有效就沒必要了，實際項目中，有這兩個問題會影響大家去運用這個原則：
- 嫌麻煩：嫌一個個小東西的麻煩，最後導致一個大型的麻煩，甚至導致開發的東西被cancel掉，這其實是糖果實驗裏的那種情況（小孩給3個糖，5分鐘不吃就再給兩個，否則就不給），不到不得已不會行動這種情況，有時候或許是無解的。
- 自負：小東西沒勁，來個大的才爽，其實這個並不是一個絕對的不好，這樣可能會穩步的增加自己hold住大模塊的能力，但是具體事情上麼，個人覺得隨着實踐的增加，會發現這其實沒必要，引用漲工資對於喬丹”花哨運球“的說法：
”打籃球到後來，都是大道至簡，舉重若輕。艾弗森2001年都不像1997年那麼花哨了。爲什麼？用不着了。1997年總決賽第一場，喬丹最後那個絕殺。三分線外接球，右手拍了三下球，重心是往右走的；忽然換到左手，腳步調整了一下，是要起速或原地投籃的架勢；拉塞爾重心剛來的及側到喬丹左手邊，喬丹左手運一步，忽然急停跳投，拉塞爾都來不及起跳，絕殺。這個球裏，包含了向右走、向左走、原地投籃三個假動作選項，最後又用一記突破假動作釘住了拉塞爾下盤，最後一個投籃。
而且時間把握得剛剛好，球進鐘響。
什麼叫分寸、精確、老練，都在裏面了。
如果能這麼舉重若輕解決問題，爲什麼還要跟街頭鬥牛一樣，把自己腿擰成麻花來晃人呢？“
好的實踐
這裏就比較雜了，列一下：
代碼要簡潔優雅
文檔恰到好處，如果代碼可以自解釋，就無需文檔了
團隊協作，注意人與人之間的關係，禮貌，和把注意力集中在事情上（起碼第一優先級不應該是誰應該對此負責，誰應該被責備上）都是非常有力的
代碼review，這個好處非常多，一些頂尖的優秀公司是嚴格遵守這一條的，
review情況下，總的質量和開發時間（如果不review，可能更多地時間來處理問題等等），這個也是贊同的，但是實際情況中需要考慮本文的第一原則，項目的真實情況和重點所在，如果實現過程中，需要快速搞定（美術協作，過milestone決定項目生死），那麼先fast&dirty，然後回頭整理的借貸式開發是更優的選擇（http://blog.csdn.net/toughbro/article/details/22776277）
轉載自：http://blog.csdn.net/toughbro/article/details/46872877