0x04 App接口，三大環境

摘要：互聯天下，移動爲王。絲絲理清，避免亂麻。程序員在本身的環境，有本身熟悉的開發工具或者IDE，有本身熟悉的調試工具或者流程。修改生產環境的任何一行代碼，均可能會影響到用戶。沒有任何人敢保證當前這行代碼不會影響用戶的使用。

互聯天下，移動爲王。絲絲理清，避免亂麻。

曾經一度也作過移動APP的後端開發，根據本身的一些經驗，談一談後端API接口的開發流程與環境的關係。

01 後端三個環境

1、開發環境
一般是api開發人員的本身機器，通常的做法是每一個開發人員本身有一個環境，也有幾個開發人員共用一個開發環境的狀況。

開發環境的優點：

1. 程序員在本身的環境，有本身熟悉的開發工具或者IDE，有本身熟悉的調試工具或者流程，遇到問題能以本身熟悉的方式很快找到問題並解決。

2. 另一個因素，恐怕是網絡的影響了。在本身本機開發與調試，基本不受網絡影響。若是是直接在測試環境（一般在遠程）進行開發，公司網絡你們用，總有那麼一些時間，會出現打一個字符卡一下的狀況，這樣根本沒法進行有效的編碼。

開發環境的劣勢：

1. 須要本身搭建一個和測試環境、生產環境幾乎一致的環境，包括各類依賴包。但這對一個程序員來講，應該不是問題。何況，一個程序員連環境都配置很差，那麼，他必定不是一個合格的程序員。

2. 須要同步數據庫，這個比較麻煩，由於不少狀況須要數據支持才能進行開發與調試。一般可按期或者在須要的時候，同步一份測試環境的數據庫下來，本地還原數據。在偶爾的狀況，也能夠直接去鏈接測試環境的數據庫。

2、測試環境
一般是程序員開發完成後，完成了由開發人員的自測，包括單元測試後，將代碼更新到測試環境，交由測試人員進行測試。

若是測試人員測出了問題，這一般有如下幾種狀況：

1. 確實是程序員致使的bug，須要由程序員修復。此時，程序員會將發現的問題，再在本地開發環境進行跟蹤（通常這比在測試環境快），一旦找到問題並修復，再將代碼更新到測試環境，由測試人員進行確認。若是還有問題，重複這個步驟。

2. 若是是測試人員和開發人員對問題的理解不一樣形成的，這個時候應該對照需求進行討論。若是是程序員的問題，繼續回到步驟1進行。若是是測試人員的問題，由測試人員本身記錄並保持代碼不變。

3. 因爲開發人員的環境或者數據庫與測試環境不一致致使的問題（開發環境沒有問題，測試環境卻有問題），此時，能夠直接修正開發人員的本地環境，或者直接修正測試環境（有多是測試環境須要更新等）。

4. 一般狀況，開發人員是不會在測試環境修改任何東西的，即便直接修改測試環境，一般也只是針對一些特定的bug（本地沒法重現的）進行必定的跟蹤與調試，最多加入一些日誌信息或者臨時修改部分代碼。若是在測試環境修改代碼後，問題解決。開發人員仍是得在本地再按一樣的方法修改，改好後又同步一次。爲何每次都得強調在本地修改一次，這是版本管理的一個重要概念，本地須要對代碼的全部修改進行跟蹤，最終的全部修改都能在git等版本管理裏面能跟蹤的。

若是測試人員沒有測試出問題，即確認知足了已知的問題。此時進入發佈階段。

3、生產環境
一般是測試人員確認了在測試環境的全部代碼後，便可直接發佈到生產環境。

發佈到生產環境後，仍是可能會出問題，發現了bug，bug一般有幾種：

1. 由測試不全面致使的，即在測試環境沒有測試到的bug，也意味着這個bug在測試環境一樣存在，這個應該由測試人員來負責找到問題並告訴開發人員修復。若是要定責，也應該是測試人員的責任。固然，有些bug也是由數據量致使的，測試環境畢竟數據量不夠，可能在生產環境的某個用戶會出現問題，而測試環境根本沒有這個用戶。

2. 因爲測試環境與生產不一致致使的，須要讓測試環境與生產環境一致，若是還有問題，也須要記錄，每次發佈是否要做特殊的操做。

3. 在生產環境發現的任何問題，須要與測試環境進行對比，是否測試環境也一樣有這個問題，是否這個問題是開發人員致使的問題，若是是開發人員的問題，又須要從：開發-測試-生產這個流程來走，是不能在生產環境直接進行修改的。

修改生產環境的任何一行代碼，均可能會影響到用戶。沒有任何人敢保證當前這行代碼不會影響用戶的使用。軟件由代碼組成，每一行代碼可能都會影響一個因素。

02 客戶端三個版本

依照上面的三個環境的狀況來，開發人員須要有每一個客戶端更新版本的三個環境版本：
ios客戶端：

開發版本
    測試版本
    生產版本

android客戶端:

開發版本
    測試版本
    生產版本

最嚴格的來講，任何客戶端更新後（哪怕只是修復一個小bug），都應該同時發這版本的：開發、測試、生產三個環境版本給開發人員，不然，會出現的問題：

1. 只發測試版本，而後說服務端有哪些問題須要修正，這就很明顯了，要求服務端開發人員直接去測試環境跟蹤問題，並修復。這個明顯不是最好的方式，並且修改的代碼不能很好的進行本地代碼版本管理。

2. 只發生產版本，這就更有問題了，生產環境上面是不能修改任何代碼的。

緣由很簡單，開發人員須要在本地跟蹤問題，發現問題，並最後修復問題。這些所有是在本地進行的，完成後再更新到測試環境測試，由測試人員確認後再更新到生產環境。

除了本地沒法重現bug這惟一的特殊狀況，須要去測試環境進行跟蹤與調試外，不得上測試環境改任何代碼。陳了測試環境沒法重現bug這惟一的特殊狀況，須要去生產環境進行跟蹤與調試外，不得上生產環境改任何代碼。

03 流程與需求管理

開發流程還和需求管理有很大的關係，這個自己算是單獨一個主題了，在此，只簡單說說：

首先，須要明確，哪些是bug，哪些是新功能。這個bug，是在哪一個環境有（測試仍是生產）？仍是都有？這究竟是一個bug，仍是一個新功能。不能上了生產環境，才發現一個原本是新功能但沒有作，但卻告訴開發人員這是一個bug。這是不合理的。

其次，這個bug是何時致使的？不能由於之前沒有測出來的bug，硬說成是新修改致使的bug。代碼是可跟蹤的，bug也須要能夠跟蹤。這個版本，須要開發人員解決哪些bug，添加哪些新功能，都是要明確的。須要在第一階段一塊兒提出來。