3. Practical Considerations
講到真正的軟體建置,就必須要思考更多的現實考量,包含執行環境、相關限制等等,而通常這塊,Software Engineering 是主力。
3.1 Construction Design
這裡談到的Design,比較接近實際實作時,所需要考量的設計,就像是建築設計師,通常會用一個小的模型來當作前導,並透過這樣的過程,來與目前大環境,不管是法規、或者是氣候現實問題,作為一個參考依據,同樣的,軟體的設計過程,也需要一個這樣的過程,可以藉此了解將來移轉到正式環境,所可能遭遇的狀況
3.2 Construction Language
4.1 api design and use
4.4Assertions, Design by Contract , and Defensive programing
Assertions : 有点類似Unit的預期結果跟時記結果的比對,如果比對到值可能有出入,可以早點發現問題
Design by Contract :假設,傳輸資料定好Contract , 就可以初步省略不一致的狀況
Defensive programming : 永遠不要相信User給的資料,初步的防呆或容錯都是必要
4.5 Error Handling, Exception Handling, and Fault Tolerance
程式碼設計畢需要考量到容錯,特別是當如果像SPI或Web Service接收到不是當時約定的資料格式,除了能減查出錯誤,並將資料Log下來,同時,以不影響其它功能流程為優先考量,確保這樣的錯誤可以被侷限在一個可以控制的範圍內。
4.6 Executable Models
類似Entity Framework , 從Model的角度出發,思考系統架構
4.7 State-Based and Table-Driven Construction Techniques
State-Based : 類似狀態機概念,透過有限的狀態切換來達到目的( 待討論 )
Table-Driven : Schema 優先,寫Code需要思考如何很容易的讀取跟儲存這些資料
4.8 Runtime Configuration and Internationalization
通常因為營運端的需求,及當下營運狀況,需要微調參數或讓使用者可以切換語系,設計都會將這樣的機致額外設計,方便在切換的時候的影響層面最低,如重起服務,踢出使用者等狀況。
4.9 Grammar-Based Input Processing
任何的Input ,主要是來自於使用者提供的部份,或與其它系統整合的部份,都需要特別去進行驗證,確認資料格式上或定義,如當時約定所述。
4.10 Concurrency primitives
這邊思考重點在於訊息是否同步。通常我們會透過許多方法,如信號燈、監控、互斥的設計,來降低資料共用,最後資訊不同步的狀況,例如AB同時修改一份文件,但是A先存檔,B後存檔,卻同時改掉A元先修改的不份。
4.11 Middleware
Java需要執行在Java VM上,Flash需要執行在Flash Player之上,這個VM或Player就是一個Middleware的概念,負責做一些資訊轉換,或語言轉換程成可被系統裡解語言。
4.12 Construction Models for Distributed
當如果系統要能夠發布到多台,或者是分散式架構,如N-Tier , 就必須要在設計階段,思考清楚資料流跟容錯能力,確保不會因為不同步造成資料錯亂。
4.13 Constructing Heterogeneous System
不同性質的系統,如果需要整合,就必須考慮到彼此的溝通方式,有介面可以轉換。像是RS232、藍芽、Wifi等方式,可以讓不同的設備透過傳輸方式,讓對方接收到資料,但是資料的解譯同時需仰賴文件支持。
4.14 Performance analysis and tuning
根據不同的資料類型與數量,需挑選適合的演算法,並且測試實際執行時間,去找出效能瓶頸點,重新設計該元件或DB IO的方式,減少IO次數,或者是改用低階語言減低VM的效能消耗,都是不錯的方法。
4.15 Platform Standards
通常,如果有照標準撰寫,就能在相容的環境中執行,像是Java自己有J2EE標準,或網頁自己的W3C標準。不過就實務上,即使用同樣的元件,在不同平台執行,還是有可能出現相容性問題。
4.16 Test-First Programming
Test-First programming (TDD)的設計架構,確保寫出來的Code有一定的品質,同時,當系統有異動的時候,可以先透過UnitTest進行初步的測試,確認是否有改到既有的邏輯。