現代軟體工程系列 學生的精彩文章 (3) 如何在Bug 不斷的情況下還能保持平常心… [zz]

from:

http://teamkingofcsharp.spaces.live.com/blog/cns!59FC2D3DD66822AA!222.entry

感想
平常心
初中的數學老師常常和我說：“你要學會保持一顆平常心”。我是一個不那麼豁達開朗的人，對很多事情都會很看重，GPA，排名，遊戲的輸贏，等等。把事情看得重了，就容易斤斤計較。這些日子趕軟工的project的時候，我在為coding和debuging焦頭爛額的時候，時而會想起組裡那些清閑的人，心裡難免不平衡：“憑什麼他們就可以這麼悠閑自在”。這種不平衡多了，不滿的情緒也就越積越多，直接導致了我的上一份感想，或者更確切的說，牢騷。發完之後我覺得心裡舒坦多了，很有一種一吐為快的感覺。

第二天是元旦，我參加了一個老鄉的聚會，互相談論著家鄉的變化和身邊的趣事。整整九個小時，只有開心的交流，沒有煩人的軟工，讓我的心情一掃前幾天的陰霾。我忽然發現，之前連著十幾天，我每天都是被軟工困擾著、煩惱著，“軟工”、“分數”，就像兩塊大石頭，壓得我喘不過氣來。我好像是把“軟工”、“分數”看得太重了。這讓我想起了我苦心經營了三年的GPA，雖然看到成績單的時候還是能小小的得意一下，但是這三年追求GPA的日子，確實有點太累人了。

生活中有太多比這區區一門軟工課精彩和重要得多的東西，又何必讓它成為一種負擔呢？很多事情沒必要太過看重，用一顆平常心去對待它。

回頭看看軟工課，問心無愧，結果會是怎樣就怎樣吧。

興趣-工作
當初選題的時候，bbs這項功能是我提出來的，因為我對於bbs比較感興趣，想好好的研究一下，寫個帶有下帖、發帖、回帖甚至自動搶整的東西玩玩。

興趣是最好的動力。team project的第一個月，我基本上都在摸索bbs的各個細節，琢磨功能實現，並且樂此不疲。對於我來說，這些功能就是為我自己做的，我的target使用者就是我自己，我甚至不care別人會不會想用這些功能。

可惜的是，作為一項Team Project，這個軟體的使用者不能僅限於我自己，我們也需要考慮別的target users。為自己寫軟體很簡單，我只要自己會用就行了，好不好看，User Experience好不好，只要自己不care，啥都無所謂。但是，考慮到這是一個同時面向其他使用者的Team Project，事情就多了：好不好看，有沒有足夠的提示資訊，操作是不是人性化，某些情況下哪些操作是不允許的以免出現bug，效能穩定不穩定，以及能不能按時發布release，都是比較煩人的問題。特別是如果問題較多的湧現而deadline又逼近，著實讓人煩躁頭疼。

這或許就是興趣和工作的區別吧。就像很多人很喜歡打魔獸，但是如果讓他們去當職業玩家，為了贏得比賽不得不每天練習幾十盤，估計很多人都受不了。

需求文檔的重要
上學期的軟工，每個組都要求寫需求和設計文檔。當時覺得這是一件無聊又費事的差事。不過這個學期，我也逐漸意識到需求文檔的重要了。上學期每個組只有3個人，組內交流起來還是非常方便的。但這學期，人多了，問題也就浮現了。給某人分配一個任務，讓他實現某某函數，但是如果沒有細緻的說明的話，還是很容易出錯的。比如，分配一個“刪除檔案夾”的函數，如果沒有相關說明的話，很可能dev直接就把檔案夾刪除了事了。但是，有可能，使用者是設定了一個郵件帳號，要把郵件下載到那個檔案夾的。現在檔案夾被刪了，郵件一下下來，發現檔案夾不存在，就會出錯了。雖然我們成員住的基本都比較近，交流起來挺方便，但是感覺如果有一份詳細的需求文檔，還是能極大程度的避免上述情況的出現的。（當然，有很多情形是因為事先沒想到這種邊界情況，這也就需要pm擁有很全面的邏輯思考能力了）

程式員最無奈的事情
就是寫完自己的代碼調完自己的bug，發現bug仍是一個一個的出現，而且不是自己代碼原因的bug，不知道怎麼修複，無從下手，干著急只能望bug興歎……

    ——劉珂

4:31 AM | Blog it
Comments (3)

 

Yuan CHEN - Jan. 2, 2009
>>感覺如果有一份詳細的需求文檔，還是能極大程度的避免上述情況的出現的
Agile manifesto裡第二項就是：Working software over comprehensive documentation。而且文檔會引入新問題，比如某人出了問題後可以理直氣壯地跟你講：“spec沒那麼寫，我當然就沒那麼做了”。而且按咱們的水平，設計不可能一開始就做得很好，開發過程中三番五次改spec設計的話，我估計又有人要發飆了……
btw：私以為把"需求文檔"轉成“feature的設計”是最難的過程...

>>就是寫完自己的代碼調完自己的bug，發現bug仍是一個一個的出現，而且不是自己代碼原因的bug，不知道怎麼修複，無從下手，干著急只能望bug興歎……
有一種“奇巧淫技”叫做Test driven development，一種quality ensurance的開發方法，用一堆test case去限定代碼的行為，如果別人寫的代碼有問題，那就用自動化的測試使其自己fail掉（在它們進入你的視線前:)）...

最重要的：人心齊、泰山移...俺就不多說了
送一句鄒老師曾經在MS^2培訓最後階段給所有team說的話：腳力盡時山更好，keep moving!
 

xin 鄒欣 - Jan. 3, 2009 - Delete
>就是寫完自己的代碼調完自己的bug，發現bug仍是一個一個的出現，而且不是自己代碼原因的bug，不知道怎麼修複，無從下手，干著急只能望bug興歎……

別人的代碼，應該能讓同組的人看懂吧。。。
移山之道裡談到了蘿蔔和白菜的故事，可以看看。

 

Ke Liu - Jan. 3, 2009
因為我不清楚那部分功能……比如我不瞭解某某協議，要去改實現某某協議的功能部分，那我就得先去好好的研究某某協議，這樣就太費時了……而且按照分工，只需要負責實現那部分功能的人去研究就可以了