現代軟體工程系列 學生精彩文章(7) 寶貴的教訓

from http://codecanvas3706.spaces.live.com/blog/cns!5A77585898179960!205.entry 

[當學生的時候, 最好犯一些錯誤,  經曆一些失敗.  不經曆一些慘痛的失敗, 難道要到工作的時候才失敗麼? ]

個人的失敗感言

記得在讀完了《夢斷代碼》之後，我也只是為chandler項目感到一點點惋惜，感覺軟體有那麼一點點難做。但是今天我卻從我的失敗中體會到了他們的另外一種心境。我不知道為chandler花費了3年的精力，為chandler費盡心血的卡普爾在項目失敗的時候，承受了多大的打擊。而我所能體會到得是：將近兩個星期，每天7個小時的精力付之東流之後，有一種讓人窒息的失落感。軟體難做，這不是假的！也許程式員必須在這種現實的無奈和鬱悶中成長。

今天淩晨。無意中搜到的MSDN對hook的定義把我對於分程式音量大小的想法，思路全都被給否定了，所有的工作必須從頭開始，可是時間已經不夠了，無奈，只能把它給砍了。

本來我是想通過api 鉤子勾住進程向系統發送的特定請求，然後再調用自己的邏輯代碼來控制聲音訊息的播放，來達到分程式音量大小的目的。可是，hook的定義是：

A hook is a point in the system message-handling mechanism where an application can install a subroutine to monitor the message traffic in the system and process certain types of messages before they reach the target window procedure.

Hook只能勾住系統向表單發送的訊息，不能勾住進程向表單發送的訊息。我這顆幼小而脆弱的心靈就這樣被他深深地刺痛了。

現在只能總結一下教訓了：

1. 基本上我從來就沒有用過windows API，對其一無所知，這使我花費了大量的時間和精力在api的入門上。我覺得使用一種你完全不熟悉的技術從事開發，效率可能為負值。今後對於一些基本的主流技術，都應該有一些瞭解。

2. 從今天的局面來看，我一開始的方向就是錯的。我只是想當然的認為hook能夠滿足我的需要，而沒有仔細的去看他的官方定義，如果能夠早一點理解hook的官方定義，那麼我也就不需要在這上面花費大量沒用的精力了。我覺得，對於你想要使用的關鍵的技術，一定要有深刻的認識，或者至少應該理解其能幹什麼，不能幹什麼！而官方的定義顯然是最重要的參考依據！

3. 不管做什麼你不能一開始就是錯的，方向性的錯誤真的是會要了人的命呀！所以軟體開發不應該倉促地 入手，你花在分析階段的時間越短，你開發的時間可能會越長，因為大部分時間花在了無用功上面。而我基本上是沒有分析就入手了。

4. 一個人是很容易犯錯的。在這一段時間裡，基本上我是在孤軍奮戰，因為我們的項目分了好幾個相互獨立的功能模組，每一個人負責一部分。這就使得我對自己的東西只是有一種片面性的瞭解，團隊其他人員沒能給予我協助，因為大家基本上都是這方面的新手。雖然說web是最大的知識錦囊，但是盲目的搜尋很難獲得實質性的東西。我覺得項目的開發小組中，至少應該有一個人是某一個方向的專家，這樣的話才能夠給予開發人員指導性意義的協助。當然，我們現在都還是學生，大家都在學習，這個條件是不可能滿足的。

以此共勉，希望cc小組能做得跟好，加油！！！

———林江

6:31 AM | Blog it

Someone on Windows Live

Comments (6)

xin 鄒欣 - Nov. 28, 2009 - Delete

很好的總結!
很多同學畢業找工作的時候，在簡曆上寫自己“精通Windows 編程”，但是還不知道MSDN是什麼東西。 你已經比他們好多了。

健 - Nov. 28, 2009

江哥，說實話，看到這篇日誌，面對你每天7個小時的經曆投入，我很慚愧。
你比我執著，我一周就放棄了檢測耳機插拔的工作。
感覺我上周末就這感覺吧。。。很失落！但是希望馬上轉向其他的方向，從新開始一塊工作，一起加油！
說點兒個人的小觀點：可能咱們組的分工導致每個人單獨奮戰，確實方向上和思路上容易出錯和進入死胡同。
這樣的分開開發，確實感覺不是我們在開發一個軟體工程，而更像每個人開發一個小軟體，然後最後拼在一起，少了相互的溝通促進，有些工作的落實和進度、難度、出現的問題，容易出現錯誤判斷……

TEAM CC - Nov. 28, 2009

