现代软件工程系列 学生精彩文章(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 加油！
