现代软件工程系列 学生精彩文章(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 加油！
總結
以上是生活随笔為你收集整理的现代软件工程系列 学生精彩文章(7) 宝贵的教训的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 在电脑上显示未知发布者怎么办_电脑提示未
- 下一篇： 软件教育随想