同樣身為小組成員之一，首先是對江哥深深的佩服，將最難的一塊接下，每天7小時，這是我不敢想象的，慚愧慚愧。其次，說實話我也感受到了計劃不足所帶來的困難，前一段時間幾乎天天都在群裡向大家詢問各種技術問題，我覺得有很多如果在代碼之前的設計時就計劃好的，那後來的工作會高效很多。或許這學期繁多的大作業讓大家無心設計，只想著趕緊開始趕緊開始。之後便導致了每天至少5小時在軟工上，可是進度卻進展比較緩慢。設計出的東西達不到大家期望的要求。
還有一個星期就要發布alpha版本了。我們要爭取把能做好的做好。小iDLE可能不一定會成為多麼優秀的軟體，但是它一定會記住我們CC小組每一位成員的成長。江哥加油！！！
----HP

TEAM CC - Nov. 28, 2009

我的回複在下一篇日誌裡@ @
總之，對不起，以及萬分感動>____<
——成

超 周 - Nov. 29, 2009

讀過，共勉！

Someone on Windows Live - Nov. 29, 2009

抱歉提出了hook的方向建議。相信江哥完成後就成這個方向的專家了！

 

 

PM之不得不說的一些話

看了林江的那篇日誌，感動萬分，也愧疚萬分。從TeamWork正式開始到現在的兩周時間裡，從沒有方向一無所知，和大家一步一步的走到這裡，有很多感慨都沒來得及說。這篇日誌，算是個人總結，一表心聲吧。

一、道歉

在《移山之道》裡，關於PM是這麼描述的

Program Manager（程式經理）做的是開發與測試之外的所有事情。有些同學會問 “我寫程式都不用測試，那麼除了開發與測試之外還有什麼事兒?”在公司裡開發商業軟體可沒有那麼簡單，比如有10個Dev和5個Test 要在一起開發下一個版本的MSN Messenger，那我們到底要做多長時間才能完成？什麼事情先做，什麼後做？項目進行了一半的時候，領導說我們改名叫Live Messenger吧，那這一改名意味著什嗎？如何調整進度？最後還剩下兩個月的時候，看起來我們的確完不成全部任務，那要怎麼辦？你又不是Dev和Test的老闆，他們憑什麼聽你的呢？這也是PM的苦。PM的樂看起來在於，他們可以全盤掌控一個產品，廣泛瞭解一個行業，和使用者打交道，代表團隊出席各種會議，在公司內部的曝光度也比較高。

老師在課上講到了，PM的工作，應當是總攬全域的。顯然，我個人的能力還遠沒有滿足對PM的要求。首先，我沒有辦法提供技術性指導，特別是在WindowsAPI以及線程的方面，我的瞭解也甚少。甚至是在分配任務的時候，我也對“耳機插拔感應”以及“分程式調節音量”的難度沒有認識。陳健和林江兩位同學遇到的困難，也有我的責任。他們兩個人的辛苦，我是看在眼裡的；而那種從頭學起，資料難查又屢屢挫敗的感覺，我個人又何嘗不理解呢。同時，毋哲和張弓兩人也是憑著自己的毅力，克服了那麼多困難，完成了兩個實際上很有難度的功能。

因此，在這裡對CC組的全體成員們表示深深的歉意，以及敬意。

經過了這些事情，我也獲得了很多教訓。第一、選題上，不該在未瞭解難度的情況下，貿然定下一些功能，導致了小組成員的無謂辛苦。第二、分配工作上，同樣不該在不太瞭解難度的情況下分配任務。第三、也是最根本的，自身知識的不足，才是導致上面兩個問題發生的原因。

二、感謝

感謝CC小組全體成員！雖然是很老套的話，但是仍然要說。

為了完成這次的TeamWork，小組的每個人都付出了很多的時間和精力。之於我個人，我從小組開發的過程中獲得了很多快樂。並不是敷衍的謊話，而是真的覺得，一個小組的人一起散發調查問卷，一起寫一個部落格空間，一起在群裡討論互助，一起去食堂吃飯，甚至在累的時候一起喊……這些，遠比一個人去開發一個軟體要快樂得太多。

似乎還沒到收工的時候，因此就先打住吧。

總之，能夠獲得大家的信任成為PM，我十分感動。從此次經曆中，我學到了很多。也希望今後，我能不再重蹈覆轍，成為一個真正值得信任的Program Manager。

4:24 PM | Blog it

Someone on Windows Live

Comments (2)

xin 鄒欣 - Nov. 29, 2009 - Delete

> 在《移山之道》裡，關於PM是這麼描述的...
我記得這些描述是在《編程之美》 中的。

TEAM CC - Nov. 29, 2009

說實話：感覺你做得相當好了！我覺得咱們組的氛圍真的很好，尤其我從一開始的由於自己的部分沒有進展，而其他組員都進展很快，不好意思參加小組的討論，到PM和組員的理解，積極加入咱們組的討論，當時很感動。。。
這次軟工，我一般多的時間也是在資料的尋找上，儘管最後沒有結果，但是對一個軟體，或者功能的實現也有了進一步的瞭解……
team cc 加油！