分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

               

前言：

哲學家常思考的問題：" 我是誰？"" 我從哪裡來？"" 要到哪裡去？不只是哲學家，我想每個人都有自己對這三個問題的認知。如果我們要成為架構師，我們自己要面臨的三大問題：找準自己定位：我是誰？在哪裡？怎樣做好架構師：我要做什麼？如何搭建架構師知識體系：我該怎麼做？
 
這裡面就是做事方法論：目標（我要做什麼），方法（計劃）（我該怎麼做）,  執行/行動

我們研發人員發展的技術路徑(僅供參考)：

架構師不是通過理論學習可以搞出來的，不過不學習相關知識那肯定是不行的。總結構架師自我培養過程大致如下（僅供參考）:
1、架構師胚胎( 程式設計師:初級工程師) 
    學習的知識是語言基礎、計算機基礎理論、網路基礎，作業系統等相關基礎知識等，應該在大學完成。

2、架構師萌芽(高階程式設計師) 
     工作幾年後，熟悉分散式系統、高效能系統搭建。精通某種 開發語言，掌握架構設計能力和業務理解能力。熟練掌握各種設計模式以及具備一定運維能力。
3、架構師幼苗(資深工程師) 
    高階工程師是在技術深度上精通，資深需要在廣度上擴大知識面，熟悉多種開發語言。同時具備團隊管理經驗。
4、 軟體架構師的正式成型在於機遇、個人努力和天賦 軟體構架師其實是一種職位，但一個 程式設計師在充分掌握軟構架師所需的基本技能後，如何得到這樣的機會、如何利用所掌握的技能進行應用的合理構架、如何不斷的抽象和歸納自己的構架模式、如何深入行業成為能夠勝任分析、構架為 一體的精英人才這可不是每個人都能夠遇上的餡餅。
我們找好路徑以後，看看我們如何做??

1、走正確的路

  如果想成為一個架構師，就必須走正確的路，否則離目標越來越遠，正在辛苦工作的程式設計師們，你們有沒有下面幾種感覺？

     一、我的工作就是按時完成領導交給我的任務，至於程式碼寫的怎樣，知道有改進空間，但沒時間去改進，關鍵是領導也不給時間啊。

     二、我發現我的水平總是跟不上技術的進步，有太多想學的東西要學，Jquery用的人最近比較多啊，聽說最近MVC比較火，還有LINQ，聽說微軟又有Silverlight了……

     三、  我發現雖然我工作幾年了，除了不停的coding，Ctrl+c和Ctrl+V更熟練了，但編碼水平並沒有提高，還是一個普通程式設計師，但有人已經做到架構師了。

     四、工作好幾年了，想跳槽換個工作，結果面試的考官都問了一些什麼資料結構，什麼垃圾回收，什麼設計模式之類的東西，雖然看過，但是平時用不著，看了也忘記了，回答不上來，結果考官說我基礎太差。。。

有沒有，如果沒有，接下來就不用看了，你一定是大拿了，或者已經明白其中之道了，呵呵。

如果有，恭喜你，你進入學習誤區了，如果想在技術上前進的話，就不能一直的coding，為了完成需求而工作，必須在coding的同時，讓我們的思維，水平也在不停的提高。

寫程式碼要經歷下面幾個階段：

一 、你必須學習面向物件的基礎知識，如果連這個都忘了，那你的程式設計之路註定是在做原始初級的重複！

    很多程式設計師都知道類、方法、抽象類、介面等概念，但是為什麼要面向物件，好處在哪裡，要解決什麼問題？只是明白概念，就是表達不清楚，然後在實際工作中也用不上，過了一段時間，面向物件的東西又模糊了，結果是大多數程式設計師用著面向物件的語言做著面向過程的工作，因此要學習面向物件，首先應該明白麵向物件的目的是什麼？

面向物件的目的是什麼？

     開發語言在不斷髮展，從機器語言，到彙編，到高階語言，再到第四代語言;軟體開發方法在不斷髮展，從面向過程，面向物件，到面向方面等。雖然這些都在不斷髮展，但其所追求的目標卻一直沒變，這些目標就是：
   1.降低軟體開發的複雜度
   2.提高軟體開發的效率
   3.提高軟體質量：可維護性，可擴充套件性，可重用性等。

     其中語言的發展，開發方法的發展在1,2兩條上面取得了極大的進步，但對於第3條，我們不能光指望開發方法本身來解決。

