个人阅读作业——阅读《移山之道》

移山之道这本书还是很有意思的,读这本书也能从中学到很多东西。阅读这本书差不多用了我一个星期的时间,当然也只能理解其中一部分的内容。

我接触编程的时间并不长,是从上大学之后才开始的。但是时间也不短了。在过去的时间里,我编程的内容基本上是完成作业和考试,软件工程仅仅是在我脑海中的一个概念,在这门课中老师要求我们选择一本书来读,我便选择了这本《移山之道》。在阅读的过程中可以说是获益匪浅,同时没有了以前阅读专业书籍时的那种枯燥感。

下面我说一说在阅读过程中没有想明白的几个问题;

1.关于结对编程,目前我们也有相关的作业,所以我特别关注了一下。在结对编程的过程中,我们两个人的特点、长处都不一样,可以说是有利有弊。在编程的过程中,我们会有意见不同的地方。虽然有各种各样的指导,但是实际中要如何协调还是一个很难解决的问题。另外,在结对编程中我们应如何协调各自的任务,以何种模式进行合作才能最大化地发挥各自的作用?在磨合过程中的争执怎样处理?

2.关于bug的处理:如何判断一个bug对于整个项目的影响?如何具体权衡是否放弃处理某一bug?

3.在《移山之道》这本书中衡量员工工作质量中(DEV)中其主要衡量两个指标

(1) check in 的质量,也就是签入破坏构建的次数

(2) 功能是否按期完成,如果延期,是否提前交流

那么当两个指标相冲突是该如何权衡?考核指标过于刚性时如何处理?

4.个人认为软件工程在某种程度上意味着软件的开发朝着流水线的方向发展,那么在软件开发人员的培训过程中,是否还需要令其理解每一个环节?还是专注于自己的环节即可?

5.关于TFS的一点问题:TFS中为什么不予许Dev自己添加任务?

时间: 2024-11-06 09:57:04

个人阅读作业——阅读《移山之道》的相关文章

个人阅读作业——读移山之道想到的问题

1.像这一类书籍,怎么阅读才更有效? 来自百度: 实践表明,直接光看书效果是不大的,必须learning by doing,寓学于干,看了书的知识,只有马上通过工程实践尝试过,才有直观深刻的印象,才能发现问题和优点.所以,我觉得我们边上课边做项目的课程安排是很合理的. 2.命名规范为什么是加前缀? 在平时使用VS等编程软件时,我们都知道,打出变量的前几个字符,vs会根据这几个字符自动帮你搜索可用的变量,那么如果加了前缀,不是阻隔了这一功能吗?我每次都要先把前缀打完才能像以前一样,并不如加个后缀来

个人作业-《移山之道》读后感

读惯了教科书,这本书独特的讲述方式让我眼前一亮,很快就融入到书中去了.这本书一直用一些故事和真实的例子来激发读者对于书本内容的兴趣,适合我这样的菜鸟.我觉的这本书对软件开发的学习十分有帮助,通过这本书我还了解到了开设软件工程课的意义——我们不是为了技术或者完成任务而开发一款软件,我们是为了更好的满足客户需求和让更多的人更容易的生活.工作而开发.接下来是我的问题. 1.复审的意义是什么?那些高手写的代码是不是就可以免去复审? 人无完人,再牛的人在编写代码的时候都有可能会犯一些细小的错误,复审不是对

《移山之道》Reading Task

老师布置的阅读任务虽然是附加的作业,但是对我来说是个很好的学习机会.软件工程主要是对工程的开发进行学习,毕竟在学校老师教了那么多的知识,我们课下做了那么多的练习并没有提高我们做一个工程的能力.一个项目一个工程不仅仅是编写代码,调试,简单的测试,通过阅读<移山之道>这本书我对开发项目有了一个全面的了解. 平时对教科书那种语言方式不是很接受,这本书一直用一些故事和真实的例子来激发读者对于书本内容的兴趣,引导读者继续阅读. 因为之前接触的编程的书不是很多,有很多东西不熟悉,读了这本书以后有很多的收获

