一次獨立開發的體會
by leetaolion
         很長時間以來，自己都是一個靠著改別人的程序過日子的人。
         前一段時間終于有機會獨立開發一個模塊，有一些感慨，記錄下來。主要是為了給自己在某個不清醒的時候潑一瓢冷水，更有人欣賞的話，幫忙添加寫評論，幫點迷津。
首先還是按照時間的先后順序來反省吧。其實寫出反省是老大不情愿的，反省是一方面，主要還是為了懲前毖后，治病救人嘛。
         整個模塊的需求的提出和整體的思路并不是我提出來的，而是由別的項目組提出來的，我只是借用了人家的思想，實現了一下，實現了人家思想的雛形。至于完備的實現，怕是沒有人拿鞭子抽我，我是不會主動去做的。這正驗證了那句話，如果沒有設計文檔的約束，開發人員會越來越偷懶，哪怕是最老實的開發人員，也會想盡辦法偷工減料。

         需求分析，是一個很講究經驗、技巧的階段，以前我認為需求分析做得好的人不一定是編程非常棒的人，當時在一個小的團隊里，我的想法是錯的。要把需求分析做好，那好的需求分析結果是什么洋子的呢？有什么特征，比如說兩個腦袋之類，讓人過目不忘的特征？或是瑯瑯上口那種？
總結一下撒：
         好的需求分析，不是簡單的總結，更重要的是分析，來源于用戶的需求，又高于用戶的需求。這樣說有點太玄了，就是需求分析總結出來的功能點，不單要覆蓋到用戶的直接需求，還要為用戶的次生需求提供足夠的擴展空間。
         分析的結果要記錄在案，免得自己日后不認賬。需要一種監督的力量，這種力量是很難得的，最靠譜的做法是群發給所有人，這樣就在別人那里記下了一筆賬，等你提交Demo版本的時候，大家都掏出賬本，一筆一筆的兌現。

         設計是回答需求分析歸納出來的功能點，一個功能點就是一個問題，設計就是回答這些問題。
問題的回答首先有個大綱，這個跟寫作文一個道理，HOHO，我寫作文從來不寫大綱，所以小學初中的時候天馬星空，深得老師贊賞，到了高中就廢廢了，sigh。
         概要設計就是這個大綱，所謂大綱，可以浪漫些，理想主義一些，把軟件想的完美一些，如果是設計完了是自己來實現，怕是多數人不會選擇這種風格，怕是實現不了，或者實現起來很難，豈不是搬起石頭來砸自己的腳。所以，很大程度上要靠責任心，這年月，什么最貴？責任心。其實，只要設計出來，實現都是沒有問題的，以上的一些逃避的想法，其實是對自己的技術不夠自信導致的，是一種對于未知世界的恐懼敢在作怪。對付這種恐懼，別無他法，只有武裝自己。
         這一步也要記錄在案，不然，本來就捉襟見肘的設計，最后在偷懶的本性的剝蝕下，會變得慘不忍睹。

         概要設計列好了大綱，下面是詳細設計。詳細設計階段對設計人員有一個要求，就是在這時候，設計者應該能透過概要設計畫出的藍圖，看到實現的細節，甚至是具體代碼。要不然，如何定義接口呢？在接口的設計上是有一些慘痛代價的，能犯的錯誤，基本上一個不拉。設計到最后，大量的重名函數，由個更名帶來的接口污染，由于態度曖昧造成返回值類型的濫用，接口類型的不確定，參數時多時少，總是不恰好。尤其是到了編碼階段，如果這些地方出現錯誤你算算需要維護多少分文件，實現文件算一份，頭文件一份，接口文件一份，再加上開發文檔、類圖，牽一發動全身，一處錯誤，到處修改（貌似Java的特性）。
         這些都是教訓，那經驗呢？
         我想，如果有一個東西能控制這整個過程，那就是類圖吧。類圖修改起來容易，而且很直觀，如果要用好類圖，就不要吝嗇你的腦細胞，整個操作流程設計的細枝末節都要細細斟酌，這樣才算沒有糟蹋UML這樣一把牛刀。

         如果有凌波微步的功夫把前面三步走都走的很瀟灑的話，后面的工作可以說是水到渠成了。可惜，這樣的功夫我暫時還不具備，摔了幾跤，爬起來，拍拍身上的泥土，擦干凈身上的狗屎，繼續前進。
到了編碼這一步，我的最大體會就是，如果你沒有把前面幾步蹚明白就貿然走進這一步的話，會碰得灰頭土臉。不要怕過度的設計，現在的問題是設計不夠，說明白點，就是沒有在設計階段，把全部的精力都放在設計上。

         在編寫代碼的第一步編寫測試用例，我想多數人接觸這個東西的時候心里都是感覺怪怪的，老是想著，我的button+label的法寶不是屢試不爽的嗎，干嘛要這勞什子。試用之后，發現這是個有遠見的好點子。首先人家實現了科學管理，試想一個全部靠button+label實現的測試，測完之后不知道扔到那個廢紙堆了。用工程來管理測試用例，形式上是一種進步。實質上呢，當聯調的時候發現問題，逐個跑一下測試用例，很快定位錯誤所在，這時候你才能體會到當年的辛苦是值得的。其實這些只是享受到這些方面的便利，就好比是買了一大塊巧克力，舔一舔就扔掉了，浪費大了去了。人家設計這種開發模式的初衷是為了更好地在編碼中體現設計的指導作用，更好地貫徹設計指導開發的思想。當然，這一點暫時還沒有深入我心，我只是在一個接口不多的小模塊上實踐了這種模式。

         一開始不進行代碼版本控制，出現代碼管理混亂，常常分不清哪里是新代碼，哪里是老代碼。翻了半天，要靠右鍵屬性通過時間來判別，有時候文件夾亂放，每一次都要翻箱倒柜。還好，星之隊拯救了我。

         當然，還是有一些好的經驗的，比如常常召喚出兩個勝利女神來，一個正常開發，一個快速的button+label驗證對xx的小想法。

         最大的問題還是對時間的控制，控制好時間，就控制了一切。