生產過程中出現的問題正逐漸得到中層和最高管理層的重視。不管是身為開發人員還是架構師，下列的事項都應該得到你足夠的重視以避免陷入未來的尷尬境地。你也可以把它作為排查問題的便籤。
#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’列。
完整內容點此檢視
#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’列。
完整內容點此檢視