提高軟體質量：可維護性，可擴充套件性，可重用性等，再具體點，就是高內聚、低耦合，面向物件就是為了解決第3條的問題。因此要成為一個好的程式設計師，最繞不開的就是面向物件了。

 

二、 要想學好面向物件，就必須學習設計模式。

     假定我們瞭解了面向物件的目的，概念了，但是我們coding過程中卻發現，我們的面向物件的知識似乎一直派不上用場，其實道理很簡單，是因為我們不知道怎麼去用，就像游泳一樣，我們已經明白了游泳的好處，以及游泳的幾種姿勢，狗刨、仰泳、蛙泳、自由泳，但是我們依然不會游泳。。。。

因此有了這些基本原則是不行的，我們必須有一些更細的原則去知道我們的設計，這就有了更基礎的面向物件的五大原則，而把這幾種原則更詳細的應用到實際中來，解決實際的問題，這就是設計模式，因此要學好OO，必須要學習設計模式，學習設計模式，按大師的話說，就是在人類努力解決的許多領域的成功方案都來源於各種模式，教育的一個重要目標就是把知識的模式一代一代傳下去。

     因此學習設計模式，就像我們在看世界頂級的游泳比賽，我們為之瘋狂，為之著迷。

 

三 學習設計模式

     正像我們並不想只是看別人表演，我們要自己學會游泳，這才是我們的目的所在。

當我們看完幾篇設計模式後，我們為之精神振奮，在新的coding的時候，我們總是想努力的用上學到的設計模式，但是經常在誤用模式，折騰半天發現是在脫褲子抓癢。。。

當學完設計模式之後，我們又很困惑，感覺這些模式簡直太像了，很多時候我們分不清這些模式之間到底有什麼區別，而且明白了設計過程中的一個致命的東西--過度設計，因為設計模式要求我們高擴充套件性，高重用性，但是在需求提出之初，我們都不是神，除了依靠過去的經驗來判斷外，我們不知道哪些地方要擴充套件，哪些地方要重用，而且過去的經驗就一定是正確的嗎？所以我們甚至不敢再輕易用設計模式，而是還一直在用面向過程的方法在實現需求。

 

四 學習重構

 

     精彩的程式碼是怎麼想出來的，比看到精彩的程式碼更加令人期待，於是我們開始思考，這些大師們莫非不用工作，需求來了沒有領導規定完成時間，只以設計精彩的程式碼為標準來開展工作？這樣的工作太爽了，也不可能，老闆不願意啊。就算這些理想的條件他都有，他就一開始就設計出完美的程式碼來了？也不可能啊，除非他是神，一開始就預料到未來的所有需求，那既然這些條件都沒有，他們如何寫出的精彩程式碼？

    Joshua Kerievsky在那篇著名的《模式與XP》〔收錄於《極限程式設計研究》一書）中明白地指出：在設計前期使用模式常常導致過度工程（over-engineering)。這是一個殘酷的現實，單憑對完美的追求無法寫出實用的程式碼，而「實用」是軟體壓倒一切的要素。

     在《重構-改善既有的程式碼的設計》一書中提到，通過重構（refactoring），你可以找出改變的平衡點。你會發現所謂設計不再是一切動作的前提，而是在整個開發過程中逐漸浮現出來。在系統構築過程中，你可以學習如何強化設計；其間帶來的互動可以讓一個程式在開發過程中持續保有良好的設計。

    總結起來就是說，我們在設計前期就使用設計模式，往往導致設計過度，因此應該在整個開發過程，整個需求變更過程中不斷的重構現在的程式碼，才能讓程式一直保持良好的設計，由此可見，開發過程中需要一直重構，否則無論當初設計多麼的好，隨著需求的改變，都會變成一堆爛程式碼，難以維護，難以擴充套件。所謂重構是這樣一個過程：「在不改變程式碼外在行為的前提下，對程式碼做出修改，以改程序序的內部結構」。重構的目標，就是設計模式，更本質的講就是使程式的架構更趨合理，從而提高軟體的可維護性，可擴充套件性，可重用性。

《重構-改善既有的程式碼的設計》一書也是Martin Fowler等大師的作品，軟體工程領域的超級經典鉅著，與另一鉅著《設計模式》並稱"軟工雙雄"，不可不讀啊。

 

五 開始通往優秀軟體設計師的路上

