本文出自門心叼龍的博客，屬於原創類容，轉載請註明出處。https://blog.csdn.net/geduo_83/article/details/88606548
昨天晚上一年一度的315晚會又來了，今年雖然沒有哪家大公司上榜，但是曝光了一些黑心小企業，我們平時用的塑料盆、塑料袋、孩子的塑料玩具有可能都是用醫療廢棄物，如輸液袋、輸液管、一次性注射器、血袋等加工而成的，還有平日孩子們搶着買的辣條這種混合了十幾中添加劑的垃圾食品的生產環境着實讓人辣眼睛，我們無比驚歎這些企業爲了金錢、利益沒有一點道德底線，等待他們的將是法律的制裁。
好了，我們言歸正傳，項目功能移植可以說在日常開發中很多時候都會遇到，把A項目中的幾個功能移植到B項目當中，最近工作中就有這樣一個需求，需要將公司的一個老項目的幾個功能模塊移植到新項目當中，一開始以爲工作量不是很大，但是隨着改造工作的深入，不得不改變原有的移植改造方案。
對，就是將一個老項目進行移植改造，說他老是因爲這個項目從2014年就開始做了，直到2018年這個項目算是基本結束，整整做了4年多時間，現在隔三差五有些零星的小升級，這個項目可以說是我參加工作有史以來工期最長的一個項目，有人可能會問，多大的項目啊，盡然能做這麼長時間？它是我公司一款核心主打移動app產品，隨着用戶需求的不斷變化，功能的不斷增多，做這麼長時間，也就不足爲奇了，我們天天使用的微信、支付寶哪個不是這樣？
編碼架構演變史:
原有項目工程架構爲單一結構體項目，在這四年時間裏，隨着業務需求的不但變化，技術的更新迭代，導致了不同模塊出現不同技術實現方案。從最開始的非標準的MVC架構，這種結構是最早些從事Android開發的人員通用的技術架構，有些人可能很奇怪，什麼是非標準的MVC結構？因爲這種結構Activity和Fragment即承擔了View的角色又承擔了Controller的角色，在項目開始的時候，我們不得不說，這種結構開發效率非常高，但隨着業務功能的增多，導致整個Activity的代碼量越來越多，使其變得極其臃腫。
爲了解決Android開發中普遍出現的這種通病，2016年穀歌Android團隊推出新一代Android應用編碼架構MVP，一經推出就火變了大江南北，它將原來的Controller層進行了拆分，將一層拆分爲兩層：Presenter層和View層，這樣一來我們整個Activity和Fragment工作量就減輕了不少，它只做View的工作，一些業務邏輯的工作就交給Presenter了。既然是google出品，必然是精品，爲了順應歷史潮流，該項目在原有架構基礎上也就引入了MVP架構，在研究了google MVP的demo後，我們發現能解決我們的大部分問題。
- Model: 數據層，負責與網絡層和數據庫層的邏輯交互
- View: UI顯示層, 並向Presenter報告用戶行爲
- Presenter: 從Model拿數據，應用到UI層，管理UI的狀態，響應用戶的行爲
但是隨着時間的推移，產品中出現一些新的業務需求，現有架構的一些缺陷也逐漸暴露出來，比如常常有這樣的應用場景：在上傳圖片的時候，首先要去請求Token令牌，客戶端拿到了令牌時候再去上傳圖片，其問題的本質就行一個網絡請求回來之後才能進行另外一個網絡請求，直接導致的一個問題就是回調嵌套太多，代碼邏輯不清晰，這樣的代碼難以理解而且不利於以後的維護，有時候進入一個界面的時候，同時要進行兩個後者兩個以上的網絡請求，那麼這時候就出現問題了，Activity數據顯示不同步，多個網絡請求同時進行，他們必然是異步的，既然是異步的，毫無疑問有的請求回來早，有的請求回來遲，界面上的數據必然會出現不同步。這時候RxJava出現了，剛剛接觸RxJava的時候，的確被它強大所驚歎，能將原來複雜的業務邏輯變得如此簡單，在配合上Retorfit那就是絕配，直接就解決了我們上面提到的問題，簡易的接口配置，優雅的代碼結構，強大的擴展支持深受廣大開發者的追捧。
從MVC架構到MVP架構，再從MVP在到MVP+RxJava+Retorfit，也就是現在我們的項目裏存在着三種編碼架構體系。雖然編碼架構移在變，但唯一不變的是項目一直都是單一結構體項目，它的弊端在我這裏我就不講了，如果感興趣的可以閱讀我的另外一篇文章：Android組件化方案最佳實踐，https://blog.csdn.net/geduo_83/article/details/86604852
網絡請求演變史:
網絡請求作爲一個APP項目最基本的功能需求，在我們項目裏http也經歷了四次更新迭代。從最開始行業通用的AsyncHttpClient框架，再到google官方推出的Volley，在到國內技術大神嚴振杰在OkHttp基礎上封裝的NoHttp，再到square公司開源的網絡請求框架的終結者Retrofit。
基本組件Activity演變史：
關於Activity基類結構也有着兩種不同的架構體系，一種是基於ActionBar的架構體系，隨着ActionBar的棄用，誕生了另一種是基於ToolBar的架構體系。
這就是目前這個項目的基本架構，給我們最直接的認識就是，各個模塊技術解決方案不統一，正是由於功能模塊多，項目週期長，新技術的更新迭代快，有沒有足夠的時間進行重構改造，必然會造成現在的單一結構體項目的多架構問題。 現在要抽取幾個功能模塊，的確不是一件很容易的事。原本打算按照現有新項目的架構：組件化+MVP+RxJava+Retorfit重新開發一遍，最後我放棄了，因爲有些模塊有着大量的業務邏輯，這工期可不是一星半點，最後經過商議，採取了一種折中的方案，編碼架構保持不變，維持原狀，功能模塊原來以包來劃分，現在以組件的方式從新進行拆分，這樣一來工作量就大大降低了。
方案定了之後，開始實施了，抽取了一個公共的Common庫，其中包含了有網絡請求組件和項目基礎組件，要移植的模塊的資源文件散落在整個項目的各個角落，然後就是施展我們的VC大法了，這可不是好差事，這一週頻繁的使用VC大法，一致出現了眼花，手腕痠疼的感覺。
通過這次的移植改造，再次給我們警醒，一個好的項目架構多麼的重要，架構不統一，技術解決方案不統一，多個模塊各自爲政，給後期的維護和改造、擴展將是災難性的。我們不得不感嘆，在軟件開發行業不像醫生、律師這些知識相對穩定的行業，軟件行業的技術沒隔一段時間就會更新換代，讓你清零，所謂“活到老，學到老”，用到程序員身上在適合不過了。