前言
項目老大回家之前，讓我和另一個人剛入職的程序，看新的一版的戰鬥UI的案子。但工作推進缺交給了原來的程序負責。只有4天的開發時間，就由原來的人負責。
在驗收時間之前，出了一箇中間版本，有幾個問題。老大讓我幫忙看下。
在重新梳理了下當前的需求，我在代碼看到一個按鈕逐漸顯示的代碼。我感覺對了下一個版本的需求。發現目前代碼的無法滿足，下個版本功能的擴展。
梳理下代碼
UI部分和3D操作的部分功能分別由兩個人來實現。UI上的一些用了數組來控制對應的文字或者image。
從UI代碼來上，最大的問題，在程序設計上，不夠抽象。這是剛入門以及寫的功能不多。不會考慮未來策劃的需求變更，自己的代碼不夠健壯，陷入無限修復bug中。
還有一些邏輯代碼，一個函數在撿起的中，還有扔下的操作。函數最好單一功能。這中間造成的問題就是，數據一旦變化了，因爲設定，就會有一些自動邏輯。然後造成邏輯就不對了。
個人理解對需求的階段
對於策劃的需求
* 第一個階段是能實現策劃的要的效果
* 第二個階段是能抽象的思維，儘量減少使用數組用類來實現
* 第三個階段是有抽象思維，寫出的代碼考慮未來擴展需求。足夠健壯
* 第四個階段是對於數據結構的使用很有心得，注重代碼的效率，內存友好，時間上友好
策劃每個版本的需求都要有案子，有變化，也要及時更新案子
質量標準
1正確性：代碼能正確無誤的實現功能。
2健壯性：在軟件遭到意外情況時，仍然能健壯的運行。
3安全性：有效保護用戶隱私，非授權用戶不得使用，能夠有效防止黑客的攻擊。
4易用性：有必備的註釋，修改起來容易，遵循MVC設計理念，各個模塊之間耦合性低，易於維護。
面向對象
重新回顧面向對象的設計原則，並分別簡述它們的含義。
1） 單一職責原則 （The Single Responsiblity Principle，簡稱SRP）：一個類，最好只做一件事，只有一個引起它的變化.
2） 開放－封閉原則 （The Open－Close Principle，簡稱OCP）：對於擴展是開放的，對於更改是封閉的
3） Liskov 替換原則（The Liskov Substitution Principle,簡稱LSP）：子類必須能夠替換其基類
4） 依賴倒置原則（The Dependency Inversion Pricinple，簡稱DIP）：依賴於抽象
5） 接口隔離原則 （The Interface Segregation Principle，簡稱ISP）：使用多個小的專門的接口，而不要使用一個大的總接口。