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

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

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

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

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

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

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

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

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