最近根據 江蘇省軟體園評測中心對我們系統測試後提交的測試報告，需要對我們的系統做些安全性修補和優化處理，下面是我根據該評測報告所做的乙個概要性的建議分析。由於我們這個系統是一年多前設計的，因此在一些設計方面（尤其是中間層）有些不足之處，事實上，要在短期內對該系統做到完全重構、優化是很難的，因此，以下的一些建議或目標需要根據專案進度和難度逐步進行。
將中間層捕獲的所有異常封裝後返回給客戶端的呼叫者，由客戶端處理特定異常以顯示友好的提示資訊或做必要的處理。
將目前的大 webservice 類按業務邏輯分解成多個業務邏輯物件類，客戶端只在需要使用相關業務邏輯時才建立對應的業務邏輯webservice 類，並在關閉相關業務子模組時釋放建立的業務邏輯物件，籍此降低客戶端的記憶體使用量。參考《webservice 效率小貼士》
中間層盡量使用儲存過程來獲取 dataset 及對它進行更新處理，不要使用 ***mandbuilder 來生成更新命令。需要同時操作多張表的窗體中，應在乙個方法中同時返回所需的所有表，並針對這些表建立所需的關聯和約束。
使用 microsoft report services 來建立報表，以提高報表的使用者自定義的靈活性和報表的美觀、多表現性，該報表服務支援對多種格式檔案的匯出功能。
重新設計系統的整體引數設定類，在系統中統一使用該類進行各種引數選項的配置，籍此提高系統引數化方面的靈活性。
操作手冊建議由專人負責重新撰寫或整理。由開發人員撰寫使用者手冊得不償失，且風格難以統
一、可讀性不強。
必須使用特定的業務邏輯物件來對併發性衝突進行特殊處理。因為該系統使用單資料庫，所以不需要跨資料庫的事務管理，因此使用ado.*** 的事務處理就可以應付，在此建議必要時使用repeatable read事務隔離級別以保證在併發性時防止其他使用者的更改。
盡量減低客戶端對應用伺服器的呼叫次數。在這個原則的前提下根據具體問題進行調整。在執行響應時間長的操作時，增加一些系統「進度條」之類的提示，以增強系統的響應性[參考：《企業應用架構模式》引言5]。
對獲取伺服器時間(getsystime)的優化：由客戶端根據當前時間和與伺服器時間差計算得出伺服器的時間，以減少對伺服器時間的獲取次數，有關該演算法見附錄。
使用數字簽名和對稱加密來保障通訊安全，有關該方案的詳細情況請參考：《安全之道：加密與數字簽名》
注：getsystime 是乙個獲取伺服器當前日期時間的函式。
If Else 優化之道
每當看到乙個方法中有幾百行 裡面被層層的if else所包圍，我都感嘆，為什麼我們不能對if else優化一下呢？早些年，table很流行，搭建頁面框架比較簡單，但是慢慢人們發現層層的巢狀，卻並不利於 的閱讀，於是人們發明了div來代替table。if else儘管處理業務邏輯比較簡單，但是層層的巢...
Instagram效能優化之道
在 scale 2014大會上，instagram工程師tyler kieft做了題為 普通安卓裝置上的instagram 的演講，介紹其團隊如何針對普通手機 相對高階手機而言 重新思考instagram的設計。highscalability.com據此報道了instagram的效能優化之道。這樣做...
老子的軟體之道 道篇 9 企業之道
摘要 軟體哲學 軟體之道 銀彈 人狼 軟體架構 參閱 序 消滅人狼 軟體的十大命題 程式設計規則 聖人曰 持而盈之，不如其已 揣而鋭之不可長保 金玉滿堂莫之能守 富貴而驕，自遺其咎。功遂身退，天之道。乙個軟體企業，當它掌握了軟體之道，建立了架構體系，它的生產能力和發展速度會大幅提公升 但是危險也會隨...