生産過程中出現的問題正逐漸得到中層和最高管理層的重視。不管是身為開發人員還是架構師，下列的事項都應該得到你足夠的重視以避免陷入未來的尴尬境地。你也可以把它作為排查問題的便簽。
#1、不在屬性檔案或 xml 檔案中外化配置屬性。比如，沒有把批處理使用的線程數設定成可在屬性檔案中配置。你的批處理程式無論在 dev
環境中，還是 uat(使用者驗收測試)環境中，都可以順暢無阻地運作，但是一旦部署在 prod 上，把它作為多線程程式處理更大的資料集時，就會抛出
ioexception，原因可能是 jdbc 驅動版本不同，也可能是#2
中讨論的問題。如果線程數目可以在屬性檔案中配置，那麼使它成為一個單線程應用程式就變得十分容易了。我們不再需要為了解決問題而反複地部署和測試應用了。這種方法也同樣适用于配置
url、伺服器和端口号等。
#2、測試中使用的資料集規模不合适。比如，生産過程中一個典型的場景就是隻使用 1 到 3 個賬戶進行測試，而這個數量本應是 1000 到
2000
個的。在做性能測試時，使用的資料必須是真實并且未經裁剪的。不貼近真實環境的性能測試，可能會帶來不可預料的性能、拓展和多線程問題。隻有使用更大規模的資料集對應用程式進行測試，才能保證它正常運作并滿足非功能屬性的
slas(服務水準标準)。
#3、天真地認為應用程式中所調用的外部和内部服務是可靠的，并且是始終可用的。不允許出現服務調用逾時和重試，将會對應用程式的穩定性和性能造成不利地影響。需要進行适當的服務中斷測試。這一點十分重要，因為如今的應用程式多是分布式并且面向服務的，都需要大量的網絡服務。無限地請求不可用的服務會損害應用程式。也需要對負載均衡器進行測試，以確定它能正常工作，使每個節點達到平衡。
#4、沒有遵循最低限度的安全要求。正如上文提到，網絡服務随處可見，進而使得黑客可以輕易地利用它進行拒絕服務攻擊。是以，在使用安全套接層時，必須完成基本的驗證并使用
google skipfish
等工具進行滲透測試。不安全的應用程式不僅會威脅其自身穩定性，還可能會因為資料完整性問題對公司的聲譽造成負面影響，例如出現了客戶
“a”可以浏覽客戶“b”資料的情況。
#5、沒有進行跨浏覽器的相容性測試。如今的網絡應用程式多是豐富的單頁應用程式，它們使用 javascript 程式設計語言以及 angular
js
這樣的架構。為了使你建設的網站能夠流暢地運作于不同的裝置和浏覽器之間，必須實作與之對應的設計。是以為了確定你的應用程式可以适用于所有裝置和浏覽器，必須對其進行相容性測試。
#6、沒有外化可能經常發生變化的商業規則。例如稅法、政府或行業相關要求、分類法等。可以使用像 drools
這樣的引擎來處理商業規則，它幫助你通過存入資料庫或 excel
的形式，來外化這些商業規則。企業掌握了這些商業規則，就能以最少的變化和測試完成對稅法或相關要求地快速反應。
#7、沒有提供下列文檔
編寫單元測試文檔并使其擁有良好的代碼覆寫率。
內建測試。
一個綜合的或者百科全書式的頁面列出了所有的軟體構件，比如類、腳本、配置檔案等，而這些構件要麼是被修改了的，要麼是新建立的。
高層次的概念圖描述了所有的元件，互動和結構。
而基礎文檔則告訴開發者“如何結合資料源的詳細資訊來搭建開發環境”。
除了 cos(滿足的條件)這種由 mindmap 建立的形式之外，靈活開發中還有 1 和 2 這兩種主要的文檔形式。
#8、沒有适當的災害恢複計劃以及系統監視和歸檔政策。在項目截止日期來臨之際，常常因為急于部署項目而遺漏了這些事項。沒有通過 nagios 和 splunk 建立合适的系統監視機制不僅會威脅到應用程式的穩定性，還會妨礙目前的診斷和将來的改進工作。
#9、沒有為資料庫表設計友善整理的列，比如
created_datetm、update_datetm、created_by、updated_by
和時間戳，也沒有提供有條理的删除記錄列，如可以取‘y’或‘n’的‘deleted’列或是可以取‘active’或‘inactive’的
‘record_status’列。
#10、沒有制定适當的回撤計劃。導緻在系統發生故障時，沒有辦法将系統恢複到部署前的穩定狀态。這個計劃需要反複推敲并有相關團隊簽字保證。計劃包括了，退回到軟體先前的版本，去除插入到資料庫中的所有資料以及屬性檔案的所有條目。
#11、在項目開始前沒有制定能力計劃。現如今，在說明對平台的要求時，僅僅說“需要一台 unix 計算機，一個 oracle 資料庫伺服器，一個 jboss 應用程式伺服器”是遠遠不夠的。你的要求必須精确到
作業系統的特定版本，jvm 等。
有多少記憶體(包括實體記憶體，jvm 堆記憶體，jvm 棧記憶體和 jvm 永久代的空間)。
cpu(核心數)。
負載均衡器，需要的節點數、節點類型，比如是 active/active 型還是 active/passive 型，以及聚類要求。
檔案系統要求，例如，你的應用程式可能會收集生成的報告并将其儲存一年，之後才進行歸檔。這樣的話，你就需要有足夠的硬碟空間。有些應用程式要求産生資料提取檔案，并将它們暫時儲存以供其他系統程序或資料倉庫系統用來做多元分析報告。還有些資料檔案是基于安全檔案傳輸協定的，它們或來自内部系統，或來自外部系統，并且在歸檔前需要被儲存
12 到 36 個月。
下面的#12來自“david decesare”發自“java.dzone”的評論，
#12、“不在工作時使用最好的工具”。很多情況下，開發者會在生産系統中使用一門想要學習的語言或某種工具。通常這不是最好的選擇。比如，為已經實際上是關系型的資料使用
nosql 資料庫。請記住，無論你采用哪種工具，都需要在未來 3 到 5 年(甚至更長的時期)内維護你的産品。
#13、在 16 個關鍵技術領域缺少充足的知識儲備。這些領域包括識别并修複1)“并發問題”、2)事務問題、3)性能問題。很多次面試中，我靠着這 3 個方面的知識拿到了新的合同。
來源：51cto