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

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

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

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

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

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

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

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

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