东莞网站建设排名公司,wordpress ping,群晖wordpress端口,网站的上传与发布from:
http://teamkingofcsharp.spaces.live.com/blog/cns!59FC2D3DD66822AA!222.entry
感想平常心 初中的数学老师常常和我说#xff1a;“你要学会保持一颗平常心”。我是一个不那么豁达开朗的人#xff0c;对很多事情都会很看重#xff0c;GPA#xff0c;排名#x…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 itComments (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 因为我不清楚那部分功能……比如我不了解某某协议要去改实现某某协议的功能部分那我就得先去好好的研究某某协议这样就太费时了……而且按照分工只需要负责实现那部分功能的人去研究就可以了
