注：第三章 三思而行：前期準備
首先要明確： 專案質量的關鍵不在於後期的測試工作，測試只是佔專案的完整質量，排查bug的一小部分，它不會糾正製造的「乙個錯誤的產品」，所以關鍵在於軟體構建活動之前的問題定義和需求分析。
小系統，風險低，需求簡單
中型系統，存在風險
大型系統，風險高，需求變化大
在構建之前，首先要滿足的乙個先決條件就是 ：對開發的系統要解決的問題做乙個清楚的陳述。問題沒找對，可能致使後面的構建解決錯誤的問題。
要以客戶角度，以非計算機語言來描述問題，對問題做乙個簡單的陳述。
1、需求明確，有助於使用者(而不是程式設計師)掌握系統功能，而且使用者可以自行評審，校準。
2、需求重在穩定，不穩定的需求在後續編碼中會花費相當大的**開支，而且 系統架構可能會混亂。
3、在構建中處理可能發生的需求變更。
4、需求checklist (p42)
架構師軟體設計的高層部分，適用於支撐整個細節設計的框架。
架構的組成部分：
1、程式組織
系統架構首先以概括的形式對有關系統做乙個綜述。定義程式組成的構造快，以及每個構造快所支撐的功能。
2、主要的類
架構應該詳細定義所用的主要的類，每個類的屬性，類之間的 關係。
3、資料設計
描述主要的資料檔案的訪問、儲存的設計。
4、業務規則
5、使用者介面設計
架構應該定義web頁面 、gui、命令介面等主要元素形式。
架構模組化，以便於在替換新使用者介面時不影響業務和程式輸出，同時還應該輕易做到 互動式介面和命令列之間的切換。
6、錯誤處理
大部分程式的**90%是用來處理異常，只有10%的**是用來處理正常邏輯功能，所以在架構中要制定一種統一一致的錯誤處理策略。
錯處理要考慮的問題，或者是錯誤處理的checklist
錯誤處理是進行糾正還是只是做檢測。糾正實際上是容錯；檢測可以繼續執行或者退出。
檢測時主動檢測還是被動檢測。
主動檢測 如：在使用者輸入引數時預處理
被動檢測 如：輸入引數處理之後產生溢位。
如何處理錯誤。
可以直接丟棄 錯誤資料
可以把錯誤進入到錯誤處理狀態
可以等程式處理完成，再通知錯誤
錯誤處理約定。應該建立一整套有關錯誤訊息處理的框架
7、容錯性
容錯的目標是系統出現錯誤之後，能夠通過容錯機制從錯誤中恢復過來。
容錯策略
檢測錯誤直接回退執行之前，再試有限次(具體在網路通訊中，網路或者裝置不穩定時)
使用備用**或者邏輯（實際就是if-else語句）
使用一種表決演算法(根據實際業務邏輯，該功能有多種方法實現，採用多種方法後，取結果的均值)
可以使系統功能退化或者跳過該錯誤處的功能（尤其是主功能出錯時，可以置乙個全域性開關，暫時讓系統空轉）
8、輸入輸出和安全性
住喲啊包括io模型的選擇、處理非信任資料(包括使用者的輸入輸出、cookies、配置檔案和外部介面輸入的資料)的規則、加密、錯誤訊息的細緻程度、保護記憶體中的秘密資料。
9、架構效能
指出系統使用的資源：速度、記憶體、成本之間的優先順序，以及存在的不可控風險。
10、國際化/本地化
主要考慮 字符集編碼的問題，中英文資源檔案之間的切換。
11、變更策略
架構最大的挑戰是，隨時面臨需求的變更，所以讓架構足夠靈活，能夠適應變化。所以架構要以系統的可變更性作為首要目標進行設計。
簡單的比如：在資料檔案中加入版本號、設定保留字段或者將檔案設計成能夠新增新的文段。
架構設計checklist 參考書本p54
vue 前期準備
瀏覽器外掛程式 vue.js devtools vs code外掛程式 自動補全標籤 auto close tag auto complete tag auto rename tag 開啟乙個伺服器瀏覽html網頁，第一次使用需要ctrl shift p輸入 live server選擇open li...
排序 前期準備
準備全面的把一些排序演算法過一遍.在此之前的準備有 1.亂序的陣列 2.對排序效率的度量 3.確定介面 一.亂序的陣列 即生成n個亂序的整數,程式設計珠璣當中介紹過相應演算法.以下介紹三個演算法 1.生成乙個隨機數,接著生成下乙個隨機數,若與之前的隨機數都不相等則加入陣列.直到生成到陣列達到足夠大 ...
開展軟體測試工作的前期準備
隨手記錄，零零散散，個人思考積累。1.明確測試目的 範圍 週期，做好方案計畫 目的明確，階段清晰，才能事半功倍。2.向使用者介紹本輪測試可能產生的影響 1 安全滲透測試，可能會損壞資料，影響服務的正常提供 2 效能測試，服務可能宕機 3.觀察伺服器資源使用情況 如果要測試乙個執行中的軟體系統，提前了...