目錄
如果你遇到過需要使用從未學過的語言去實現業務需求，或者你想快速入門一門新的語言，這篇文章值得你閱讀參考。本篇主要講述類似場景的方法論和我自己的實踐故事，大神可以繞着跑了。
1.那些應急上馬又不得不上的項目
有時候我們會突然接到緊急的任務，使用新的語言去實現一些軟件功能，亦或接到公司的轉型項目，比如原來是C#寫的，現在項目要求使用Java去寫。或者爲了工作快速入門一門新語言，我們第一需求就是完成它，更好地完成它。
現在需要實現這些業務場景需求，要麼去招聘新的人員、要麼使用現有程序員去學習新的語言去實現它。前提是這些業務需求場景是有時間限制的，必須在規定時間內完成。
這很爲難，招聘新的人員帶來公司的成本，需要對招聘的人負責人，如果這個項目做完了，人又多出來了，對公司來說很不划算。老闆自然不願意多投入。有時候招人不是你想招就能招，招聘一名與公司價值觀相一致的正常要半年，如果是啓用老員工去做這件事，可以增加現金激勵、升職加薪激勵，讓願意幹的員工去學習新的知識，員工自身可以增加項目經驗、學習到新的技能，公司也省了不少成本。那麼現在的問題是責任落到了這個員工身上，他面對的問題就是“如何快速的學習新的語言或技術，快速的應用到業務場景上呢？
我有幸做過不少類似的需求場景項目，激情奮戰之後，積累一些經驗，與大家共享，一些理論，我曾經與人探討，但大多是不同意見者。
2.編程語言的本質
我們使用某個編程語言，但絕不會超出這個語言本身的特性。甚至可以說，我們編寫軟件都是出自語言本身的API，我們只是搬運工。
我們的高級語言不論是PHP、ASP、C#、Java還是C++、Lue、Javascript等等他們都有哪些共性
1.在操作系統上運行
2.最終使用了二進制
從這條特性上來說，我們寫的所有的語言都是二進制的不同體現。“條條大路通羅馬”我們只是走了不一樣的路。
我們（使用語言的人）是使用某種語言，我們只是在使用語言，並不能發明某種語言之外的特性。
當我們編寫某種軟件功能的時候，假如我們編寫網絡通信，我們需要調用語言作者提供的接口來實現，或者藉助語言本身提供的底層技術來實現，但是我們並不能發明更多的接口或技術。我們是使用者，如果一種語言不支持多線程，那應該是語言不支持，而不是所在的環境不支持。
所以本質上來說，語言所有的特性對我們使用者來說，是已知的，可認知的可實現的。那麼最好的學習資料應該是語言開發者的提供的文檔和示例。
那麼是不是我們必須學習完所有的特性才能編寫軟件，只要寫過兩種語言以上的人來說，編寫軟件功能的邏輯是差不多。所以我們知道了如何編寫軟件，使用新語言就想堆積木一樣，你需要什麼的函數、方法你去庫裏找到它和它的使用事例，重要的是我們架構軟件的方法，而使用什麼樣的語言都是可選項。
3.編程語言的快速學習方法（實例）
總會有一些方法論，指導着我們學習進步。
2015年的時候，公司有個app，民生銀行的tpa軟件，那時候做ios app還是比較熱門的工作，招聘一個的成本還是相當的高，主要做完之後又不在需要這個崗位，我作爲公司骨幹，毅然挑起重擔，因爲老闆開心、自己也想了解下編寫ios app的快感。
3.1.基本語法的瞭解
對比學習法，我對object-c基礎知識做簡單的瞭解，當時買了本書，學習一門語言的基礎知識就是邊看邊寫邊練邊記錄成博客日誌。我大概花了兩週的時間完成所有基本知識的學習和事例的編寫。
這個過程中，我瞭解了object-c語言的基本編寫語法，熟練掌握了Xcode使用。
當然正如《極客時間》紅人耗子叔推薦的那樣，學習語言最好做類別學習，我是把IOS的object-c跟C#做對比（當時我最熟悉的是C#），瞭解學習起來就特別的快。
3.2.業務分析
瞭解了基本語法、IDE的使用後，就是對目標業務需求做一定分析，找到知識點，找些相關聯的開源的代碼下載下來訓練。
我做的是保險TPA軟件，就是保險理賠手機客戶端，主要涉及知識點包括：界面佈局、界面後臺的按鈕時間、頁面加載銷燬等事件、頁面跳轉、頁面間信息共享、以Json形式調用服務器接口、文件上傳、版本自動檢測升級等。只要寫過客戶端的（html客戶端、winform、linux桌面、java桌面等後面會分享）都知道這些都是構成客戶端軟件的基本要素。這些軟件非常容易找。例如類新聞客戶端、oschina的開源客戶端都是可以的。
我找到這些客戶端源碼，在本機先調試起來，然後依據記錄下他們的涉及到知識點的功能點在哪裏實現（注意我並不需要完全瞭解是怎麼做的）。
這個階段我花了大約2周的時間，有人說這麼短的時間，瞭解不夠，我並不需要了解學習每個代碼每個知識點，主要對軟件整體的知識、軟件的架構的瞭解，對比與已知軟件的異同。
3.3.項目架構與關鍵技術
就是開始架構階段，這個階段通常是我最花時間的階段，我通常考慮一個架構方式，需要通盤考慮他的可用性、可擴展性。這個階段我對關鍵技術進行實現。
例如當採用何種界面、代碼架構模式，我採用的是界面與代碼分離模式，沒有采用story模式，也沒有采用純代碼模式（後來第二版本我改成了純代碼模式）。這種mvc的架構模式最適合初學者特別是知道c#的mvc或者java的mvc的學習者，當時考慮了很多，怕自己一但定下來，後面遇到問題就很難做下去。
當時在架構階段我實現了：界面代碼的搭建模式、實體類的創建（因爲當時服務端的接口以及給出來了）、列表的實現、列表的分頁、文件的上傳、頁面的信息共享、頁面跳轉、基於http/https的post、get方法、json的編碼和解碼等主要關鍵點。
這個階段我花了3到4周的世界，大部分時間是在思考，實例代碼其實在上一個階段就有框架了，只是在這個階段把他填充時了。
3.4.項目編碼階段
這個時間UI已經出來了，高保真圖和切圖都已經做好了，我進入到真正的編碼階段，這個階段反而編碼很快，只是對我這個新手來說經常要去google搜索一些基本語法的使用，這看起來對oc編程者來說很可笑。
這個階段我大概花了1個月的時間。
項目編寫很順利，不會的去google查詢，遇到幾次閃退，有的就是xiaobai常常遇到的問題，有的到google多搜索幾次就解決了。
3.5.上線
測試很順利，因爲沒有多少東西，接口api已經是測試過的，客戶端沒有多少權限問題，剩下的是幾個不同尺寸的適配問題，感謝喬幫主，iphone設計的如此完美，適配已經不成問題。
最後順利交差。
方法的普適性
這些方法是否適合不同語言，我原來是寫ASP出生，我用這種方法直接應用到IOS App、Java桌面程序、Android客戶端、Linux QT主機監控程序等等。就我自己而言，不同語言間是具備普適性的。不同的人之間是否有用這種方法，我沒有特意去調查，但我堅信這套方法論是沒有問題。當然各個人的學習的方法各有不同的，本質上應該有相同的地方。
4.總結一下快速學習步驟
1.基本語法的瞭解，瞭解新語言的基本語法和相關知識，主要方法就是不停地取編寫示例、運行示例、寫博客或日誌。
2.業務分析，對當前的業務需求做技術點分析，可表述爲關鍵技術的實現（相對於技術小白的關鍵點），可以找到類似開源的項目或半成品下下來程序跑起來、日誌記起來。
3.項目架構與關鍵技術，尋找對本次項目的最有效架構，架構實際上跟具體語言是沒有關係的，但是也要考量語言實現的難易，並把關鍵技術統統實現預演。
4.項目編碼階段，這個階段跟其他項目的編碼階段沒有差異。
5.上線（後面步驟不寫了）
當然速成方法的優勢是快速應用，如果要深入瞭解繼續加強，總的方法就是多看、多練、多寫、多教（寫博客教別人用、寫教程給別人參考、錄視頻做分享等）。
我分享的方法只適用於應急場景，那些勇於專研某個領域的人，則不屑於這樣的方法論。
本文是2019年年度計劃的第002期博文，以此記錄共勉。
完！
往期博文(博客園鏈接）