個人記帳軟體開發小結

連結：個人記帳軟體0.1版發布

首先說說失敗的地方吧（因為和別人的代碼比較起來，寫的確實比較爛）：

1、設計沒有文檔化。雖然前期設計也有個十天，但一直都是比較零碎的想法，而且都記到紙上沒有敲到電腦上文檔化。導致有的想法比較潦草的記到紙上後，下次再看又不知所以然了，更有幾次紙都不知道扔哪去了，所以周期才拖的比較長。下次開發的時候，應該強迫自己每天記開發日誌，把想到的問題、新的思路、瀏覽的資源都記下來。

2、過於關注細節，沒有重視整體。這幾天一直在看《設計模式精解》，作者認為以前的開發模式是探索需求的名詞與動詞，然後把它們分別轉換成類與方法，結果導致整體結構的不合理。而更合理的開發模式要求我們不能過早的把眼光放在細節上，要多考慮細節所處的上下文，也就是整體環境。拿到這個問題之後，我就憑直覺把它分割成資料訪問類、幾個WinForm類，沒太考慮設計模式方面的東西，代碼顯得很不優雅，具體說就是違背了“設計一次，多處使用”（把重複的地方封裝起來）的原則。比如對結點的處理，很多地方都對日、月、年、賬本結點作了重複的處理，在選擇、刪除、添加的事件響應裡面都有switch case這樣的爛代碼。其實設計個樹結點類，然後日、月、年、賬本分別繼承，用多態處理的話效果應該更好些。

    以前用Java作開發的時候，習慣是先考慮程式架構，到.NET之後，常常是不自覺的先想有什麼控制項可以用，沒了大局觀^_^。

3、沒用UML。以前總覺得作個小軟體沒必要用UML，其實UML不僅對大項目，個人項目也挺有用的。在開發到後期之後，類多起來，有時候自己都糊塗了，不知道該用哪個類的哪個功能，如果這時候有個類圖就好了。而在開發前期，如果畫了使用案例圖，時序圖，類圖指導後面的開發工作，後面的開發也就不會像打補丁一樣，哪缺往哪補。當然這也建立在充分設計的基礎上，我的兩個資料提供者就設計的比較粗糙，結果到後期老是缺功能就往介面裡添方法聲明，然後再改實作類別。在開發完後作第二版時，沒有這些圖可能自己都會忘哪個模組是作什麼的，也不便於與別人交流。等有時間了，一定好好把UML學一下。

4、沒有規劃。雖然不至於用到Office裡面Project這樣的大傢伙，但用個軟體記錄一下步驟總是不錯的。我總是寫了一個功能之後，忘了下面該作什麼，然後想老半天（我比較健忘）。後來發現VS.NET 2003下面的工作清單是個不錯的東西，就用這個記任務。不過我覺得它還是不夠強大，推薦一個ToDoList（http://www.abstractspoon.com/），免費，而且強大實用。

5、MainForm裡面代碼過多。雖然平時說MVC感覺就是作網站才用到，但就個人軟體而言，介面和功能也不該太耦合。我對樹結點的操作很多都放到MainForm裡面，等下一版的時候，一定好好精簡一下。

至於其他的版本控制、NANT、Bug記錄、日誌等等還不會，慢慢的去學了。

 

失敗的地方不少，但能讓我覺得好的地方還是有的。

1、迭代化開發。我給自己定的目標就是先把它作出來再說，功能上能用就行，麻煩的地方留著下一版再實現。如果想第一版就作的很好的話，估計等下一版出來之前我就沒鬥志了。過長的周期與過高的開發難度容易使人產生挫敗感，把目標分解，一個個去完成更好一些。

2、勤查資料。多查MSDN自然是老生常談，我習慣是直接看執行個體代碼，文字多了我頭暈，還好MSDN裡面的代碼寫的還不錯。另外CodeProject也是必須上的，它讓我很快就瞭解了XML、ADO.NET方面的知識，例子也很深入淺出，慢慢翻書會急死我的。部落格園裡面的好文章也很多，用站內檢索也能查出不少好東西。

    3、資料分類。資料多了，就必須分個類。我把圖片、參考文章、參考原始碼與程式目錄放在一起，同時對資源寫了一個索引（記錄這個資源對開發有什麼用），找起來就比較方便。

4、把開發過程中學到的技巧記下來，這樣下一次作同樣的事情就快多了。我把諸如MessageBox、TreeView、DataGrid等控制項的提示記了下來，有些自己又寫了樣本，如果下次用這些控制項的時候就會很容易上手。

 

以上就是我的感想，可能比較初級吧。如果覺得放首頁不合適，我就移到新手區裡。歡迎大家講講自己在開發個人軟體時的經驗。