1、不要抱怨池凄，把注意力集中到解決問題上來抡驼。
2、了解清楚情況肿仑，比如團隊風格致盟，業(yè)務(wù)需求等，才動手編碼尤慰。
3馏锡、指出問題，當然伟端，更好的做法是禮貌一點杯道。
4、勇敢的說出實情荔泳，然后努力的去解決問題蕉饼。
5、用鄧公的話來說：與時俱進玛歌，開拓進取昧港。
6、提倡團隊成員之間的分享精神支子，比如搞個午餐會議（雖然聽起來很蛋疼）创肥。
7、拋棄舊習慣很難值朋，這需要勇氣叹侄，但是想要與時俱進，這是必須要做的昨登，想想改革開放前后的對比趾代。
8、對于一個問題丰辣，不滿足于表象撒强，不斷追問'為什么'禽捆，當然，也要問到點子上飘哨。
9胚想、把握開發(fā)的節(jié)奏，固定的時間做固定的事情芽隆，就像跳舞和演奏一樣浊服，一個節(jié)拍一動，充滿韻味胚吁。（不只是開發(fā)牙躺，適用于一切工作。）
10囤采、讓需求方?jīng)Q定需求述呐，而且描述越清楚越好，不然返修就是必然的蕉毯。
11乓搬、設(shè)計和開發(fā)交替進行，不要被一開始的設(shè)計圖牽著鼻子走代虾。
12进肯、根據(jù)需要選擇技術(shù)，問自己為什么需要這種技術(shù)棉磨，其中一個標準是使用新技術(shù)是否無需時間成本江掩。
13、使用版本管理工具乘瓤，以免引入破壞性的修改導致系統(tǒng)死掉环形。
14、子系統(tǒng)頻繁集成衙傀，有助于提早發(fā)現(xiàn)問題抬吟，以免后期隱藏的問題滾起雪球。
15统抬、從一開始就使用自動化部署應(yīng)用和環(huán)境火本，還是那個早期不做準備后期問題被滾雪球無限放大。
16聪建、需求的變化是人的天性钙畔，如果不想在最后軟件交付時才去面對用戶的變化，那么就該使用演示獲得頻繁的反饋金麸。
17擎析、小步前進，使用短迭代挥下、增量發(fā)布的方式開發(fā)大型系統(tǒng)叔锐，而且這也能避免跳票挪鹏，還能根據(jù)用戶的反饋及時修正方向见秽。
18愉烙、固定的項目報價有悖于敏捷開發(fā)的原則，合理的做法是短迭代解取，由用戶去評估每次迭代的成果并決定是否繼續(xù)做下去步责。
19、使用自動化單元測試工具禀苦，每次構(gòu)建和編譯時都會運行之前留下的測試代碼蔓肯，能幫助發(fā)現(xiàn)新修改帶來的錯誤。
20振乏、測試驅(qū)動開發(fā)蔗包，即：在編寫之前，先編寫測試用例去使用它慧邮，出現(xiàn)問題是就馬上針對問題去做開發(fā)调限。
21、使用持續(xù)集成工具误澳，周期性的從源碼控制系統(tǒng)中取得代碼耻矮，并運行代碼。這種方式能夠幫助發(fā)現(xiàn)不同平臺（操作系統(tǒng)）下的兼容問題忆谓。
22裆装、使用FIT，即集成測試框架倡缠，使用戶參與到驗收測試的用例設(shè)計上來哨免。
23、度量本次工作的時間花費昙沦，如果有錯誤琢唾，那么在下一次度量的時候就有了修改的依據(jù)。
24桅滋、傾聽真實用戶的聲音慧耍，查看一下找出真正的問題所在。
25丐谋、代碼要清晰地表達意圖芍碧，比如說使用枚舉來代替不明意義的數(shù)字，應(yīng)該努力的增加代碼的表現(xiàn)力号俐。
26泌豆、保持良好的命名規(guī)范，使用代碼來進行溝通吏饿，必要時加上注釋踪危，但是也請不要添加無意義的注釋蔬浙。
27、動態(tài)的評估各種因素：性能贞远、成本畴博、可移植性等，然后做出取舍蓝仲，不要去追求不可達的“完美”俱病。
28、編程如開車袱结，不可能能一路踩著油門到達終點亮隙，使用增量編程的方式，分階段去添加新的特性進來垢夹。
29溢吻、代碼設(shè)計應(yīng)該保持簡單，在幾百行代碼中使用十幾個設(shè)計模式是不可取的果元。
30促王、保持代碼的高內(nèi)聚，意味著一個模塊內(nèi)部所有函數(shù)都是為了齊心協(xié)力完成同一個功能噪漾，這呼應(yīng)了第29條保持簡單硼砰。
31、劃分各自的職責范圍欣硼，封裝修改為命令题翰，封裝讀取為查詢，并設(shè)置一定的訪問控制防止意外發(fā)生诈胜。
32豹障、編程時需要更多的考慮程序語義，比如繼承要求子類和父類是is-a的關(guān)系焦匈，如果不是is-a的關(guān)系可以考慮用聚合的方式做代碼重用血公。
******33、可以把每日日報當做解決方案日志來做缓熟，碰到問題就把解決思路記錄下來并做成可搜索的方式累魔，這樣再次碰到時就能亡羊補牢。**********
34够滑、調(diào)高編譯器的提示級別垦写，把警告當做錯誤來處理，不要忽略它彰触。
35梯投、分離開模塊做單元測試，對發(fā)現(xiàn)的問題做逐個擊破。
36分蓖、拋出所有異常尔艇，除非你確實想好了怎么處理，不然與其讓問題藏著掖著不如在發(fā)生的時候爆發(fā)出來留個全尸么鹤。
37终娃、提供有用的錯誤信息給用戶，比如說：[問題摘要][詳細細節(jié)]午磁。
38尝抖、提倡“每日立會”，并回答三個問題：1迅皇、昨天有什么收獲？2衙熔、今天有什么計劃登颓？3、未來有什么障礙红氯？
39框咙、架構(gòu)師必須寫代碼，原理陣線的將軍難以成為合格的戰(zhàn)役指揮者痢甘。
40喇嘱、實行代碼集體所有制，互相之間輪換維護各自的代碼塞栅，這將提高代碼的整體質(zhì)量者铜、易于維護、降低出錯率放椰。（極客與團隊中也提倡代碼不署名作烟，方便他人作改動。）
41砾医、與團隊分享知識和經(jīng)驗拿撩，知識并不像金錢，給了別人自己就沒有了如蚜，知識分享了之后就從一份變成了兩份压恒。
42、幫助他人可以不直接提供解決方法错邦，而且告知如何去解決問題探赫，相信別人也有這種能力，授人以魚不如授人以漁兴猩。
43期吓、向源碼控制系統(tǒng)提交代碼時，所有單元測試都是可以通過的，而且應(yīng)該與一個特定的任務(wù)或是一個bug的解決相關(guān)讨勤，并注有日志信息箭跳。
44、在代碼剛剛完成時潭千，做代碼復查能夠很好的發(fā)現(xiàn)大部分BUG谱姓，復查的方式可以是輪換復查或者結(jié)對編程。內(nèi)容可以是：1刨晴、可讀性 2屉来、明顯的錯誤 3、對其他部分的影響 4狈癞、重復代碼 5茄靠、可改進和重構(gòu)
45、積極的通報進展和問題蝶桶，不要等到時間截止的時候才來做這件事慨绳，也不要等別人來詢問進展，積極主動才夠敏捷真竖。
