寫在前面 嗯，首先是java,這學期第一次oo作業佈置下來的周末才開始看的，第一次作業因此寫得有些手忙腳亂。不過大概看了一遍後發現比c好用，入門更簡單吧，好多操作直接import一下就能用了，碼代碼的時候只需大概想想實現思路就好了，還是蠻好用的。 第一次作業 Metric的度量 程式的類圖 分析 第 ...
寫在前面
嗯，首先是java,這學期第一次oo作業佈置下來的周末才開始看的，第一次作業因此寫得有些手忙腳亂。不過大概看了一遍後發現比c好用，入門更簡單吧，好多操作直接import一下就能用了，碼代碼的時候只需大概想想實現思路就好了，還是蠻好用的。
第一次作業
Metric的度量
程式的類圖
分析
第一次寫得一般般，然後我出的bug是把ERROR複製的時候複製成了ERRO，跪了一個公測點，（我再也不亂複製不檢查了）。不過發現別人正則表達式寫錯了。這些都是些小的細節，註意一點就好。（一定好好檢查）我自己寫的時候面向對象的思維還不太成熟，只是像之前寫函數一樣分成了幾個class，沒完全把多項式封裝好。然後通過第一次互測發現測試數據一般找不出什麼bug，仔細閱讀他人的代碼才是最好的方法。。。
第二次作業
Metric的度量
程式類圖
分析
第二次作業結合第三次作業來說，沒有太好的考慮程式後續的可延展性？就是在做第三次作業的時候發現這次作業不太好進行調度策略的修改。第二次作業我採用的是離散的通過邏輯判斷同質請求，因為寫著比較快，並未採用時間的模擬。這次作業沒出什麼大的問題，但電梯類的作用沒有體現出來。主要的操作還是在controler里實現的，可以將電梯的狀態進行封裝，但因為這次電梯的狀態的重要性並不能體現出來，而且還是開始的設計不太好，所以做成了這個樣子。然後就是為了避免crash和簡單的判斷error，學了學try catch，嗯，確實挺好用。
第三次作業
Metric的度量
程式類圖
分析
這次作業確實吃了很多虧。首先是發現上一次作業的設計思路難以延展，就得重新進行設計。最後我選擇了進行時間的模擬，這樣的話，程式比較直觀。但編寫過程中因為對指導書的理解問題，進行了茫茫多的debu和修改才弄出來。稍微有點趕，所以忘了點東西，比如大數輸出的處理。其實第二次作業我就做好了，後面寫著寫著就忘了，直接把時間強制轉換成了int，沒用printf結果就被找了個bug。還有就是因為和上次比較相似，readme就是大概改了一下，沒認真寫好。然後就被別人找了INVALID和SAME後輸出的request的格式問題（只是把指令處理好了輸出，readme沒寫清楚應該是什麼格式。。。）嗯，以後一定認真對待的。還有就是以前一直認為readme是限制測試者的，其實通過別人給我找的一個沒有有效輸入的情況的bug。我認識到了readme應該寫成給一個什麼都不明白的人教他使用程式的這種感覺。這次測試起來也確實比較難想數據。除了測試樹外，特殊的情況太多了，還是和別人討論了下可能的情況才弄出的測試數據。經過量化分析，這次的調度類的嵌套太多，以後應該註意。
總結
在寫代碼前一定得好好的考慮設計的問題，第三次作業就是在實現的時候發現考慮掉了很多的問題，在已經完成的程式中嵌套添加了太多的內容，導致其變得複雜。然後每個項目最好還是有工程化的思維吧，就想第二次和第三次作業，雖然第二次寫得很容易，但只能單一的解決特定的問題，到了第三次作業就特別不好修改代碼，只能重寫大量的方法，修改思路。一定不要立刻上手編碼，先好好想想再說吧。。。