通過設計模式和重構，我們的所學和我們工作的coding終於結合上了，我們可以在工作中用面向物件的思維去考慮問題，並開始學習重構了，這就像游泳一樣，我們看完了各種頂級的游泳比賽，明白各種規則，名人使用的方法和技巧，現在是時候回家去村旁邊的小河裡練練了，練習也是需要有教練的，推薦另一本經典書叫《重構與模式》，引用他開篇的介紹，本書開創性地深入揭示了重構與模式這兩種軟體開發關鍵技術之間的聯絡，說明了通過重構實現模式改善既有的設計，往往優於在新的設計早期使用模式。本書不僅展示了一種應用模式和重構的創新方法，而且有助於讀者結合實戰深入理解重構和模式。

這本書正是我們需要的教練，值得一讀。

 

六 沒有終點，只有堅持不懈的專研和努力。

      經過了幾年的堅持，終於學會了靈活的運用各種模式，我們不需要去刻意的想用什麼模式，怎麼重構。程式的目標，就是可維護性，可擴充套件性，可重用性，都已經成了一種程式設計習慣，一種思維習慣，就像我們聯絡了幾年游泳之後，我們不用再刻意的去考慮，如何讓自己能在水上漂起來，仰泳和蛙泳的區別..... 而是跳進水裡，就自然的遊了起來，朝對岸游去。但是要和大師比起來，嘿嘿，我們還有很長的路要走，最終也可能成不了大師，但無論能不能成為大師，我們已經走在了成為大師的正確的路上，我們和別的程式設計師已經開始不一樣，因為他們無論再過多少年，他們的水平不會變，只是在重複造輪子，唯一比你快的，就是ctrl+c和ctrl+v。

正確的路上，只要堅持，就離目標越來越近，未來就一定會是一個優秀的架構師，和優秀架構師的區別，可能只是時間問題。

2、大牛的法寶

     原文：http://www.cnblogs.com/seesea125/archive/2012/03/30/2425281.html，

     接下來我們就要往這個方向努力。然而如唐僧去西天取經一樣，要歷經種種磨難，一路上打敗各種妖魔鬼怪才能繼續前行，所以唐僧取經，第一件事，就是招徒弟，遇見妖魔鬼怪就讓技術高超的徒弟打敗它，徒弟不聽話就念緊箍咒，徒弟也搞不定的妖怪，就請觀音菩薩搞定，這就是唐僧成功的法寶，沒法寶上路，看來我們會死的比較慘啊，哈哈。

    我們在通往架構師的路上，同樣會遇到各種各樣的問題，但不幸的是，沒有菩薩在暗中相助，要是有牛人相助你，那老兄你太幸運了，成功機率大大增加。但我們沒有牛人幫助，更沒有技術高超的徒弟一路保駕護航，關鍵招徒弟得開工資啊，我們還窮的自己還養不活呢，怎麼辦呢？乾脆自己動手，找幾件護身法寶，留著路上除妖之用。

    問題是從哪找呢？百思不得其解，俗話說思索不如搜尋，乾脆百度一把，看看牛人都是怎麼煉成的，找來找去，還真總結出幾個牛人身上的通用法寶，當然獨門絕技之類的就不拿了，太多那不動，呵呵。拿著這些法寶上路，嘿嘿，那我們就不是騎著白龍馬去西天了，我們騎著摩托去西天，那速度可要快多了。

 

法寶一：牛人愛惜自己的時間。

    時間就是金錢，時間就是生命，時間如同健康一樣，如果時間都沒有，那成功也就是浮雲了。所以牛人總是很愛惜自己的時間，總是在想辦法提高自己的做事效率。我突然想了起來，我QQ裡有幾個牛人，問問他們點經驗，結果大大出乎意料，個個不線上，好不容易發現個牛人線上，當然關係還不錯的，至少不會不給面子吧？於是就QQ說一句客氣話，“老兄，好久不見啊，最近在忙什麼呢？”，訊息發出去石沉大海，到第二天上QQ才收到一句回覆，“不好意思，昨忙，有事直接打電話”，言簡意賅，效率奇高，再想想我們這些普通人的時間真多，一聊天就是半天，搞不好還有N個QQ群在不停的彈窗……

    偶然看到一本書，《時間管理：小強升職記》，順便開啟看下，第一句話這麼說的，“前一種人用20%的時間完成了後一種人用80%的時間才能完成的事情，因此前一種人忙著考慮如何打發閒暇時間，後一種人則忙著煮方便麵和熬夜。

    假設上面說的真的，我初略算了算，如果一天工作時間8個小時，則牛人的效率，可能就1，2個小時就幹完了，這麼一算，牛人忙和一年，則等於普通人忙和了4，5年啊！法寶，這絕對是牛人致勝的第一大法寶，俗話說，唯有以快制慢，方能笑傲江湖，沒錯，東方不敗牛就牛在，速度快，快到你還沒出招就搞定你了。強大啊，這個法寶一定要隨身攜帶，哈哈。

    所以看了這本書後，我做的第一件事就是QQ關了，動不動就一閃一閃的，思路一直被打斷，這不是在浪費自己最大的資本--時間嗎？關了幾天，發現效率果然出奇的高多了，QQ真是害人不淺啊，當然愛惜時間，還有很多經驗，建議有空看看相關的書，受益不淺啊，嘿嘿。 

 

