from:

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

感想
平常心
初中的数学老师常常和我说：“你要学会保持一颗平常心”。我是一个不那么豁达开朗的人，对很多事情都会很看重，GPA，排名，游戏的输赢，等等。把事情看得重了，就容易斤斤计较。这些日子赶软工的project的时候，我在为coding和debuging焦头烂额的时候，时而会想起组里那些清闲的人，心里难免不平衡：“凭什么他们就可以这么悠闲自在”。这种不平衡多了，不满的情绪也就越积越多，直接导致了我的上一份感想，或者更确切的说，牢骚。发完之后我觉得心里舒坦多了，很有一种一吐为快的感觉。

第二天是元旦，我参加了一个老乡的聚会，互相谈论着家乡的变化和身边的趣事。整整九个小时，只有开心的交流，没有烦人的软工，让我的心情一扫前几天的阴霾。我忽然发现，之前连着十几天，我每天都是被软工困扰着、烦恼着，“软工”、“分数”，就像两块大石头，压得我喘不过气来。我好像是把“软工”、“分数”看得太重了。这让我想起了我苦心经营了三年的GPA，虽然看到成绩单的时候还是能小小的得意一下，但是这三年追求GPA的日子，确实有点太累人了。

生活中有太多比这区区一门软工课精彩和重要得多的东西，又何必让它成为一种负担呢？很多事情没必要太过看重，用一颗平常心去对待它。

回头看看软工课，问心无愧，结果会是怎样就怎样吧。

兴趣-工作
当初选题的时候，bbs这项功能是我提出来的，因为我对于bbs比较感兴趣，想好好的研究一下，写个带有下帖、发帖、回帖甚至自动抢整的东西玩玩。

兴趣是最好的动力。team project的第一个月，我基本上都在摸索bbs的各个细节，琢磨功能实现，并且乐此不疲。对于我来说，这些功能就是为我自己做的，我的target用户就是我自己，我甚至不care别人会不会想用这些功能。

可惜的是，作为一项Team Project，这个软件的用户不能仅限于我自己，我们也需要考虑别的target users。为自己写软件很简单，我只要自己会用就行了，好不好看，User Experience好不好，只要自己不care，啥都无所谓。但是，考虑到这是一个同时面向其他用户的Team Project，事情就多了：好不好看，有没有足够的提示信息，操作是不是人性化，某些情况下哪些操作是不允许的以免出现bug，性能稳定不稳定，以及能不能按时发布release，都是比较烦人的问题。特别是如果问题较多的涌现而deadline又逼近，着实让人烦躁头疼。

这或许就是兴趣和工作的区别吧。就像很多人很喜欢打魔兽，但是如果让他们去当职业玩家，为了赢得比赛不得不每天练习几十盘，估计很多人都受不了。

需求文档的重要
上学期的软工，每个组都要求写需求和设计文档。当时觉得这是一件无聊又费事的差事。不过这个学期，我也逐渐意识到需求文档的重要了。上学期每个组只有3个人，组内交流起来还是非常方便的。但这学期，人多了，问题也就浮现了。给某人分配一个任务，让他实现某某函数，但是如果没有细致的说明的话，还是很容易出错的。比如，分配一个“删除文件夹”的函数，如果没有相关说明的话，很可能dev直接就把文件夹删除了事了。但是，有可能，用户是设置了一个邮件账号，要把邮件下载到那个文件夹的。现在文件夹被删了，邮件一下下来，发现文件夹不存在，就会出错了。虽然我们成员住的基本都比较近，交流起来挺方便，但是感觉如果有一份详细的需求文档，还是能极大程度的避免上述情况的出现的。（当然，有很多情形是因为事先没想到这种边界情况，这也就需要pm拥有很全面的逻辑思考能力了）

程序员最无奈的事情
就是写完自己的代码调完自己的bug，发现bug仍是一个一个的出现，而且不是自己代码原因的bug，不知道怎么修复，无从下手，干着急只能望bug兴叹……

    ——刘珂

4:31 AM | Blog it
Comments (3)

 

Yuan CHEN - Jan. 2, 2009
>>感觉如果有一份详细的需求文档，还是能极大程度的避免上述情况的出现的
Agile manifesto里第二项就是：Working software over comprehensive documentation。而且文档会引入新问题，比如某人出了问题后可以理直气壮地跟你讲：“spec没那么写，我当然就没那么做了”。而且按咱们的水平，设计不可能一开始就做得很好，开发过程中三番五次改spec设计的话，我估计又有人要发飙了……
btw：私以为把"需求文档"转成“feature的设计”是最难的过程...

>>就是写完自己的代码调完自己的bug，发现bug仍是一个一个的出现，而且不是自己代码原因的bug，不知道怎么修复，无从下手，干着急只能望bug兴叹……
有一种“奇巧淫技”叫做Test driven development，一种quality ensurance的开发方法，用一堆test case去限定代码的行为，如果别人写的代码有问题，那就用自动测试使其自己fail掉（在它们进入你的视线前:)）...

最重要的：人心齐、泰山移...俺就不多说了 :)
送一句邹老师曾经在MS^2培训最后阶段给所有team说的话：脚力尽时山更好，keep moving!
 

xin 邹欣 - Jan. 3, 2009 - Delete
>就是写完自己的代码调完自己的bug，发现bug仍是一个一个的出现，而且不是自己代码原因的bug，不知道怎么修复，无从下手，干着急只能望bug兴叹……

别人的代码，应该能让同组的人看懂吧。。。
移山之道里谈到了萝卜和白菜的故事，可以看看。

 

Ke Liu - Jan. 3, 2009
因为我不清楚那部分功能……比如我不了解某某协议，要去改实现某某协议的功能部分，那我就得先去好好的研究某某协议，这样就太费时了……而且按照分工，只需要负责实现那部分功能的人去研究就可以了