趙云大喝一聲，挺槍驟馬殺入重圍，左沖右突，如入無人之境。那槍渾身上下，若舞梨花；遍體紛紛，如飄瑞雪。

趙云是所有歷史人物中我最喜歡的一個，如果放到現代，他走了it的道路，一定可以成為一個編程高手。為什么？

其實古時打仗也是一門技術活，需要有勇有謀，跟it沒有什么太大的區別。打仗要修身、修技、修器才能左沖右突，如入無人之境，同樣做it也要修身、修技、修器，才能高效編程，如入無人之境。

高效編程的修煉

何謂修身、修技、修器？

• 修身，古今都是修煉自己的體魄和思維，使自己體魄強健，思維敏捷

• 修技，古代修煉自己的武藝和兵法，如今修煉自己的設計方法、模式及設計技能

• 修器，子龍左手青釭劍，右手亮銀槍，跨下白龍馬，一身白盔白甲，帥到爆炸！如今我們左手xmind，右手eclipse，uml在腳下，也是無比瀟（ku）灑（bi）。

待修到山花爛漫時，需求叢中過，片葉不粘身。

修身

修身是一個很大的話題，要講個幾天幾夜了，所以我們就先略過。當然修身之后，可以從思維的高度上確定大的方向，但是大家的看了題目也不太會關心如何修身，so pass！后面省略十萬字，我可真夠高產的（稿費不要省略啊，我不怕麻煩）。

修技

古時修技都是有秘笈，而且必須有獨門功法歷盡千辛萬苦才能修煉成功。如今好了，有很多書和視頻，還有我這種讓人醍（提）醐（壺）灌頂的好教程，所以你只需要少吃一點苦就可以練成了，我算算啊——-你大概歷盡999辛9999苦就可以了，看少了1點吧。

• 不明真相群眾：揍他，揍他小舅子

• 作者：亞美蝶，揍我不行，揍我小舅子可以。

• 作者：哎呀，輕點

• 作者：呀，輕點

• 作者：輕點

• 作者：點

• 不明真相群眾：KO

• 作者：請讓我講完，55555

修技大概分為：

• 面向對象、面向過程設計方法（心法）

• uml設計語言（秘笈）

• 設計模式、重構、xx最佳實踐（先輩實戰經驗）

• 單元測試（對打練習）

等修煉到10成功力，才可以繼續修煉終極秘笈架構模式，否則會走火入魔、oom。

• 不明真相群眾：等一下，我們在討論高效編程，你跟我們講什么面向對象，你瘋了吧！揍他，揍他小舅子

• 此處同上，省略100字。

• 作者：請讓我講完，55555

其實看到題目我首先想到的也是編程工具的使用，以及快捷鍵的使用。后來我發現那只占我浪費時間的5%-10%，真正浪費我們時間的是：

• 老板說：哎呀，我們方向錯了，我們重新搞一個方向吧！（產品、碼農、測試心中下起了大雪，好冷，好累，我要屎了，砍死他…….看在錢的份上，先饒你一條狗命）

• 產品說：哎呀，需求不是這個樣子的，我們應該改成這樣………（碼農心中一萬只草泥馬跑過）

• 測試說：哎呀，這么多bug，快來改（測試心中鄙視的看著你，菜鳥，切！）

• 碼農說：哎呀，這樣地方設計不合理，我們需要重構。哎呀，這樣地方if else好多，我暈了。哎呀，這地方出異常了。哎呀，…..（哎你媽個頭啊!你有完沒完啊!）

•  

• 不明真相群眾：好像很有道理的樣子，先饒你一條狗命

• 作者：謝謝大俠

其實我們看看這些問題怎么來解決：

• 老板的問題，我先不解釋了，老板最英明！（老板在后面看著呢）。《精益創業》《精益創業實戰》，好像有點修身的味道。

• 產品的問題，有些錯誤的地方，你在設計時會感覺不對，那就問題所在。但是有些就是方向性的問題，這可以歸結到第一個問題。（產品說：這個鍋甩的好）《head first 面向對象分析與設計》《領域驅動設計》

• 測試的問題，單元測試起碼保證最基礎的代碼的正確性，上面集成測試，功能測試，系統測試才有可能正確。《單元測試之道》《測試驅動開發》

• 碼農的問題，先輩的經驗先學會，你就不會有那么多需要哎呀的地方。《重構》《Head first 設計模式》《代碼大全》，《Effective java》《代碼整潔之道》