法寶二：牛人善於總結

     算了算我記得的牛人，包括古代的，孔子，老子，孫子，曹雪芹，魯迅。。。我想了一下，為什麼能記住他們呢，幾千年前來，轟動一時的人物應該年年有，代代有，但我們為什麼只記住了這些人？很容易想明白了，他們有個共同的特徵，就是總結自己的思想，寫成了書，並把這種思想傳承了下來，而那些身懷絕技但是祕而不傳，或者只傳近親的絕技，都在歷史的長河中慢慢消失了。

    再看看IT界的，蘇傑，寫了本《人人都是產品經理》，程傑，寫了本《大話設計模式》......，除了寫之外，他們還經常出沒於各大論壇，講座，想躲也躲不開啊......。

    看來牛人之所以牛，自己懂的多是一個因素之外，更重要的是把自己的知識總結下來，並努力推廣了。

    所以日常總結，隨身筆記一定是要做的，總結就是理解它，並且理解了還不要忘記它，時不時還翻回來看看，否則很多知識學習了又忘記了。總結這個法寶，一定要隨身攜帶。 

 

法寶三：牛人懂得專注

   

    有句古語是這麼說的：能夠到達金字塔頂端的動物只有兩種，一種是蒼鷹，一種是蝸牛。蒼鷹之所以能夠到達是因為它們擁有傲人的翅膀；而慢吞吞的蝸牛能夠爬上去就是認準了自己的方向，並且一直沿著這個方向努力。對人類而言，能夠於眾生中脫穎而出者實屬少數，這些人也可以看到：一種是資質優越、天生異稟，本就是成就大事的種子，這樣的人是少之又少，而且有些這樣的人還因不知學習而淪落了；另外一種人就是蝸牛一樣的人物了，早早就知道自己是常人，卻仍然立下鴻鵠之志，憑藉後天的堅忍和努力，同樣做出常人難以想象的成就。它是一種素質，更是一種能力。

    IT領域需要懂的太多了，運維、DBA，各種作業系統，各種語言......如果什麼都想學好，結果必然是什麼都略懂，但什麼都拿不出手，所以註定無所建樹，成不了牛人，而牛人是深刻明白這個道理，所以他們會選擇某一點最感興趣的地方，然後持之以恆的深專下去，最後達到了別人從未達到的高度，我們做IT程式設計的大部分人都是這也學那也學，簡歷上寫的什麼都是精通，其實這樣的人，卻不敢深問，深問了什麼都不懂，因此專注某一個技術領域，是走向成功的鐵定法則。

 

 

法寶四：牛人注重動手能力

 

    “紙上得來終覺淺，絕知此事要躬行”， 鄧小平最經典的一句話叫“摸著石頭過河”，毛主席也在實踐論上寫道：“理論若不和實踐聯絡起來，就會變成無物件的理論，同樣，實踐若不以理論為指南，就會變成盲目的實踐。” 

    看來牛人並不是坐在屋子裡成牛人的，而是在不斷的動手，在實戰中造就了牛人，也充分的說明了學習的終極目的--學以致用。所以我們學習時，一定要動手做，只學習不動手，是成不了牛人的啊。

 

     拿著這四件法寶去取經，就為成功增加了強有力的保障，並能達到事半功倍的效果。當然在路上多撿幾件隨身攜帶，那功力就會更強了，像007一樣，口袋裡總是需要什麼有什麼。法寶之重要，猶如練武的找到了降龍十八掌，乾坤大挪移之類的祕籍一樣，拿到手了就會成為武林至尊！

3、架構師都要懂哪些知識

