無論是換工作，換團隊，還是換業務，我們都不可避免地會接觸新的專案，甚至可能接觸乙個大型的專案。很多人，包括我自己，在面對這一整個龐大的工程的時候，未免會感覺到有點力不從心，有點焦慮，因為畢竟是乙個全新的東西，它有自己的生命，自己的問題，自己的功能，自己的架構。
我經常在想，有沒有一套方法，可以讓我們快速進行專案工程呢？
答案是有的，最近逐漸在腦子裡成型。
專案工程，我們不外乎關注這麼幾個點。
1、這玩意幹啥的？怎麼做到的？
2、這玩意我咋上手？
3、這玩意我改得動嗎？不會崩嗎？
很遺憾的是，很多人其實只關注了第二點，也就是我經常說的 ctrl c + ctrl v 工程師。很多的時候你並不知道為什麼這樣寫，為什麼只能這樣寫，當時為什麼會這樣寫。聽過乙個笑話，就是你覺得一坨**很爛，但是你深思熟慮後，覺得也只能這樣寫了。
我們關注的幾個點要怎麼到達呢？我建議是這麼乙個路徑去達到。
首先，諮詢原來的開發者，得到整個專案的背景以及專案的歷史，和各個部分的關係。這一步，我們可以在腦子裡有個大概，但是很顯然乙個元件都記不住，關係也記不住，但是沒關係，我們來到第二步。
這個時候，你腦子裡必然是一臉懵逼的，我們的經驗和大腦本能地告訴我們這事情是行不通的，但是別人又說這是行得通的，這在我們腦子裡就很矛盾，你需要一些證據給你的大腦證明這是行得通的。所以這時候你需要乙個 quick start，也就是 ctrl c + ctrl v 按照前輩的經驗自己寫乙個小功能，也就是乙個證據，乙個就夠了。接下來就開始分析我們的需求改動點應該是**了。
這玩意我改得動嗎？這是我們的腦子給我們的第三個訊號，它在不熟悉乙個東西的時候，會本能地拒絕任何的變更。所以在這個階段，原始碼閱讀是我們必不可少的乙個步驟，特別是在專案開發的過程中，我們要依靠第一步的系統關係，以及我們已經認知的業務流程，把專案**啃下來。就是我們已經知道有abcde子系統以及他們的大概關係，利用這個關係，像編織籃筐一樣，按照設計的方向慢慢看清整個專案。
閱讀原始碼的過程 以介面和訊息機制為入口，仔細梳理某個流程的完整呼叫鏈，並把它擴充套件到其他的呼叫過程裡面。相信我，絕大部分的**都是增刪改查，你要了解的事情是，這是在哪查的，在哪改的，在哪刪的，在哪增的，這就夠了。至於業務流程本身，或者邏輯判斷，有個大概的認識就好了，第一遍閱讀主要是認一認各個系統各個資料結構之間的關係，讓你的腦子知道這玩意是怎麼跑的。
基於第一次閱讀的認識，我們再反向觀察整個專案結構，這時候的你不僅有信心，而且知道專案整體情況，對於各個部分的細節也有一定的認識，你的專案眼界不知不覺中已經提高到乙個架構師的基本。這時候的你必然能得到你所負責需求的改動，以及對於全域性的影響。
大系統就是這樣，牽一髮而動全身。
如果時間很急，複製貼上走起，不要想太多，了解個屁專案。（加紅加粗）
quick x建立新專案
時為quick x2.2.1rc版本 建立新專案之前，確保已經正確設定了quick cocos2dx root環境變數，參考 啟動 終端 應用程式，然後進入需要放置新專案的目錄 cd desktop執行create project.sh命令，並指定專案的 package name quick coc...
新專案，新架構
新專案需要乙個長連線架構的實現，而長連線對於效能的要求決定了用c或者c 來寫比較靠譜，但是公司的技術人員組成決定了不可能用c或者c 來寫業務邏輯，而且這個也不現實，會使得開發周期和維護成本很高。於是決定採用boost asio fastcgi php來實現，也即前端有乙個保持長連線的伺服器，當前端將...
有關sourceTree clone新專案的嘗試
本人使用的souretree 去獲取gitlab 上的遠端倉庫的檔案 採用http,非ssh 期間改動密碼一次，此次需要更換專案，clone的時候暴露乙個問題 這是乙個無效的源路徑。1 將問題定位在密碼改動上 處理方法1 試圖 工具 選項 驗證，更改密碼。但是仍然失敗。處理方法2 試圖 刪除 工具 ...