重構是需要慎重考慮的，不是拍腦子決定的事情！程式設計師都有一顆工程師的心，所以當他們到一片新的場地想做的第一件事就是，將舊的一切推倒重來。是的，他們覺得舊**異常混亂，因為讀**更難，寧願丟掉舊**重新寫，也不願意修修補補，他們認為舊**簡直一團糟。
我覺得這個出發點是好的，但我觀察了非常多的案子，那些重構的專案大多數是失敗的，相當一部份都成了爛尾。他們從頭開始再寫一遍並不意味著會寫出比以前更好的**，因為不少人沒有參與到上乙個版本的建立，所以其實根本不算有經驗。一旦推倒重寫，可能會再犯一遍版本一犯過的錯，甚至會產生更多的新問題。
對處於團隊 leader的我來說，重構考慮的是人力、時間、專案風險等因素，在商業專案中，推倒重來是非常危險的行為,重寫專案的**也是乙個異常艱難的決定。當然，如果只是在做實驗，想到新演算法、sdk可以隨時重寫。
經過慎之又慎的考慮，重構也不是不可以的，但不是一下子推翻專案之前的所有**，否定一切，你可能不一定會寫出比以前更好的**。結合自已的工作經驗（移動端開發經驗），重構主要工作從以下幾個方面展開：
前面提到重構是慎之又慎的決定，這裡就提到必要性，是不是自相矛盾呢？其實這並不矛盾，而是承上啟下的。隨著應用的不斷發展，最初的架構往往面臨著各種問題，比如無法滿足客戶的需求、無法實現應用的擴充套件、無法實現新的特性等等。在這種情況下，我們如何避免一些坑，盡量比較成功地實現架構的重構。
3.1 確定重構的目的和必要性
每一次架構的重構都是「傷筋動骨」，就像做手術一樣，即使再成功，也會傷元氣，所以決策者們首先要分析架構重構的理由和其他備選方案，明確重構的目的是為了滿足業務需求，並且是不得不做的最佳方案，然後再考慮其他問題。 有時候，經過分析就會發現，也許還有其他解決方案，比如增加計算資源，或者重構的目的不是為了業務需求，那就沒有必要做了。檢查清單：
3.2 定義「重構完成」的界限
如果確定要重構，那麼要把目標明確下來，也就是重構的邊界條件，怎麼才算是「完成」了重構，目標要有資料量化，或者有能夠測試的辦法。這也是乙個需求分析的過程，如果需求不明確，那麼規格說明書沒法寫清楚，負責重構的團隊也沒有明確的目標，不能以重構的時間或者主觀的判斷為結束的依據。檢查清單：
3.3 漸進式重構
現在軟體研發最流行的就是快速迭代、持續交付、盡早反饋。這同樣可以用在架構的重構上，重構過程的難度不亞於構建乙個新產品，所以在設計重構的時候，要引入持續交付的流程，每乙個重構步驟或者模組都要快速部署並得到反饋，以便評估重構的效果，及時作出策略調整。經過謹慎測試之後，將資料和業務遷移過去。檢查清單：
3.4 確定當前的架構狀態
在啟動重構之前，團隊要對當前的架構狀態有清晰的了解，也就是設定好基準，以便評估重構的效果。據我的觀察，負責重構的架構師或者開發者，往往還沒有搞清楚現有的架構設計，就開始重構了，結果經常出現這樣的情況：重構到某個階段，發現行不通，然後一拍腦袋說，哦，原來這塊的架構是這個樣的，是為了達到某某業務需求啊，這塊不能動，得想別的辦法。類似的例子在研發團隊中時有發生，也提醒我們要慎重小心。檢查清單：
3.5 不要忽略資料
資料的重要性不言而喻，業務都是以資料流為載體的，所以架構重構的本質就是對於資料流的重構。資料對重構的重要性主要體現在兩個方面：在重構設計時，需要考慮業務資料的需求，重構之後的系統對於資料的儲存、處理、分析等功能是否有影響；在重構過程中，考慮依靠資料甚至是實際的資料來驗證重構的效果，提供評估的支援。檢查清單：
3.6 管理好技術債務
技術債務在平常的軟體研發過程中也是比較突出的問題，架構重構往往是為了償還技術債務，所以請不要在償還技術債務的過程中製造技術債務了。技術債務就像信用卡一樣，會有很高的利息率，就如同給團隊留下了大量的帳務開銷。組織應該培養一種保證設計質量的文化。應當鼓勵重構、同時也應當鼓勵持續設計以及其它有關**質量的實踐。在開發時間中應當專門抽出一部分以解決技術債務。檢查清單：
3.7 遠離那些虛榮的東西（例如使用「熱門」的技術棧）
架構的重構過程應該是以目標為導向，換句話說「注重實效」。對於技術人來說，乙個經常被輕視的問題在於，喜歡追逐新鮮的熱門技術，這其實是個好事情，說明技術人勇於創新，不斷接受新技術。但是對於架構的重構這樣的關鍵性任務來說，是不是新技術並不重要，重要的是能不能實現重構的目標。對於新技術來說，雖然熱度大，但大家踩過的坑還不多，積累的失敗教訓和成功經驗還不夠，在這種情況下，建議大家不要頭腦一熱就上馬新技術，應該客觀冷靜地評估新技術和成熟技術對架構重構的影響和效果，以資料和經驗來說話，而不要追趕時髦。檢查清單：
3.8 做好準備面對壓力
軟體開發過程中，壓力無處不在。對於架構重構來說，壓力**於多個方面：管理層、團隊成員、同級部門等等。說白了，架構重構對個人來說往往是一件出力不討好的事情。和做乙個新產品能夠取得很高的讚賞相比，重構的成績往往並不受領導重視，而且出了問題還要承擔很大的責任。從軟體開發角度看，做新產品是從 0 到 1，而架構重構是從 -1 到 1，複雜性和難度通常更大。因此，重構的負責人要提前做好心理準備，舒緩壓力的乙個技巧是，設定好里程碑，將重構的成果量化，並且和業務的變化關聯起來，定期向利益相關各方同步狀態，得到大家的理解和支援。檢查清單：
3.9 了解業務
架構重構的最終目的是改進業務，所以對於業務的了解將有助於架構師和技術人確定重構目標的優先順序和關鍵路徑。比如，我們需要知道哪些關鍵業務的架構是不能碰的，哪些業務之間是互相關聯的，哪些業務的架構是需要優先重構的…..等等。除了了解業務本身，我們還需要了解「人」，表面上管理層是重構目標的裁決者，但實際上業務部門的人才是。技術人需要了解他們的業務需求，並將其轉化為重構目標。通過這種方式，架構重構的意義才能得到具體的體現。檢查清單：
3.10 做好面對非技術因素的準備
不管你是否願意相信，技術在架構重構（以及其他很關鍵的公司決策中）的影響因素中並不是最高的，我們還會涉及到商業利益、管理層偏好、大客戶影響、團隊問題等等，對於架構師和技術人來說，這些因素往往不是他們所能掌控的。我們能做的就是，與利益相關者設定重構目標，然後，根據不同的影響因素，調整目標。請記住，不要死扛這個目標，當有人提出不同的意見時，要坦誠地和他們交流，並告知他們如何採納意見，那麼重構目標會有變化，然後讓其他利益相關者也知道這些變化。非技術因素的影響是客觀存在的，而且從商業層面來說也是合理的，所以對於技術人來說要學會適應。檢查清單：
3.11 對於**質量有所掌握
架構的重構對**質量要求很高，一方面是重構過程對 bug 的容忍性比新產品的研發更低，另一方面也決定了下一次重構的難易程度。**審查是乙個非常好的辦法。**審查是軟體開發過程中的必要步驟，既可以幫助被審查者提到**質量，又可以讓審查者加深對產品的理解。不論團隊多忙，一定要保證**提交之前，是經過其他成員審核過的，短期來看會占用團隊的時間，長期來看是事半功倍的好事。檢查清單：
關於架構的重構，一切**於實踐中的經驗是最有價值的，為技術人所用才是有意義。
android專案 開發過程中需要時刻注意的
菜鳥入門級別程式設計師，頭一回做上線專案。經驗不足導致專案在開發完成之後bug 百出，小記一下在以後的開發過程中需要時刻注意的點 1，規範很重要 在後期的 整理的過程中，回頭看才發現，各種亂七八遭的多餘 邏輯混亂的 在專案進行的過程中一定要注意，先理清邏輯再敲 摒棄多餘 該省就省。2，記憶體優化 安...
專案開發過程中的幾個階段
1.evt engineering verification test 產品開發初期的設計驗證比如功能性測試等，通常這個階段的產品存在的問題還比較多。2.dvt design verification test 這通常是硬體生產中不可缺少的乙個檢測環節。3.dmt design maturity t...
專案開發過程中遇到的問題
問題分類 1 邏輯問題 結構 處理流程的設計有問題，尤其在多執行緒操作同乙個物件時 2 介面定義和使用問題 例如介面結構或返回情況改了，未及時編譯或更改其他模組的呼叫 3 對接問題 對講問題不是你的問題，就是我的問題，需要聯查 4 理解問題 對功能 邏輯流程或函式定義和使用的理解不清晰 5 異常處理...