Web架構師究竟都要學些什麼？具備哪些能力呢？先網上查查架構師的大概的定義，參見架構師修煉之道這篇文章，寫的還不錯，再查查公司招聘Web架構師的要求。 總結起來大概有下面幾點技能要求：

一、 架構師有優秀的編碼能力，解決開發人員無法解決的難題。

二、 架構師對系統的大資料容量高效能高併發高容錯的網站有架構設計和開發經驗。

三、 架構師對作業系統、資料庫、伺服器各種軟體使用的配置比較瞭解，比如Linux、Web負載均衡、反向代理、資料庫叢集、容災等比較瞭解。

四、 架構師對軟體開發過程有清晰明確的認識，也就是對軟體工程有有明確的認識，並能把需求進行分析、建模。

五、 架構師學習能力很強、接觸知識面要很寬廣、喜歡關注和接觸各種新的技術。

六、 架構師溝通能力很強。

七、 架構師對從事的行業的業務要有深刻的瞭解。

 

換個角度看看這些要求把：

 

第一條要求你是個優秀的程式設計師。

第二、第三條要求你要懂DBA，運維都需要懂的知識。

第四條要求你是個專案經理。

第五條要求你是個技術全才，不僅學的要深，還要學的廣。

第六條、第七條要求你熟悉公司業務人員、產品人員要懂的知識。

這個要求太高了，架構師就相當於戰爭中的司令員的位置，是整個團隊的核心和靈魂，這種技術要求甚至技術總監和CEO都不具備，唯一要求少點的就是管理能力，如果再具備管理能力，那就甚至能超過技術總監和CTO了，而中國不乏管理人才，怪不得有人總結說，中國沒有合格的架構師呢，也難怪，大概算一算，這種要求相當於一個人學6個人的知識，並且都能達到專業的水平，這就意味著你的領悟能力和學習能力，要高於常人幾倍！所以說，成為架構師確實需要天分啊。

 

成為優秀程式設計師，需要學好的知識：

1、 面向物件程式設計、UML畫圖、設計模式、程式碼重構

2、 常用ORM工具

3、  MVC,WCF,XMl, JQuery ，SQL以及效能優化

4、 FrameWork一些深入的知識

5、 高效能程式碼，比如靜態化，MemCached等手段。

6、 最好也瞭解一些其他語言，比如Java，PHP等。

 

成為DBA，需要學好的知識：

1、 常用資料庫，MSSQL、MySQL、Oracle，效能調優熟練，備份、負載均衡、叢集、容災熟練

2、 大資料量處理熟練

3、 各種資料庫監控軟體

 

成為運維，需要學好的知識：

1、 各種Web負載均衡的硬體，比如F5，軟體，比如Nginx等原理和配置

2、 反向代理加速，比如SquID等

3、 作業系統，Linux是必須懂的，各種好的工具都在Linux下。

4、 各種效能監控軟體。

 

成為產品和業務以及專案經理，需要學好的知識：

1、 溝通和理解能力。

2、 該行業和本公司的業務邏輯。

3、 軟體工程的知識。

4、 質量控制、進度控制、人員組織等。

 

看來想成為合格的Web架構師，需要學太多東西了，只有一條路可走--持續不斷的修煉和學習。

另外學習中，採用先深後廣的策略是明智的選擇，一門學深了，其他知識可能都會融會貫通，那樣比較的學起來會很快。否則可能陷入知識的海洋裡，沒準淹死了。

總體的看來，Web架構，分為伺服器架構和程式架構兩個方面的架構，一般的Web架構師還是偏向程式架構，因此學好語言，程式架構是基礎，學好了這些，做一個合格的架構師沒大問題，畢竟DBA，運維的東西在公司都有專業的人在幹。

所以深度還是要深入學習程式設計的知識、軟體架構知識，有了這個基礎後，Web架構師應該在大資料量、高併發、高負載、以及高容錯方向再有所瞭解和涉及，再返過來促進我們對軟體架構的思考，這種深-廣-深-廣的模式是我們學習的方法，只要堅持不懈努力幾年，做真正合格的Web架構師是沒大問題的。

另外由於學東西太多，在學習中也要和其他架構師多交流、共同進步，多參考其他架構師的傑作，是很明智的選擇。

原文地址：http://www.cnblogs.com/seesea125/archive/2012/03/30/2425281.html

對原文一些內容做一些修改，感謝作者，尊重原著。

           

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow