生產過程中所出現的問題正逐漸得到中階和最高管理階層的重視。不管是身為開發人員還是架構師,下列的事項都應該得到你足夠的重視以避免陷入未來的尷尬境地。你也可以把它當作排查問題的便條紙。
#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 應用程式伺服器」是遠遠不夠的。你的要求必須精確到
以下的#12來自「David DeCesare」發自「java.dzone」的評論,
#12、「不在工作時使用最好的工具」。很多情況下,開發者會在生產系統中使用想要學習的語言或某種工具。通常這不是最好的選擇。例如,為已經實際上是關係型的資料使用NoSQL資料庫。請記住,無論你採用哪種工具,都需要在未來3 到5 年(甚至更長的時期)內維護你的產品。
#13、在16 個關鍵技術領域缺乏充足的知識儲備。這些領域包括識別並修復1)「並發問題」、2)事務問題、3)效能問題。在很多次面試中,我靠著這3 個方面的知識拿到了新的合約。