《移山之道》读书笔记

由于老师的推荐,刚刚读了<移山之道:vsts软件开发指南>,感觉作者用一个个小故事和白话的形式向我们说明了一个个在实际中软件开发可能遇到的情况, 感觉软件开发由一个比较深刻的问题忽然变得比较浅显易懂了.但是在阅读的过程中还是感觉到一些问题. 1.作者所讲的一个团队之间的工作,很大部分都是由pm来提出的,而真正去参与完成任务的人一般都局限于少数人,这样尽管由于根据工作量来决定薪资收益, 但是这样对于少数人来说事情太多了负面影响也实在太多,该如何去改变这一现状,同时提高整个团队的效率,减少队员偷工

读《移山之道——VSTS软件开发指南》

读<移山之道>这本书差不多用了一个星期的时间,感觉还是收获了一些知识的,以前只是会简单地编个小程序(虽然现在也是这样),但看过这本书之后我对软件开发这个概念的认识度有了从一片模糊到了解大体概念的转变.但是毕竟用一周时间读透这么一本完整的书不是一件简单的事情,我也只是了解到了一些皮毛,在阅读的过程中也遇到了很多问题,一些基本的问题在后面的学习中已经解决了,有的还在困扰着我. (1)在书中了解到了一个术语叫 Work Item,但书里并没有提到一个vs里出现过的叫做issue的Work Item,

《移山之道》——读后感

<移山之道>并没有来得及看完,大概只看了半多本吧,下面是我边看边提出的一些问题……(总体感觉看这本书还是有点吃力的,明显感觉是我的能力以及开发经验还不够,所以对于此书,我着重看的还是书中的关于软件开发的思想原则.解决方案以及方法论方面) 我看到的是第二版,下面的页数均是第二版书中的页数. Q1:(这个问题与VSTS无关)P39,文中在强调“重视商业价值”的时候,引用了罗大佑的一首歌<错误>中的歌词,词是诗人郑愁予所作—— 我嗒嗒的马蹄 是个美丽的错误 我不是归人 是个过客 …… 文

《移山之道——VSTS软件开发指南》读后随笔

前几天应老师课设要求,选取了课程推荐参考书<移山之道>并读了一部分,使我发现了我目前正在进行的工作中的诸多不足. 首先这并不是一个风格非常严肃的书,作者的叙述性比较强,并且能够自问自答,就已经解决了我不少疑惑. 但是同时,我也从自身出发发现了一些问题: 1.在团队项目中,工作量如何分配?如果对于一个足够成熟的团队,可以假定每个人都是可以信赖的,那么这个时候就可以将工作量接近平均地分配,保证每一个人的利益,但是在我们目前这种不成熟至只做一次项目的团队中,首先工作量的分配问题就已经很难找到平衡点.

读《移山之道-VSTS软件开发指南》

首先,我选择<移山之道>有几个原因.第一,书的名字给我一种新鲜感,而不是像另外两本书那么平常:第二,作者邹欣是老师推荐的,看一看他的书或许能让我发现老师对他推崇备至的原因,而实际上,读完这本书,我也深刻感觉到自己学到了很多东西:第三,这本书的写作风格和我们平时用的教材有很大差异,以一个故事的形式娓娓道来,让人耳目一新.就是这些原因,我选择了这本书,我也发现了一些问题,这些问题也许在我们以后的学习工作过程中都会遇到. 第一个:书中衡量员工工作质量中(DEV)中其主要衡量两个指标,一是check

《移山之道》读后感想

问题如下: 一.怎样通过一个有效的方法确定一个bug的重要程度? 二.我们知道,修改一个bug时别的bug有可能会产生相应的改变,也就是说如果出现了一些bug,应该先修改哪些bug会比较有效率? 三.出现bug时怎么调整他们的优先级? 四.我们一直在谈创新,假如我在一个自己创业的团队中,需要并不是很清楚,平时别人也很少的做过类似的项目,那么我们应该怎么去完善需求,怎样很好的规划处具体的进度 以及重要的时间及地点? 五.移山之道的“道”来源于何处?