秘笈已經放在后面了，請大家笑納！

• 不明真相群眾：好像還不錯，看在秘笈的份上先饒你一條狗命

• 作者：謝謝大俠

• 不明真相群眾：等等，終極秘笈沒有給

• 作者：sorry，各位大哥，《企業架構模式》，《大型網站技術架構》

修器

有小說講到高手已經不需要好的武器，一片葉子，一根枯枝，都可以分分鐘秒掉一片人。還有人謠傳，最牛逼的開發人員只使用文本編輯器，巴拉巴拉，一個操作系統開發出來了。

我只問一個問題，你用不用電器，你開不開車？

如果用，那就繼續，如果不用，那就閃開，騙子，你怎們看到我的文章的。

人活著的目的就是為了讓更多人的獲得更多的自由，時間自由，財務自由，人身自由。開發工具的目的是為了，讓你更快的完成一些重復的繁瑣的事情，讓你有時間去享用你的自由。所以盡情的使用工具，工欲善其事，必先利其器。

• 不明真相群眾：好偉大

• 作者：我只是說說而已，不要打我。

要高效，必須把最常用的工具修煉到極致：

1. 操作系統，盡量選擇蘋果、Ubuntu，window次之，當你用命令行爽呆的時候就明白了。當然如果用windows，盡量使用快捷鍵操作。

2. 開發工具，eclipse 快捷鍵，統一的格式，重構功能 ，findbug，checkstyle

3. 自動化編譯發布，使用hudson進行定時自動化打包發布

4. 其他工具，xmind 快捷鍵

5. 時間管理，番茄工作法 控制時間

6. 好的框架，定義好一個好的框架，可以節省大量開發時間。具體內容詳見我前面講到的框架。

7. 代碼生成器，輸入uml設計的類圖，自動生成相關的類，對于需要持久化的對象，可以實現從前到后的增刪改查的代碼。

實戰

產品獲得了一個用戶需求給到我，我通常是這樣做的：

1. 分析需求的合理性，并不是所有需求都是合理的，需要積極發現其中問題。發現的問題跟產品討論，如果所有問題都解決掉，才進行下一步。如果后面的開發建立在一個錯誤的需求上，所有開發都是然并卵。

2. 進行分析設計，至少形成uml的用例圖和類圖。對于關鍵復雜邏輯，確定是否可以通過設計模式解決。復雜流程需要畫出流程圖，如果狀態變化較多，還需要畫出狀態圖。在uml設計時，仍然會發現需求的問題，此時仍需要跟產品確定，直至所有問題解決掉，才進行一步。

3. 編碼實現，根據類圖自動生成相關代碼，省去了自己一個個再敲一遍的時間，前后端增刪改查等重復邏輯都已經有了，只需要寫具體的業務就ok了。

4. 編寫單元測試，對于自定義代碼，必須編寫單元測試。這樣后期修改代碼或者進行集成測試時，才會比較順暢。

5. 進行findbug，checkstyle自動檢查，系統自動化發布，如果出現問題郵件通知。

6. 自測，自己實現功能后，先按照需求自測一般，保證正確性。

7. 提交測試，發現bug及時修改，基本做到日結。

8. 自動化發布上線。

當然中間會盡量節省各種時間：

1. 快捷鍵操作

2. 番茄工作法，設置不被打擾時間，全神貫注的投入編碼

3. 3次以上重復的事情，就考慮實現自動化，比如 發布，代碼檢查，代碼生成

4. 代碼規范嚴格遵守，最優實踐嚴格遵守

團隊高效

其實編碼不是一個人的事情，團隊協作是必不可少的。團隊盡量采用如下管理方式：

1. 需求、設計集體參與，不需要再每人講解

2. 設計后進行分工，如果有新人就采取新老結合的結對編程，對復雜的代碼也采取結對編程。

3. 推行結果導向，從產品，需求，設計，開發等，不要白白浪費時間做無結果的事情

4. 代碼規范嚴格遵守，最優實踐嚴格遵守

5. 規范流程，不斷磨合各個環節人員，達到絲般順滑

6. 人員互備，不會出現單點

祝福

上面是我做軟件以來的一些感悟，當然一千個人眼中有一千零一個哈姆雷特，每個都會有最適合自己的方法，希望大家都早日修成自己的高效編程之道。