開發階段總結

    開發的關鍵點在於學習，學習能夠說是在任何行業永恆的話題，學習什麼？如何去學習？就編程而言，學習最終是爲了應用，首先要學習到這種應用，而後學習其如何應用，再學爲什麼能這樣應用，最後學如何創建或者（根據須要）更改這種應用。

    假設你想學習一個開源項目，首先要了解該項目應用的工做機制，熟悉其業務邏輯，懂得其業務核心在哪裏，業務邊界在哪裏，什麼地方正常使用無問題，什麼地方正常使用可能有問題（所謂的‘坑’），什麼地方在某種狀況下使用必有問題等等。

    而後須要瞭解其組成原理，便是代碼組成。在對代碼工做目的充分了解的前提下，從代碼源頭找起（方法調用部分），學會單元測試，對代碼相關位置進行功能驗證，對其相應功能分別進行深刻，慢慢排除模塊干擾（通常來講，爲了提升項目的可維護性，都會將模塊進行劃分，以致於相應的功能具體實現被劃分模塊的代碼掩蓋），同時學習該模塊的建設，積累經驗

    最後最終的目的天然是要根據須要更改此項目（或者不須要更改，但最好能有更改的能力，通常項目應用範圍難以保證必定在業務需求以內），假設前兩點都能正常完成，那麼我對於該項目的各個功能的應用點、邊界問題、架構劃分、具體實現應該有了必定的瞭解，一般狀況下，爲了下降功能及模塊的耦合度，項目功能的具體實現都是邊界狹隘的單面功能，通常邊界在一個任務的範圍內，若是業務需求要求更改相關具體實現，應該從調用者處改起（不能改變單面功能的實現，而應該在該功能的調用者處增長業務邏輯），但若是調用者處於一個模塊內，則最好在該模塊外更改，避免模塊與模塊間耦合度太高。

    假設前兩點不能正常完成，只要注意到項目的邊界範圍，若是能解決需求問題，短期內也沒有關係，而且還能快速解決需求，但若是該項目須要長期使用下去，最好能在有空的時候能將相關的耦合度問題（事實上，全部的設計模式要解決的難題，很大程度上就是這個耦合度難題，只不過在實際開發中這個問題有大有小，一般大的都是小的積累起來的，通常最初發現的都是能夠解決的）解決掉，否則你所在的項目可能會愈來愈難改，任何地方稍微動一下，就會出現各類連帶問題，到最終就會面臨兩個選擇，項目重構，或者，重建項目。

    項目重構是一件很是吐血的事情，原本到了這個地步，改一小點都會形成恐怖後果，況且重構是要大改，這大概是幾個星期不眠不休的節奏了。可是不能否認，重構項目是一個很是好的學習機會，能夠加深對解耦的理解。

    我再簡單談談新建項目，建一個新的項目，該項目的開展，一定跟創建者的編程基礎、開發經驗有直接的關係。一個資深的工程師，能夠對工程的各個需求完成的效率、工程結構、代碼模塊、領域知識、資源、實現方案有較強的開展或把控能力，根據公司規模、需求強弱、需求花費、可用人力物力資源在規定時間內進行需求分析、工程規劃、代碼編寫、測試、內部使用測試、上線、迭代需求分析、工程規劃......如此這般

    說到底，就編程來講，學習分兩個點：基礎積累，和，經驗積累。基礎能夠說是經驗的催化劑，由於任何的編程經驗都離不開基礎知識，換句話說，全部的功能都是基礎知識的應用，當基礎知識紮實了，積累經驗是水到渠成的過程，學習將變成一種習慣。

    關於基礎知識（如數據結構、算法、網絡等），如今的高級語言大多都已將基礎知識進行了封裝，但基礎還是必學之重，基礎知識學起來或許比較枯燥乏味，我認爲在完成一些個項目，對項目有必定的認識後，再去補習缺乏的基礎也許是一種不錯的方式