其他

第一章 善於防守使程式正確和使程式能用的區別：1. 編寫在大多數情況下都能用的代碼是很容易的，它對常規的輸入集會產生常規的輸出集；2. 正確的代碼絕對不會崩潰，對於所有的輸入集，它的輸出都將是正確的；3. 並非所有正確的代碼都是優秀的代碼，因為有些正確的代碼的邏輯可能很難理解，難以維護。在編寫代碼的時候，你會很容易產生很多設想，例如程式應該如何運行、如何調用、如何輸入等。我們經常有以下3種常見的設想：1. 這個函數“絕對不會”被那樣調用，傳遞給我的參數總是有效；2.

第七章

    剛剛結束的一個項目，在後期客戶對效能提出了很高的需求，然後就是不停的進行最佳化，下面把一些最佳化的心得記錄在這裡吧。    項目是一個Java的web應用系統，最佳化的過程重要從程式和資料庫兩方面展開，中間也調整了Tomcat的一些設定。

第三章 名正言順遠古的人認為命名某個事物就是對其擁有權利。這不僅僅是簡單的宣稱所有權。一些人對名字的力量堅信不疑，以至於他們從不將自己的名字告訴陌生人，因為他們害怕陌生人會使用名字來傷害他。名字所描述的內容包括：1. 身份；2. 行為；3.

軟體架構師沒有時間對‘所有需求’進行深入分析，這既是策略，也是現實。 需求是任何促成設計決策的因素，但是很少有開發人員可以擁有一個穩定的需求集，所以，關鍵的第一步就是要縮小範圍，範圍的標準是具有重要性、可能性並且數量要少。 從需求轉向架構的過程中，存在的幾個問題：抱怨留給架構的時間太短，而不是接受項目節奏普遍加快的現實。一般來說，新的商業應用的開發週期最多不能超過9個月。認為必須詳細分析所有的需求，只有這樣才能設計出滿足所有需求的軟體架構。我們採取的策略是：在架構設計期間，關鍵需求決定架構，其餘

功能、品質和商業需求的某個集合塑造了架構，也就是說關鍵需求塑造了架構。 概念性架構設計可以分為以下3步：1． 魯棒性分析2． 引入架構模式3． 品質屬性分析 很多人認為從需求分析到架構設計之間的過渡遇到很多問題，究其根源，可能是以下的原因造成的：用例是面向問題領域的，而設計是面向機器域的，這兩個‘空間’存在映射。用例技術本身不是物件導向的，而設計應該是物件導向的，這是兩種不同的思維方式。用例規約採取自然語言描述，而設計採取形式化的模型描述，描述的方式不一樣。 魯棒圖可以很多的解決需求分析和架構設

//ArcGIS server9.3 ADF JavaScriptvar scale="";if(map._extent!=null){//得到當前視野內地圖範圍地圖座標var maxX=map._extent._xmax;var minX=map._extent._xmin;var maxY=map._extent._ymax;var minY=map._extent._ymin;//地圖控制項（圖片）的寬和高var imageWidth=map._mapsize[0];var

Server發布地圖都是基於Mxd去發布的，這點與IMS使用axl檔案差不多。一般來說，發布後mxd儘可能不要修改，或者在通過使用arcMap進行編輯後在重新發布。修改mxd會導致地圖服務發生變化，因此，相對來說是一種危險的操作。但有時客戶需要對Mxd進行修改，自訂的添加修改圖層，並重新發布服務。當然，這些苛刻的需求server同樣可以應付，但還是不建議這樣做。方法總是有的，越危險的事也就越有趣。還是跟大家分享一下這方面的心得吧。下面函數實現添加一個圖層到mxd檔案，並設定樣式。為更好的表達，函

