from:

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

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

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

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

回頭看看軟工課，問心無愧，結(jié)果會(huì)是怎樣就怎樣吧。

興趣-工作
當(dāng)初選題的時(shí)候，bbs這項(xiàng)功能是我提出來的，因?yàn)槲覍τ赽bs比較感興趣，想好好的研究一下，寫個(gè)帶有下帖、發(fā)帖、回帖甚至自動(dòng)搶整的東西玩玩。

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

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

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

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

程序員最無奈的事情
就是寫完自己的代碼調(diào)完自己的bug，發(fā)現(xiàn)bug仍是一個(gè)一個(gè)的出現(xiàn)，而且不是自己代碼原因的bug，不知道怎么修復(fù)，無從下手，干著急只能望bug興嘆……

    ——?jiǎng)㈢?/p>

4:31 AM | Blog it
Comments (3)

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

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

最重要的：人心齊、泰山移...俺就不多說了 :)
送一句鄒老師曾經(jīng)在MS^2培訓(xùn)最后階段給所有team說的話：腳力盡時(shí)山更好，keep moving!
 

xin 鄒欣 - Jan. 3, 2009 - Delete
>就是寫完自己的代碼調(diào)完自己的bug，發(fā)現(xiàn)bug仍是一個(gè)一個(gè)的出現(xiàn)，而且不是自己代碼原因的bug，不知道怎么修復(fù)，無從下手，干著急只能望bug興嘆……

別人的代碼，應(yīng)該能讓同組的人看懂吧。。。
移山之道里談到了蘿卜和白菜的故事，可以看看。

Ke Liu - Jan. 3, 2009
因?yàn)槲也磺宄遣糠止δ堋热缥也涣私饽衬硡f(xié)議，要去改實(shí)現(xiàn)某某協(xié)議的功能部分，那我就得先去好好的研究某某協(xié)議，這樣就太費(fèi)時(shí)了……而且按照分工，只需要負(fù)責(zé)實(shí)現(xiàn)那部分功能的人去研究就可以了