通過這個小程序讓我看到了不少地方做的還是不好，下面記錄一下，謹作爲自己以後學習的參考。
1、抽象層次太低，思路不夠清晰：
客戶端線程的讀寫，需要單純抽離；
各個界面缺少統一的管理，致使不少變量封裝不好；
變量出現冗餘情況；
統一對接收到的數據進行處理不夠徹底
剛開始對程序結構不夠清晰，至於後來添加功能時有點混亂
對程序的邏輯處理還不夠到位，眼光還只着眼於當前，設計存在不合理的地方
2、對於費時間的處理實行多線程操作，對線程的理解還不夠深入。創建線程的時機把握不夠準確，線路處理的業務不夠清晰
3、對於程序的統一性做的不好，例如命名格式出現混亂
4、程序模塊劃分不夠清晰，出現不少代碼冗餘
5、服務器端雖然統一維護了5個數據存儲結構，即使同步了更新，但卻降低了服務器端的性能，代碼不夠精練，例如可以自己定義數據存儲結構的類，繼承map，然後再對外提供相應的數據訪問方法，對數據維護來說更容易、方便、簡潔。
6、程序的優化問題：
程序中依然有很多地方必須進行優化處理，比如服務器端的邏輯處理類，應該將公共的信息處理再進行抽離，例如一些變量的初始化、賦值、發送等都能抽離，讓每個類承擔獨自的責任，信息的處理不夠清晰。例如發送和接受的數據處理要分開，同時也不能太分散，同一類型的數據處理最好放到一塊。在服務器端可以將對所有用戶的操作跟對單個用戶的操作分開，並提供相應的方法調用。
對於服務器來說需要更多的優化，每一行代碼都應有其存在的必要性，特別是訪問頻率多的代碼，必須要進行優化處理，包括變量的定義，對象的創建，特別是那些耗資源的對象，如輸入輸出流，最好使用單例模式
7、在此程序的編碼方面，雖然使用了java，但更多的還是以一種面向過程的方式編寫的程序，思維還沒有完全轉換到面向對象上，對面向對象的理解不夠深入，完全沒有體現出面向對象編程的優勢
8、對於程序理解不夠清晰、準確、透徹。沒有徹底理解程序的功能，看待程序的角度，對於程序的設計方面還存在許多不合理的地方。當創建了一個對象時要想到將來誰可能用到此對象，可能會如何使用，並提供相應的方法提供服務。比如客戶端創建了一個Panel，應該思考此panel裏的內容，變量，功能，性能，如何獲取此panel，如何取得此panel以及對其中的變量進行操作，對panel中的事件進行驅動。
9、抽象層次太低。雖然使用了Object流、Switch結構、enum數據類型，可以在一定程度上可以方便一些功能的添加，但卻使得代碼一直在快速膨脹，代碼的複用率太低
10、參數傳遞要謹慎。在定義類時，構造函數參數的定義要謹慎，只定義必須使用的參數，降低對實例化該類的其他類的依賴性，降低類與類之間的耦合程度，最好可以是類獨立存在，可以將此類在任何地方實例化，如果參數越多會使得能實例化該類的地方越少。最好在開始時統一進行實例化，以後只需調用此對象提供的服務即可。