这一个季度做了不少东西。

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天的时间，并且不应过于依赖全局性事件完成调用，只会增加复杂度和性能消耗。