書摘與心得 軟體預先架構之美學 Prefactoring

中文書名:軟體預先架構之美學

英文書名:Prefactoring

ch1

基本觀念

  • Extreme Abstraction

  • Extreme Separation

  • Extreme Readability

另一面向是把焦點放在介面(interface);想著介面,就能進一步邁向抽象化的目標,也就是說,要去想哪些元件能為你所用,而不是去想這些元件該怎麼運作。

預構無法保證你的設計不用做重構。

情境是一切。不同的路要準備不同裝備,而且要知道終點在哪理。

保持敏捷。

ch2

探討需求時,採用精簡過的使用案例(Use Case)或故事板(Stroy Board)記錄情境,用它跟客戶討論。在我們的團隊中,如果BA未寫Use Case,則用它跟BA討論。

不要重新發明輪子。如果系統的某個部份已有成熟、可靠的元件可用,就不要再重新開發。

系統中每個概念都要定義清晰的名詞。

結合兩個概念,比分離一個概念簡單許多。

把資料凝結可以簡少必須劉在心中的概念數量。例如:把street, no, state凝結成address。

用抽象資料型態(Abstract Data Type),建立模型時,避免使用基本資料型態。用顯態定型(explicit typeing)描述問題和解法,日後有需要時容易轉成隱態定型,但反向則困難許多。

避免一切都是字串。

不要只是為了實作上的考量而把類別合併起來。

快速的做出雛型。

ch3

從大藍圖開始

系統裡的設計決策應該和架構一致。

建立系統前,先對既存環境有所認知,可協助你節省開發時間。

介面規範

介面和使用該介面的人之間有個規範。規範的內容包含了該介面中每個方法的先決條件(precondition)和後續條件(postcondition)。先決條件主張,每個方法被呼叫時必為真,使其能執行運算,後續條件主張方法執行完後,應為真。

作者傾向於被呼叫的方法會特別在其程式中查核其先決條件。這些程式就是規範的記錄。

查驗

應該把來到系統的輸入資料,轉成其對應的抽象資料型態。

所有識別項目都應含有自我查驗值,以防止多數常見資料錯誤。

就分層系統而言,查驗工作都是在各層的邊界上,至於查驗什麼,則是根據每層之間所定義的規範。

把假設和決策形諸文件

錯誤處理和錯誤

找出你的系統會有那些誤差和錯誤,並決定如何處理。

誤差和錯誤發生時,回報給使用者的訊息應該對使用者有意義。訊息中應該包含盡可能多的資訊,說明該如何避開或更正問題。

ch4

系統初次成品完工時,我們想保有最少功能集(minimum feature set,MFS)。

過成

分析的中點是描述使用者需求(不是規格),而設計的重點是建立一套解決方案,使其滿足需求。

分析停滯

你不能花一輩子的時間,確認你的系統需求,你應該花時間瞭解基本的抽象化內容、基本的使用案例、以及每件事之間如何互動。

設計停滯

要確認類別的設計是否足夠,方式之一是利用你考量的類別運作使用案例,如果所有案例都能實施,很可能你已經抓住所有有意義的類別了。

初始設計

除非某人試著使用該概念,否則該概念不會被完整理解。

從大處規劃,從小處設計

如果我們的設計結果無法執行某些使用案例,繼續走下去之前,就得重做一遍。

有了最初一組類別之後,我們檢視每個使用案例,想弄明白會不會影響我們選配出來的類別。

檢測功能

系統開發的每個時點,你都應該建立檢測內容的草案,檢測內容可以包含基本的使用案例,以及日後討論時會出現的任何誤用案例。

AT與UT都要寫,而且最好可以自動化。

安全

安全不能事後諸葛,隨時都要考量進去。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s