from:

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

?

感想

• 平常心

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

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

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

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

• 興趣-工作

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

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

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

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

• 需求文檔的重要

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

• 程序員最無奈的事情

就是寫完自己的代碼調完自己的bug，發(fā)現bug仍是一個一個的出現，而且不是自己代碼原因的bug，不知道怎么修復，無從下手，干著急只能望bug興嘆……


??? ——劉珂
4:31 AM?| Blog it

Comments (3)

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

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

最重要的：人心齊、泰山移...俺就不多說了 :)
送一句鄒老師曾經在MS^2培訓最后階段給所有team說的話：腳力盡時山更好，keep moving! xin 鄒欣 - Jan. 3, 2009 - Delete >就是寫完自己的代碼調完自己的bug，發(fā)現bug仍是一個一個的出現，而且不是自己代碼原因的bug，不知道怎么修復，無從下手，干著急只能望bug興嘆……

別人的代碼，應該能讓同組的人看懂吧。。。
移山之道里談到了蘿卜和白菜的故事，可以看看。
Ke Liu - Jan. 3, 2009 因為我不清楚那部分功能……比如我不了解某某協議，要去改實現某某協議的功能部分，那我就得先去好好的研究某某協議，這樣就太費時了……而且按照分工，只需要負責實現那部分功能的人去研究就可以了

總結

以上是生活随笔為你收集整理的现代软件工程系列 学生的精彩文章 (3) 如何在Bug 不断的情况下还能保持平常心...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。