問題其實就是你期望的東西和你體驗的東西之間的差別。 那些沒有經驗的問題解決者們，幾乎無一例外，都是去匆忙的尋找解決辦法，而不是先給要解決的問題下定義。即使是有經驗的問題解決者們，在社會壓力要求他匆忙決定的時候，也很容易屈服。這樣，他們會找到得到很多解決辦法，但未必適合手頭這個問題。當一個人努力讓別人接受他贊成的解決方案的時候，總是指責別人太頑固，而不是說對方的觀點其實是可以替代的。 對於那些沒有幽默感的人，幫他們解決問題簡直就是自尋煩惱。 不要把他們的解決方案誤認為是問題的定義。不要把問題的解決

 代碼 Code highlighting produced by Actipro CodeHighlighter

忽視品質屬性需求在內的非功能性需求是很致命的。 關於品質屬性，以下幾方面的認識是很重要的軟體品質屬性可以劃分為運行期品質屬性和開發期品質屬性兩種。為了滿足效能、持續可用性登運行期品質方面的需求，架構師必須深入研究軟體系統運行期間的情況，合理劃分系統不同部分的職責，權衡輕重緩急，並指定相應的並行、分時、排隊、緩衝、批處理等設計決策；而要滿足可擴充性、可重用性等開發期間品質需求，則要求架構師深入研究軟體系統開發期間的職責劃分、變化隔離、架構使用、程式碼群組織等情況，制定相應的設計決策。各類需求對架構

1、在用戶端根據指定id擷取coolite控制項對象var obj=Ext.getCmp(“myId”)2、設定coolite控制項的值用函數setValue();例如：checkbox.setValue(false);//設定coolite控制項checkbox的選擇狀態3、在用戶端使用coolite對象，在控制項的Handler屬性綁定JavaScript事件處理函數時以 #{控制項ID}的格式傳送，多個參數之間以逗號間隔。頁面代碼：<ext:Panel

如果要用CreatObject方法建立一個ArcObject對象，那麼需要知道這個對象的類的CLSID。例如要建立一個Point對象，那麼IPoint pRemotePoint = pServerContext.CreateObject(“esriGeometry.Point”) as IPoint;至於這個方法所用的參數esriGeometry.Point可通過ESRI提供的Library Locator工具來查詢得到。這個工具可以從開始\程式\ArcGIS\Developer

第五章

多視圖的方法不僅僅是架構歸檔技術，更是指導我們進行架構設計的思維方法。 越是複雜的系統，越是需要從多個方面進行架構設計，這樣才能把問題研究和表達清楚，而提供不同的軟體架構視圖也便於交流和傳遞設計思想。 關鍵需求是對軟體架構設計起關鍵作用的需求子集，包括功能需求、品質需求和商業需求三種，架構細化必須注意滿足這些需求。 領域模型是以物件導向方式對問題領域的模型的類比和抽象，它揭示了重要的業務領域概念，並建立業務領域概念之間的關係，領域模型被不斷精化後成為最終軟體系統的問題領域層，它決定了軟體系統的功

//構建新的MXD文檔  protected void CreatMXD()  {      //獲得伺服器上下文      IGISServerConnection gisServerConnection = new GISServerConnection();      gisServerConnection.Connect("fms");      IServerObjectManager4 serverObjectManager =

第六章

Ext提供了這樣的一個實用函數 Ext.extend 在EXT架構中實作類別繼承的機制。這賦予了你擴充任何JavaScript基類的能力，而無須對類自身進行代碼的修改（這裡通常指的是子類，或是從它繼承的，一個基類）擴充Ext組件這是個較理想的方法。 要從一個現有的類建立出一個新類，首先要通過一個函式宣告新類的構造器，然後調用新類屬性所共用的擴充方法。這些共用的屬性通常是方法，但是如果要在執行個體之間共用資料（例如，Java中的靜態類變數），應該也一同聲明。

不值得驗證的架構不值得設計。 如果我們決定接受第一顆子彈，那麼子彈到來的越早、越快對我們越有利。 原型技術的思想：對感興趣的問題先試試看，而故意忽略其他方面的要求，從而使‘試試看’的成本遠遠低於‘正式幹’的成本。 根據實驗或者評估的結果，我們可以做出很多有意義的判斷：1.       我們擔心的風險是否真的存在2.       通過開發原型是否找到了風險的解決方案3.       下一步，我們是讓項目繼續還是將項目取消4.