在專案實施中，我們常常會有這樣的情況：在客戶現場進行需求調查分析，然後返回公司做系統的概要設計，詳細設計，**設計，然後再交付給客戶現場組進行組裝和聯調測試。這種方式結合得好將會為公司節省開發成本中的差旅費等費用，而且開發人員可以聚集在一起互相交流等好處。
但是目前在公司的具體情況是開發人員需求分析後直接進入**實現，因此沒有經過概要設計和詳細設計階段這個客戶認可的階段，所以在設計上會有不少的缺陷，同時由於涉及到與其它系統的整合，而在公司沒有條件搭建同樣的測試環境情況下，缺少有效的測試就直接提交到客戶，隨之必然會產生一系統問題。如何更好的做好異地開發，避免給專案帶來的風險，也許需要我們更多的去思考。
當然，如果客戶能提供vpn或者其它遠端連線的方式 ，那麼就會解決專案實施中的很多問題，可以要求開發人員遠端登入現場直接修改**以修正缺陷。但是，如果不客戶提供不了遠端連線的方式下，我們如何解決異地開發中的相關問題呢？
1、測試系統的搭建，既然在公司無法搭建相應的測試環境，那麼，就在客戶處搭建相應的測試系統，測試環境的要求可以不用太高，畢竟沒有太多的實時使用者訪問，只需要檢測**的正確與否
2、bug的反饋，目前公司的實施方法就是前方只有乙個專案經理，如果是這種異地開發，且與其它業務系統有整合，自認為專案經理還是要具有一定的開發知識。首先從系統日誌中查詢問題的原因，這也需要開發人員的程式有很好的錯誤處理機制，從反饋的系統日誌中就能找到問題的所在。其次，在迫不得已的情況下，異地開發的程式對專案經理開放原始碼，原始碼的可閱讀性也要稍強，專案經理可以自己加入除錯**找到問題所在。但是這兩點對專案經理有一點的技能要求。
3、遠端桌面工具，在給開發人員反饋相關的bug之後仍然無法知道出現bug的原因，那麼就考慮遠端桌面共享了，目前公司有rtx可以遠端桌面共享，但是速度不夠理想，所以可以考慮用qq或者netmeeting之類的代替。由開發人員控制桌面，來除錯相關的程式。
4、版本的控制，在異地開發的過程中，由於開發人員不在現場，所以很多資訊**於專案經理，專案經理應該有乙個buglist，這個buglist可以記錄在專案經理的本地或者提交在公司的缺陷管理裡面，以便對各個版本解決的問題進行闡述。但是，即使是這樣，也有遺漏的地方。所以一定要確保所有的bug都已經修正。而且往往存在新提出的bug修正了，以前的bug又冒出來了，防不勝防，所以做好版本控制實在太有必要了
5、聯調，在更新**到正式系統之前，務必要在正式系統上進行聯調，在聯調的過程中，不僅僅是除錯開發人員修正的bug，還要除錯其它相關的功能。這個問題在專案中經常出現，往往修正了乙個bug卻導致更多的bug出現，這是由於在修正bug的過程中，開發人員只考慮修正提出的bug，卻沒有考慮到**的修改對其它相關功能的影響，所以聯調是必要的。
6、備份，**測試聯調通過之後就要正式更新，但是別慌，在更新之前，一定要對正式系統原來的模組進行備份，在更新**的過程中，有些問題可能不是我們**的問題產生的，而是系統的底層導致的，所以如果更新出現問題還可以恢復到以前的狀態。
其實上面所述的只是在異地開發中我們處理開發問題的一些常識，對異地協同開發的任務分配，進度管理，錯誤管理，專案溝通沒有提出什麼建議，還需要進一步的思考。
前後端開發協同的思考
前後端需要定義一套完整的錯誤碼體系，每個錯誤碼都有其含義，正確響應結果會有乙個code，可以定義為200，跟標準http code對應，容易理解。有些api介面，會使用http標準code返回，告知使用者業務的狀態，例如easyar的介面http 1.1 404 not found 這裡使用了htt...
異地開發的問題討論
朋友問 現在正在做的乙個專案,開發方自己就分成了大陸和海外兩個基地,大陸這裡的開發人員的領導在海外,不在一起 然後我們是客戶,我的的分公司也在海外不同的國家,感覺很吃力,時差很大 有什麼辦法解決這種問題?我剛看 最後的期限 中說 如果人分散在不同的地方,就什麼也幹不成了 cabinhome答 這個問...
程式人生思考之協同
近代的知識體系相對是完善的，是結構化體系的，是分門類別的。以格物致知的方式去研究深入，也是最讓人苦惱的，許許多多類別，需要不斷的去深挖，直至進入到商業化的產品，從0到1,或者是從1到n的程度。所謂的通才或者是叫做通識，在知識的維度上存在以名知意，妄加分析判斷，在通往的路上不斷進行打磨，最終成為社會認...