移山之道读后感想(阅读作业之王冬篇)
2012-10-31 21:27
183 查看
看完了老师的《移山之道》,发现跟自己的预期有很大的区别,下面就谈谈我看完这本书的感想以及一些收获。
总体来说,移山之道并不是一本单纯的介绍VSTS或者技术方面的书,而是一本有关方法论甚至有一些哲学意味的书。
邹老师以情景剧的方式组织书的方式很新颖,很能吸引着人看下去,这是本书的一个很大的特点,也是优点。
另一个令我印象深刻的地方是书中的一些失败开发的例子,比如典型的学生团队的开发流程,简直就是真实情况的写照。
我觉的这本书对软件开发的学习十分有帮助,通过这本书我还了解到了开设软件工程课的意义——我们不是为了技术或
者完成任务而开发一款软件,我们是为了更好的满足客户需求和让更多的人更容易的生活、工作而开发。当然,
开发的过程中要有良好的沟通,共同的愿景才行。这也是这本书试图教会我们的软件开发经验。
还有一个让我印象深刻的地方是软件测试。我们以前写的小程序基本都是没有经过什么测试的,就是找一些最基本的
数据<或者直接是老师给的数据>进行测试,根本就经不起推敲。在《移山之道》中看到了测试数据应该遵守的原则,
感觉测试真是一个十分重要的环节。至于这一点,我还有一些别的感受:win8,我尝试安装使用了win8的DP,CP,RP,
RTM版本,如果没有这些测试改进,win8的体验真的是十分的糟糕的。像DP和CP版,Modern<Metro>应用很容易崩溃,而且
传统应用也是经常的崩溃,甚至资源管理器都定期的No response。但是到Rp就有很大的改观了,RTM就基本没有这些现象出现
了。我想这就是测试的重要作用吧。没有完整的各种测试,发布出的产品就很难得到认可。
看完这本书我有以下几条问题要提: 1、我们一直在谈创新,假如我在一个自己创业的团队中,需求并不是很清楚,同时别人也很少的做过类似的项目,
那么我应该怎样去完善需求,怎样很好的规划出具体的进度以及重要的时间节点?
2、怎样通过一个有效的办法确定一个Bug的重要程度?我们知道,修改一个Bug时别的Bug处有可能会产生相应的改变,
修改了某个Bug可能有的Bug的出错原因就发生了改变,也就是说,如果出现了一些Bug,应该先修改那些Bug会比较
有效率?怎样调整他们的优先级?
我自己尝试给出了问题1的答案:
尽量缩短需求分析的时间,尽量完成基本核心功能,然后尽量拉长软件测试的战线,多测试,少加功能。这样可以赢得一些
比较看重核心用处的高粘性用户,只要有一些忠诚的用户,做出来的产品就挺成功的。
另:本来想去yishan.cc看一下别分享的心得的,结果发现了这样:
![](http://pic002.cnblogs.com/images/2012/449893/2012103120411316.png)
貌似这个站点没有维护过啊,不过我看了一下是基于Wordpress搭建的,在中国也直接访问不到。
总体来说,移山之道并不是一本单纯的介绍VSTS或者技术方面的书,而是一本有关方法论甚至有一些哲学意味的书。
邹老师以情景剧的方式组织书的方式很新颖,很能吸引着人看下去,这是本书的一个很大的特点,也是优点。
另一个令我印象深刻的地方是书中的一些失败开发的例子,比如典型的学生团队的开发流程,简直就是真实情况的写照。
我觉的这本书对软件开发的学习十分有帮助,通过这本书我还了解到了开设软件工程课的意义——我们不是为了技术或
者完成任务而开发一款软件,我们是为了更好的满足客户需求和让更多的人更容易的生活、工作而开发。当然,
开发的过程中要有良好的沟通,共同的愿景才行。这也是这本书试图教会我们的软件开发经验。
还有一个让我印象深刻的地方是软件测试。我们以前写的小程序基本都是没有经过什么测试的,就是找一些最基本的
数据<或者直接是老师给的数据>进行测试,根本就经不起推敲。在《移山之道》中看到了测试数据应该遵守的原则,
感觉测试真是一个十分重要的环节。至于这一点,我还有一些别的感受:win8,我尝试安装使用了win8的DP,CP,RP,
RTM版本,如果没有这些测试改进,win8的体验真的是十分的糟糕的。像DP和CP版,Modern<Metro>应用很容易崩溃,而且
传统应用也是经常的崩溃,甚至资源管理器都定期的No response。但是到Rp就有很大的改观了,RTM就基本没有这些现象出现
了。我想这就是测试的重要作用吧。没有完整的各种测试,发布出的产品就很难得到认可。
看完这本书我有以下几条问题要提: 1、我们一直在谈创新,假如我在一个自己创业的团队中,需求并不是很清楚,同时别人也很少的做过类似的项目,
那么我应该怎样去完善需求,怎样很好的规划出具体的进度以及重要的时间节点?
2、怎样通过一个有效的办法确定一个Bug的重要程度?我们知道,修改一个Bug时别的Bug处有可能会产生相应的改变,
修改了某个Bug可能有的Bug的出错原因就发生了改变,也就是说,如果出现了一些Bug,应该先修改那些Bug会比较
有效率?怎样调整他们的优先级?
我自己尝试给出了问题1的答案:
尽量缩短需求分析的时间,尽量完成基本核心功能,然后尽量拉长软件测试的战线,多测试,少加功能。这样可以赢得一些
比较看重核心用处的高粘性用户,只要有一些忠诚的用户,做出来的产品就挺成功的。
另:本来想去yishan.cc看一下别分享的心得的,结果发现了这样:
![](http://pic002.cnblogs.com/images/2012/449893/2012103120411316.png)
貌似这个站点没有维护过啊,不过我看了一下是基于Wordpress搭建的,在中国也直接访问不到。
相关文章推荐
- 个人阅读作业——读移山之道想到的问题
- 个人作业博客——阅读《移山之道》想到的五个问题By Zhe Song
- 阅读作业1----读《移山之道》疑问与感想
- 阅读作业1_读《移山之道》
- 个人作业-《移山之道》读后感
- 《移山之道》读书笔记(阅读作业之李嘉良篇)
- 移山之道读后感谢(阅读作业之王泓洋篇)
- 读《移山之道》的收获与疑问(阅读作业之刘明篇)
- 阅读作业第一弹——移山之道
- 阅读作业第一弹——移山之道 by 吴煜
- 阅读作业总结——《移山之道》
- 个人阅读作业——阅读《移山之道》
- 个人阅读作业2—《No Silver Bullet: Essence and Accidents of Software Engineering》读后感
- 读移山之道确实有收获(阅读作业之王熹篇)
- 个人作业--课本最后一章及博客读后感
- 个人读后感作业
- 软件工程15个人阅读作业1
- 软件工程网络15个人阅读作业1(201521123027 陈龙)
- 软件工程网络15个人阅读作业1
- 第1次作业:阅读优秀博文谈感想