+ -
当前位置:首页 → 问答吧 → 看代码之道的两章后来聊几句

看代码之道的两章后来聊几句

时间:2008-12-08

来源:互联网

代码之道的两章看后来聊几句
关注这本书算是比较长时间了,但是迟迟动不了笔。光看书名以为是一本技术类的书籍,但是看了两章节后发现讲的内容更偏向与项目发过中的各个细节,可以这么说对于任何一下程序员来说都是希望有点能当上个项目主管的,其实我也这么想的只是身不逢时啊!

我自己也主持过项目的开发,遇到的最大问题都是沟通问题。对于我这种草根程序员没有主持过什么大的项目,但深知在开发过程中团队的沟通是多么的重要。

在现实的开发中正如作者在书中所说的那样没有项目书或是拖到项目到快开发玩了才出项目书,这都是很常见的事了,更可气的问题是有很多时候顾客种是三天两头的改变需求,这主要也不能怪顾客主要是在项目开发前期没有沟通好。

对于作者讲的两种会议形式很不错,其实我认为说会议不如说交流,很多时间在吃饭时在看电影的时候!交流一下各自的问题,谈谈以后的工作安排都是比较不错的选择。

前段时间自己算是半个主持开发一个项目,中间开发一半流产了,老板中途让作别的项目,作好以后又接着开发先前的项目。在开发的一半又从开发团队中把美工拖去作另的项目,让我是气到要吐血,最后还是决定放弃了,其实这个项目拖的时候比较长,中途也干了不少别的项目。但一个领导的决定直接就会影晌到整个团队的开发心态。一个健康的开发团队能给企业带来效益,有一个好心态的团队能为企业带来更为直观的效益,所以在开发中希望是当老板的领导看后一定要记住。

对于BUG的修改问题是最令人头痛的问题了,至少我是这么认为的。在开发中发现的问题马上就修复了。最当人当心的是那些没有被发现的问题,或是说找不出问题。

在看完书后,许多时候总让我想起作者说的那句话:“要么听我的要么走人”。这话在一个企业里常听老总这么对那些表现不好的员工这么说,那时候我总是很不理解,有什么这么牛的。但是看了作者说的原来是这么回事,在一个项目中只能有一个头不然就会让你的项目一败涂地。

对于本书的许多东西还在学习当中,对于作者写的内容我不敢乱加评论只能写点自己的感想吧!等学习了第八节的后面部分在把感受共享出来。

作者: gvtbs   发布时间: 2008-12-08

留个位置

作者: gvtbs   发布时间: 2008-12-08

╮(╯_╰)╭没有沙发做

作者: mouxie   发布时间: 2009-01-26

顶一下

作者: gjwzjl   发布时间: 2009-03-01

热门下载

更多