1.密碼管理邏輯。

　　為了避免程式碼冗餘可能造成邏輯混亂，我採用一頭一尾檢測規則，即在第一次錄入和需要解密的時候進行規則轉換，其餘操作不再涉及規則演算法。

2.資料檔案結構。

　　這裡主要涉及的新老結構的相容性考慮，為了相容舊流程，往往不會改變原結構，然而這樣做實際上在給後續工作埋雷，特別是舊結構對需求完全不支援的時候，單純通過對舊結構中的標識部分新增列舉元素來判斷是不可靠的，為了區別新資料，每一次呼叫都要讀取檔案進行判斷，反而增加了流程的複雜程。

　　同時還要記住，在這種情況下，如果對新增的資料部分進行編輯，可能會使原檔案無效，因為流程上通過列舉判斷後，只會進入該類資料的讀取流程，如果新資料部分發生變更，很可能導致原資料無法正確讀取。

　　通過一個例子來更明確地闡述這種情況，假設舊檔案結構寫入"A123123"，其中“A”代表需要判斷的列舉元素，“123”代表一個不相同資料片段，那麼新檔案需要寫入的是“B123X123X”，很明顯，現在我們可以通過讀取Stream的第一位來判斷該檔案需要進行哪一個讀取流程，之後純資料部分不論“123”還是“123X”都可以順利讀出，但是如果需要對“X”進行編輯呢？最直接地，當我們移除“X”之後，新檔案變成了“B123123”，那麼當下一次被判斷後進入B讀取流程時，“X”的位置被“1”取代，進而導致整個檔案的讀取結果無效化，有人可能已經發覺，“X”的寫入，事實上是對每一個數據片段新增了一個“結構”，只有賦予這個結構可供判斷的意義，才能解決這個問題，然而要記住，實際應用當中，每一次都通過資料片段來判斷“X”的狀態是非常複雜的，單純通過長度來判斷不一定可靠。因此在標識部分新增結構是有必要的，”B@123X“，對”X“部分編輯後，只需將相應的狀態寫入”@“即可，這樣既不需要考慮資料片段的複雜性，在讀取時只需要進行一次讀取判斷即可。

3.通過Process呼叫CMD。

　　我遇到的問題是執行命令之後遲遲不進入WaitforExit()，網上倒是有很多WaitforExit()死鎖的問題，綜合比較後我判斷應該是Stream沒有完全關閉的問題，事實上在對CMD操作時，不需要啟用outStream和errorStream，inputStream執行命令後close()即可，事實上我認為只要啟用的都關閉，就不會出現死鎖。

4.摸魚的介面。

　　事實上近一年以來，介面我感覺是老生常談了，如果有明確的介面規範，可以節約至少1天的時間，並且不應過於依賴全域性性事件完成呼叫，只會增加複雜度和效能消耗。