本人上传文档来源于互联网如囿侵权，烦请私信告之本人会立刻删除！

华中师范大学网络教育学院

《教育统计与测量》课程练习题库及答案 本科

1.教育统计:是运用数理统计的原理和方法研究教育现象数量表现和数理关系的科学

2.变量:是指可以萣量并能取不同数值的事物的特征。

3. 算术平均数:所有观察值的总和除以总频数后所得之商

4.频率:就是随机事件A 在n 次试验中出现了m （m ≤n ）次,則m 与n 的比值就是频率,用公式表示就是

W(A)= 5.测验设计:是指测验编制者对测验形式、时限、题量、题目编排、测验指导手册等进行的设计工

6. 测验效喥:就是测验实际上测到它打算要测的东西的程度。

7.描述统计:是研究如何将收集到的统计数据用统计图表或者概括性统计量数反映其数量表现和数理关系的统计方法。

8.名称变量:又称类别变量是指其数值只用于区分事物的不同类别，不表示事物大小关系的一种变量顺序变量又称等级变量，是指其数值用于排列不同事物的等级顺序的变量

9. 离散变量:又称间断变量，是指在一定区间内不能连续不断地取值的变量

10.总体:是根据统计任务确定的同一类事物的全体。

11.教育测量学：就是根据一定的法则用数字对教育效果或过程加以确定教育测量学是鉯现代教育学、心理学和统计学作为基础，运用各种测试方法和技术手段对教育现状、教育效果、学业成就及其能力、品格、学术能力傾向等方面进行科学测定的一门分支学科。

12. 自由应答式试题;是指被试可以自由地应答只要在题目限制的范围内，可在深度、广度组织方式等方面享有很大自由地答题方式。

13.随机变量:是指表示随机现象各种结果的变量

14. 连续型变量:是指在其所取的任何两值之间可以作无限哋分割，即能连续不断地获取数值的变量

15.度量数据:是指用一定的工具或按一定的标准测量得到的数据。

16. 正相关:两个变量变化方向一致的楿关

17. 同质性χ2检验：在双向表的χ2检验中，如果是判断几次重复实验的结果是否相同叫做同质性χ2检验。

18. 难度：就是被试完成项目作答任务时所遇到的困难程度

19. 比率变量：等距变量又称间隔变量，是指其数值可以用于表明事物距离差异大小的变量比率变量是指数值鈈仅能反映数字之间的间隔大小。还能说明数字之间比率关系的变量

20. 样本：总体是根据统计任务确定的同一类事物的全体。个体是构成總体的每个基本单位样本是从总体中抽取的作为观察对象的一部分个体。

21.频率：就是随机事件A 在n 次试验中出现了m （m ≤n ）次则m 与n 的比值僦是频率，用公式表示就是W(A)= 概率又称“机率”或“然率”，表示随机事件发生可能性大小的量

22. 负相关：两个变量变化方向相反的相关。

23. 独立性χ2检验：在双向表的χ2检验中如果要判断两种分类特征之间是否有依从关系，叫做独立性χ2检验

24.情境测验法：指的是把被试置于一种特定情境中以观察其行为反应，然后对其人格特征作出评鉴的一种方法

25.推断统计：是研究如何利用部分统计数据所反映的数量特征，在一定可靠程度上推测和判断未知的全体统计对象数理表现和数理关系的统计方法

26.等距变量：又称间隔变量，是指其数值可以用於表明事物距离差异大小的变量比率变量是指数值不仅能反映数字之间的间隔大小。还能说明数字之间比率关系的变量

27.随机误差是指甴于某些事先难以控制的偶然因素造成的误差。

28. 双向表：按两种分类标志编制成的表就是双向表

29.心理测验：是通过对一组标准刺激所引起的行为样组的客观分析，对人们的心理特征及个别差异进行估测描述和诊断的一种方法。

FAQ陆續迁移到 CSDN社区中，请访问：

欢迎大家通过PR的方式或者在本博客下留言的方式随时补充意见和建议我们会持续更新

1. 书中的书, 边开发asp.net的项目，这相当于一边看医学书一边动手术”在我看来这个是初期项目开发者都会遇到的问题，其实在一定程度上确实影响了自身的开发效率那面对这样的情况应该要怎么处理呢？

2. 在第五章的团队不同的投入中作者提到团队中有一类人为鹦鹉：“他们有漂亮的羽毛,能说会道，联系广泛能提出很多建议，很多点子但是他们不执行,除了一些人云亦云的观点和一些关于架构的空谈之外他们没有其他投入，一旦項目失败, 他们就会飞到另一个项目中去”这种类型在团队其实是很影响队员效率的，那应不应该适当的提醒她呢或者应该怎么处理这樣的情况呢？
3. 在第九章创新方面作者提到了两种如何在一个创新性的市场上后来居上的观点分别是“改变游戏规则”和“转换目标用户”。其实我认为“居上”最多也就是几乎齐头并进但是还是无法超越之前的产品，这样的想法是否正确呢对于这个观点，我觉得最好嘚例子就是拼多多的崛起在淘宝已经占据了绝大部分市场份额的时候，拼多多以一个“砍一刀”的规则重新进入了大众的视野同时商品定位比较亲民，他利用了大众心理制定的政策果不其然，确实很成功同时，在后续的使用过程中我们也先后发现了其他app也出现过类姒的板块这其实就正好契合作者所提到的这两个创新的办法，但是在市场上看淘宝还是大部分用户的第一选择因为前者可以向新的创意学习，可能两者的起点就是不同但是不可否定的是拼多多的创新确实做的很成功。
4. 在第七章设计阶段分析中作者提到对于需求分析不應该条条框框的完成需求内的要求但是也不可以一味追求“最大的扩展性”。所以在需求分析和设计的时候我们应该保留什么样的弹性呢
5. 在七章开发阶段的日常管理中作者提到“要尽量减少非开发时间，不要动不动就开“全体会议”团队成员们自我时间管理也很重要。”这个全体会议其实是很经典的问题感觉其实当团队积极参与度不高的时候，全体会议就显得很没有效率但是有时候又是必要的需偠告知大家，或者希望大家参与讨论应该怎么处理呢？
6. 事后诸葛亮会议是对整个项目的回顾总结经验教训，但是一些公司里人员流动夶去去留留一个项目能换几茬人，那么事后诸葛亮会议还有意义吗会不会变成甩锅大会呢？
7. 结对编程的好处书中已经详细描述了那結对编程的不足之处呢？结对编程在现实生活中国内的公司似乎很少采用是有什么局限吗？
8. 典型用户是指按不同维度来区分用户的过程中，在每个维度中能代表目标用户的那类群体比如，按人数多少来划分的能代表最多用户特征的群体；按盈利来划分，能代表带来朂多盈利价值特征的群体但是典型用户的定义和删除让我觉得非常奇怪，典型用户在何种情况下需要进行删除呢
9. 第三章提到过早扩大囮/泛化会使整个软件变得四不像最后只能让后人来完善，怎样才能避免陷入这种误区又应该在什么阶段对软件进行扩大化/泛化，使得程序更加完善
10. 第四章提到结对编程使用同一机器一同完成工作，那么应该如何根据各自的特长分配两个人的任务范围以取得更高的投入产絀比
11. 第五章中提到为解决瀑布模型的问题提出了生鱼片模型和大瀑布带着小瀑布模型，分别有什么优缺点这两种模型分别适应与哪种開发场景？
12. 第九章介绍的PM对团队起着重要作用但应该如何处理好与团队成员的关系，了解成员的状态合理分配工作来提高项目的完成效率何工作质量？
13. 面对庞大而又零碎的需求是如何从中化繁为简，捋顺思路将各个需求串起来已进行功能的实现的呢？
14. 那么作为团队Φ的一员如何快速的找到自己的定位，完成自己可以胜任的任务呢并且作为初入职场的新手程序员，如何让正确而又全面的向领导展現自己能力呢
15. 假如作为一个个人开发者，考虑的测试情况总是有限的有什么办法可以帮助我们拓宽自己对软件可用性测试的思维呢？
16. 囿着各自的见解无法迅速的达到统一，所以请问在这种情况下到底应该如何达成一样的意见团队又应该如何去沟通交流思想呢？
17. 我有個疑问例如现在的某手机支付软件，为了利润投加了很多影响用户观感的广告经常在使用的时候会无奈地误触到，作为用户我感觉软件的使用不够清爽而反观某b视频软件，在广告以及一些不影响软件主要播放功能的小功能方面安排的很好请问作为程序员在接受了用戶这样的体验反馈后会做出如何的调整呢，如何在软件收益和软件使用体验之间做出均衡呢

《构建之法》3.2 软件工程师的思维误区
“不分主次，想解决所有依赖问题：想马上动手解决所有主要问题和次要问题而不是根据现有条件找到一个足够好的方案”

疑问&思考?：
我們在编写代码的时候确实会遇到一个问题，但是因为代码都是有相关联性的所以往往会牵扯出一链子的问题。那么这时候难道不是顺着這条思路去改代码吗什么叫做根据现有条件找到一个足够好的方法呢？
就还是以作者举的小飞的例子小飞本来要去自习，发现自行车沒气去借打气筒借打气筒要送围巾，就开始织围巾确实这个结果偏离了最开始的计划，或许最开始小飞发现自行车没气决定走路去自習是不是作者认为的足够好的方法呢
那么我的问题和思考归结于是不是要评估这个问题所依赖的一链子问题是不是过于复杂？对于不复雜的例子就可以马上动手顺着思路去解决对于复杂的问题就先放着，看看有没有更快捷的方法

1. 阅读《构建之法》第一次知道结对编程，感觉结对编程这种形式对我来很新颖两个人一起写一个代码工作量直接减少一半欸:)，但我觉得也有些局限首先结对的两个人水平相差怎么样，一个人很牛一个人相对的菜会不会导致牛人写的时候，另一个人看的时候觉得“哇牛，这个好写的好快，性能也好...”等到这个人写的时候，厉害的人在旁边看的觉得这不行这不对开始指导最后恨不得自己把键盘鼠标抢过来。那么对于结对编程的人是不昰要有一个基本的水平要求
2. 通过对第九章的阅读了解了PM，同时知道PM需要的能力很多我在网络上收集了一下PM需要的基本技能：
   1.研发/测试 2.運营3.设计4.市场5.职能部门6.其他技能比如word、excel、ppt等基础技能还要有思维、管理、沟通能力7.产品，熟悉高效的产品工具：Auxre、墨刀、Xmind、ProcessON7.多关注各网站囷APP多看行业报告和商业计划书，多看别人的产品
   那么PM是由程序员逐渐去往PM培养成长起来的呢还是一开始的职业目标就向PM方向发展？比洳软件工程的大学生发现对于写代码开发不怎么感冒能不能就轻于写代码开发，而尽早去点亮作为PM的技能树呢
3. 书中认为测试人员测试嘚软件功能100%符合要求，测试人员也都按照SPEC去测试但是如果用户恨你的软件，那么就说明是测试人员的责任我想请问的是这里是不是把測试人员的责任看的太大，首先我认同作者的好的测试人员要做易用性测试去站在用户的角度考虑，但是我也考虑到用户在运用软件发現有问题或者不好的地方是不是说明这个软件的需求分析之类的做的不够好，而不是去指责测试的不到位像易用性测试这样的更像是┅个附加的测试条件，有点像之前提到的Ad hoc Test比如之前的微信，我们很经常会用微信打开别人分享的链接之后在链接里看到另一篇文章也鈈错，再打开看看然后就在微信里面开始循环的浏览信息。这个时候突然有一条微信进来我要去看看。结果回复完信息之后找不到之湔循环浏览的网页了这是我之前使用微信的一个痛点，但是惊喜的是后来微信增加了一个float window的功能就解决了这个问题。请问这样的是测試的责任吗
4. 单元测试应该是可重复的，用随机数去单元测试不好又提到也要用随机数出去增加测试真实性，但不是在单元测试中那請问是在什么时候用随机数去测试呢？在这个部分我也有上网搜索但是结果都是程序中含有随机数生成器怎么进行单元测试，并没有对於什么时候可以使用随机数去测试的解答
5. 一个软件如果仅仅用于一时演示而没有投入全面应用。甚至在演示之后基本就不会再继续使用叻那么这些程序在开发的过程中还有必要严格按照常规的开发流程吗？
6. 简单说明故事是否会缺少用户体验的细节然而如果要让故事说奣得完整又细节，是否会将故事写的缺少简明性那么要如何把握故事的细节？在之前设计用例时我使用UML图形来分析的次数比较多，而攵字内容较少故事有哪些图形不具备的优势吗？
7. 只把最重要的功能醒目地展示出来的确可以让产品看起来一目了然，用户上手的难度吔降低了我的疑问是那些介于无关紧要和最重要之间的，没那么重要的功能应该放在哪里比较合适呢

“在产品达到引爆点之前，不宜過早考虑变现同时，不宜受产品现有变现模式的束缚而要把重点放在用户满意度和用户增长率上。”

看了这句话之后我对其中提到嘚“引爆点”概念的定义并不清楚。我在维基百科中查阅到关于引爆点（Tipping Point）的定义：“系统发展到一定程度会产生飞跃性的变化，但转捩点更隐含意思于一系列大型事件、大型系统的发展这种改变在表面或外在方面来看可能明显也不一定很明显。”查阅百科后我对“引爆点”的概念还是有些模糊一个产品在什么时候到达引爆点，又可以通过哪些指标判断呢

“在用户中招募粉丝，让粉丝有参与感并整匼到市场推广中在这一阶段要首先培养用户的忠诚度，然后再考虑品牌的知名度”

我也十分赞同这个观点，我认为先着手用户的忠诚喥可以通过粉丝的用户体验来完善产品此外粉丝用户也能在产品发布之初缺少宣传的时候对各自的亲友宣传推荐，在产品有不足的时候忣时反馈可是在软件开发之初就可以确定自己潜在的忠实用户吗，实际市场中有什么策略可以有效地招募粉丝、培养忠实用户并提高用戶忠诚度呢

1. 如何终止“分析麻痹”？

P52 3.2 分析麻痹:一种极端情况是想弄清楚所有细节、所有依赖关系之后再动手心理上过于悲观,不想修复問题，出了问题都赖在相关问题上分析太多，腿都麻了没法起步前进，故得名“分析麻痹"( Analysis Paralysis )

当出现一个问题的时候，我们当然会去分析导致这个问题出现的原因而这个问题的出现也确实是存在着其他依赖问题，比如书中举的例子：木桶出现了洞需要粗绳堵但是粗绳呔长需要刀砍断······但是这些也都是真实存在，需要解决的问题我的疑惑是，我们在分析问题的时候需要分析到哪一种程度停下来實施才能避免“分析麻痹”？

1. 软件工程师的职业生涯真的就会终止在35岁吗

P55 3.3 软件工程师的职业发展 2. 工作（Job） 这些人经常会问“软件开发莋到35岁以后怎么办”这样的问题。很多中国IT人士认为这个年龄是程序员的职业终点

这个问题也是现在非常困扰我的一个职业规划方面的問题。在我上网查找的相关言论中非常多的人都认为35岁就是一个程序员的终结，原因有很多比如身体原因、脑力的退化以及有能力的噺人的涌现等等。我的疑惑是软件工程师的职业生涯真的就会终止在35岁吗？我们应该如何规划35岁以后的职业生涯

1. 用户体验和质量要怎麼去权衡？

P269 12.1.6 用户体验和质量 好的用户体验当然是所有人都想要的如果它和产品的质量有冲突，怎么办?牺牲质量去追求用户体验么,用户能接受么?

现在很多的软件都拥有数量相当多的用户用户数量一多就会有各种各样的用户体验，有的人会觉得好而有的人觉得不好，这样偠怎么去定义“用户体验”呢况且我认为质量不也是影响用户体验的一个因素吗？那么在这种情况下，牺牲质量去追求用户的体验導致了一部分用户觉得好，又有一部分觉得不好那这样的改动还有必要吗？

1. 怎么决定一个团队中各人负责那一功能当一个团队接手一個项目时，是让每个人选择自己感兴趣的部分去实现还是根据每个人的特点去分配更好？怎样去平衡这样的分工呢

2. 便宜、好、快这三個愿望只能满足两个，怎么办又好又便宜的需要花时间等，又好又快的需要钱又快又便宜的比较难用。如果让我来抉择的话我首先會排除又快又便宜的，因为又快又便宜这个条件虽然看起来很诱人但是做出来的东西难用，难用的东西会有人用吗我的疑惑是，我们應该怎么在这三个愿望之间做出较好的权衡

3. ??我的问题是：教材中给的解释是说在这些科学巨人顿悟之前已经有坚实的基础了，但是頓悟和这些知识具体的联系是什么呢
   ??事例资料：我试图去查了对于牛顿这个故事，也看了有的资料去讲顿悟、渐悟的关系
   ??但昰我还是不太懂，我的想法大概是牛顿这样的一个思想的来源是不是由于他本身有对力的知识，就是知道世界上有力的存在力能改变粅体的状态，能让物体“动起来”之类的知识现在发现没人动苹果，苹果却能动说明也有一个力在牵引着它，作用于它但我感觉这樣的过程好像更像一种延申，它真的是顿悟吗还是说所谓的“顿悟”其实就是这样延申出一个新的东西呢？

4. ??我的问题是：我感觉创噺面临的更多问题是在于不够创新没有吸引力，而不是这些问题如果是真的非常建设性的东西，是不是不太会受到这些问题呢
   ??倳例资料：不知道该往哪个方向找资料，搜索相关关键词基本只能看到非常笼统地说“我们要创新”“创新才有未来”之类的话于实验室，利用先进的技术和设备在实验室中还原
   ??我的困惑是：好像现在更多的创新都非常容易和过去的相撞或者和别人的想法很类似那洳果真的很有意义的创新的想法是不是会获得更多人的支持呢？在编辑这段文字的时候我又想到是不是这个“创新者”除了创新的想法之外还需要其他大量的工作去证明这个创新是有意义的，那这样究竟是一件好事还是坏事呢

5. ??我的问题是：如果一类产物是具有别样意义的东西，那么这样的产业化真的会动摇原产业吗
   ??事例资料：钻石类比于水晶。现在市面上已经有大量的人造水晶像著名品牌施华洛世奇作为轻奢的一员使用的就是人造水晶。目前为止出现在市面的有培育钻石钻石的化学成分是碳，这在宝石中是唯一由单一元素组成的属等轴晶系。常含有0.05%-0.2%的杂质元素其中最重要的是N和B，他们的存在关系到钻石的类型和性质晶体形态多呈八面体、菱形十二媔体、四面体及它们的聚形。
   ??问题：那钻石是不是也和水晶一样会包含不一样的矿物质，世界上没有两颗一模一样的钻石那么人慥和天然的意义是不是还是有区别。像水晶在人造水晶越来越漂亮高阶的今天，天然水晶的市场中依旧有很多人趋之若鹜珠宝市场的規则是不是是和批发市场有所不同呢？这样的创新是不是并不会影响这类的市场或者影响不大呢

6. ??我的问题是：这样的一个决断，是徝得参考的还是只是当一个故事看看呢
   ??事例：像京东当年想要转战线上，关掉了在北京的12家实体店如今看来当然是个正确的决算，但如果这一条路错了呢
   ??问题：卖掉所有的生产线，看上去是一个非常伟大而漂亮的决断让后来的诺基亚坐到了行业头部的为止。但是如果这一战失败是不是直接死亡所以这一部分的内容是要希望我们能坚持决断地做一件事是这个意思吗？还是一定要能选择到正確的方向

7. ??我的问题是：这个举了两个选择，一个是利润50%一个是利润10%，那如果创新的产品没有利润甚至一开始就倒贴，后面有可能有更高的利润人又会去怎么选呢？

8. ??我的问题是：目前为止看到“价值观坚定”而成功的栗子好像基本都是坚定站在用户的角度上栲虑问题的那有没有其他价值观成功的呢？
   ??事例资料：例如为什么微信不能多任务同步操作？——就是说你看微信文章的时候来叻一条消息就必须要退出文章界面，很多人会觉得非常没有效率而这个就是微信的产品经理在向用户传达一个小小的价值观：生活已經这么累了，那就专心做好一件事吧
   ??但是我还是不太懂，我的困惑是：这好像是这个软件本身成功了这个事才无所谓就像我同样吐槽微信为什么不能三个平台同时登陆，平板一上线电脑就会掉线那如果这个软件改掉会不会更贴合用户，更受欢迎呢

9. ??我的问题昰：现在真的效能过剩了吗？有的效能是不是必要的呢
   ??事例资料：比如现在的手机的性能越来越好，按一些人的形容是已经超过了佷多人的需求比如很多父母辈的要求就只是要能顺利发消息，发文章新闻发消息之类，现在的手机的性能很多是针对有重度游戏需要嘚人
   ??但是好像实际上会发现这些多余的性能是有用的。除了跟内存空间相关之外更强的性能是不是在使用时间较久之后仍不滞后，仍能使用户有与开始一样好的使用体验呢现在的手机都在不断地提升刷新率，不也是为了用户体验的提升吗很多肉眼不可见的地方，所谓“多余的性能”或许并不多余呢？

10. ??我的问题是：假如真的有这样的梦想这真的应该是我们要考虑的事吗？
    ??事例资料：認为作坊式开发的集中体现是有组织的管理难以落地有以下几个主要问题：
    ????（一）对“师傅”的依赖严重
    师傅就是骨干工程师，很多东西都是装在开发人员的脑子里面的往往会因为一两个开发骨干走了，就造成整个团队的瘫痪如果研发骨干一个人另谋高就，公司投资就将全部付之流水我们看到很多团队里的“技术权威”使得老板也不敢对其“指手画脚”，否则他会“撂挑子”事情成败取決于师傅的能力，实际上说明工作缺乏组织的有效管理在这样的情形下，生产过程基本上是无序的、无约束的老板作为“管理者”角銫的职能几乎谈不到，甚至受师傅的摆布除非老板是一个非常高水平的技术大牛。
    ????（二）老板对软件开发的过程无法介入各層级之间也是以人为纽带的弱管理
    老板大概知道要开发个什么东西，需要什么时候交付但具体开发过程、产品工期、产品质量老板只能問技术总监，有趣的是技术总监也是个大概齐更多的只能问项目的负责人，虽然越接近开发工程师越了解实际情况，但项目负责人甚臸都不知道手下的工程师今天倒底是写代码了还是打游戏了这种粗放的管理水平在今天的其他行业是很难想像的。
    ????（三）无文檔式开发设计都在师傅的大脑里，开发项目可持续的风险很大
    ??问题：那是不是其实除了文中提到的自身的很多条件和想法之外作坊本身也是非常非常重要的呢？而在外部的人根本无法窥得内部的真实情况应不应该冒这样的风险呢？其二现在的年轻人比起梦想，其实更多需要的是能够生活下去有稳定的工作和工资，是不是不应该去试错呢

11. 一部分人写代码时充满激情，也有一部分为了工作而勉強了事那造成这种差异的所谓“激情”是如何产生，它来自于项目的商业价值还是个人的理想实现又或者是什么第二类人又该如何激發自己的激情呢？

12. 今天碰到的问题来自于昨天的风险一个项目存在着许多的风险，其中来着环境的风险有法规、市场竞争环境、经济情況、技术大趋势等等那么我们程序工程师在项目确定的时候考虑风险是参考当下的环境，还是凭借个人的眼光以及周遭信息更多地参考所预测的未来的环境呢

13. 用户体验的好坏与产品的成功息息相关，我想可以理解为用户体验至上但是有些时候我们不得不牺牲一部分用戶体验以换取性能、安全性等等，这种时候我们怎么进行取舍呢

14. 假设我们砍掉了一个无法实现预期的设计需求，我们为这个功能所花费嘚成本可以称之为“沉没成本”那我们能不能从这个已经花费出去的“沉没成本”上吸取到什么教训。

15. 结对编程中两人进行角色互换，阅读对方的代码、理解对方思路时是否会浪费大量时间

16. 读了56~57页“专和精的关系”，我想问的是究竟该往哪个方向发展：是成为一个什麼都会一点的全栈工程师还是成为只精通某一种语言的工程师？哪个方面会更吃香
    我自己是觉得可以成为精通一门语言的工程师比较恏，把这门语言学到深真正去理解这门语言，使用的时候就会得心应手当然，这不意味着不要去学习其他语言、技术只是不需要学嘚那么深入，会基本语法能够使用就行，自身是需要精通一门语言的才有底气。

17. 读了74页的注释规范这里说“应该只用ASCILL码，不能用中攵字符”我有点不大理解
    我的观点是认为注释的作用就是为了让其他程序员，甚至是自己看得懂代码写的是什么功能是易读的。如果茬欧美国家用ASCII码当然没问题。但是在我们自己看来英文注释反而大大阻碍了其可读性，我遇到英文注释可能还需要借助翻译工具，這样就浪费了我的时间而且写中文注释可以同英文代码更好的区分开来，哪个是注释哪个是代码。

18. 读了84~85页我认识到结对编程的必要の处，那我想问如何进行有效的结对编程若是其中一个人能力不足，或者总在偷懒又因为项目要到时间了，另一个人只能被迫完成大蔀分内容这样的结对编程反而无法带来好处，那么如何避免这种情况的出现呢
    我自己的能想到的解决方法是，找个能力相近的有责任惢的人一起结对编程不知道还有没有更好的解决方法？

19. 敏捷开发的一个原则是“可用的软件是衡量项目进展的主要指标”我想问的是“可用的软件”的具体含义指的是什么？指的是仅实现功能需求的软件但是仍存在一些bug，还是指的是无bug的软件如何判断一个软件是可鼡的？有没有什么具体的标准

20. 读到第八章收集用户需求时，我有一个问题：软件开发时是满足大部分人所需要的需求还是尽量满足所囿用户各式各样的需求，即对小众用户的需求是否要满足比如手机的旁白模式，这个对大多数人是用不到的但市面上基本所有的手机嘟实现了这个功能，因为他对一些人来说这是非常必要的

21. 从事软件行业的人肯定是避免不了团队合作以及结对编程的。那么《构建之法》也在P108提到性格一定程度上会影响合作据MBTI分析，ISTJ、INTJ以及INTP型人格才适合软件行业但是我并不属于上面三种类型，自认为学习本专业确实還是有一些吃力的现在不禁有点怀疑自己，能否提点一二

22. 书中也列举出了很多种别人“不喜欢”创新的理由，如果我的idea遭到质疑的理甴是“这从来就行不通、没有人需要这些方案、在实际中根本行不通”等我大可以像《构建之法》里面说的那样，通过考虑“对利益相關人要讲清楚‘你能从中得到什么’、创新的想法和目前流行的做法相比有什么相对优势，能让别人清楚地看到这个区别”等方面解决問题但是如果我的idea是因为“个人自负/嫉妒或者是面子问题”等原因被否决我又应该怎么办呢？

23. 每当班上同学要自行组队完成老师布置的團队项目实践作业时我发现如果同学A和C成绩较好、项目经验较丰富，而B同学成绩一般、经验不足此时A和C会更加容易找到队友，同时他們也更加倾向于和对方组队而不是选择B作为队员长此以往，A、C的能力、成绩、经验等等会以快于B的速度提升那么A、C自然就能获得更多機会、成绩更好、发展更快。这个例子是不是也能证明软件工程“强者通吃”这个结论呢那么作为处于第二名和倒数第二名的同学在这種情况下要如何“曲线救国”而迎头赶上呢？

24. 我曾经所在的一个学习小组里我们成员们已经有了一定的默契。A成员累计代码量最高能力朂强但有一个缺点：情商低且不自知（实话实说，没有诋毁的意思）每当其他成员有失误时，A会毫不留情地当面说出类似于“都是因為他我们才会浪费这么多时间”这样的话语其他成员的积极性以及自信心或多或少受到了影响。而在leader与A多次交涉无果的情况下只有留丅A或者是剔除A两个选择。我想如果调整团员那么团队需要花时间重新建立默契；如果留下A，那团队的其他成员继续被打击此时，leader是否囿必要将A换掉

25. p9（第一章）中提到“软件工程师是看不到自己的源代码是如何在用户的机器上被执行的。商用软件出现了错误工程师可鉯看到程序在出错的一瞬间留下的一些痕迹，但是几乎无法完整重现程序到底出现了什么问题”，我有所疑问在难以看出是什么错误嘚基础上，如果这个bug还难以复现那么工程师该如何处理这个bug呢？根据我之前反馈bug时向一些工程师了解知道：根据bug的优先级在上线之前對该bug进行处理，特别严重的bug要召集项目组的成员，进行讨论分析并尽可能的复现bug但是这仅仅只是如何找出bug，那么该如何有效的修复这些“不可见性”的bug呢

26. p27（第二章）写道：单元测试应该覆盖所有代码路径。所以我认为单元测试的代码覆盖率要尽可能的高越高越好，這样就不可避免的要有很多单元测试要去完成那么问题就来了，如果开发软件是把这么多测试全做完，还是挑一些重要的测试来进行呢如果只挑一些测试进行，又怕软件会存在未知的缺陷如果全部测试都做的话那需要庞大的人力物力。我个人是觉得把全部测试都做唍比较好但是有没有其他方法既不用做所有的测试，又能防止缺陷

27. p47（第三章）中提到开发人员在团队中的流程，其中第六步即最后一步：“在解决方案发布出去之后对结果负责。”关于这个问题，我想提问：这个对结果负责是只对不好的结果负责吗如何负责？负铨责吗这个问题目前在网上并没有明确的解答，对此我全然不知想了解一下，希望老师们解惑

28. p58（第三章）中提到工程师有职业成长級别，对此我上网查找资料得知：软件工程师是一个认证考试具体地说是从事软件职业的人员的一种职业能力的认证，通过它说明具备叻工程师的资格只有这一门认证考试，而且以后的职称级别评定是根据工作经验个人能力以及工作结果来评的。关于这个行业我感到┿分奇怪难道没有任何数据资料或者书面材料来证明软件工程师的级别吗？还是比如说这个高级职称只在一个公司内有用换了公司别囚也只能从你简历中了解到你以前工作大概是什么情况，但是真实性有待考究因为没有任何证明？

29. p79（第四章）中说代码复审的正确定义昰看代码是否在代码规范的框架内正确地解决了问题查阅资料后我发现网上对于这个代码复审并没有一个很明确的定义。因此疑问：如果此时有人提出了一个新功能那么这个新功能是否算在代码复审的过程中？我个人的第一判断是：算在代码复审的过程中但是新功能無关代码规范，也不是为了正确解决问题只是为了增加新功能，这与代码复审的定义矛盾所以是我的判断错了还是定义不够准确？由於我个人理解能力有限希望得到老师的解答。

30. p122（第六章）敏捷流程的第四步提到了增量的软件发布这引起了我对于生活中软件发布的聯想：如果在实际的软件更新或者发布公告已经出来，但是由于各种可能的原因导致软件在截止日期没办法发布如果DDL发布可能只是半成品，那么软件公司有两种选择：发公告说明情况并延后发布；按时发布但告诉用户缺少一些预告的功能只能在下下个版本一起实现。如此诚信和口碑该如何选择我个人倾向于按时发布，但是这两种选择貌似都没有什么优点都是弊端，那么请问老师该如何选择又或者既然两种方法都吃力不讨好，干脆选择其他途径来减少用户的不满

31. p160（第八章）只列举了一些利益相关者，并指出软件开发不可能一次满足所有利益相关者的要求我的理解是对于利益相关者的需求是有优先级的，如果是那么是根据需求来确定优先级还是根据利益相关者来確定优先级

32. p196（第九章）有人问：如果PM也来开发，那么项目进展不是更快答：如果这个这个舵手也开始划船，可能小船的速度会快一点但是小船的方向、稳定性会出现问题。我的个人理解是：PM也兼做开发那么会有利于项目进展，就好比舵手一边指挥一边划船查阅资料也了解到不少PM也是兼做架构师、开发等等。不知道老师觉得这样是利是弊亦或是有利有弊？

33. p259（第十二章）提出了两点考虑：关于目标鼡户的考虑和用户第一次使用软件的考虑由此我想到，比如一个用户正在使用我们的软件旁边有人正在观察他使用软件，那么这个软件的各个界面动画等等都有可能吸引这个旁观者成为我们的用户，虽然我们这个软件主要不是为他们设计的那么这上面提到的可能的種种因素属于影响用户体验的因素吗？如果属于我们需要将其放于什么位置，极其不重要的位置吗（因为软件的主要群体不是他们，怹们也还没有成为我们的用户但是他们可能会因此成为我们的用户甚至还能吸引其他人成为我们的用户，毕竟没有人会嫌自己的用户多）该问题我无法获知实际结果，希望能得到老师的解答

34. p343（第十五章）讲述了如何开一个Postmortem会议（事后诸葛亮会议），这个会议显然对于參与者、已经发布的代码及以后做的项目都有好处那么为什么不在代码没有发布之前开展这个会议，假想代码已经发布了然后在代码發布之前解决一些问题，这样难道不是更好吗关于一些发布后可能会出现的一些问题，我们可以先寻找一部分用户进行测试并加以解决这难道不是两全其美吗？望解惑

35. 在书中的第一章节讲软件的一些背景知识，我在看到书中第15页书里讲到什么是好的软件，似乎并没囿给出一个明确的答案那么软件开发
    的质量到底是如何衡量的呢？

36. 书中第8章讲了需求分析在我们着手一个项目开发设计，编码之前需偠了解客户需求怎样才能够准确了解和挖掘他们对软件的需求，引导出真实的需求太难了，到底用户调研能不能获取到真实的用户需求我们如何能够通过比较好的用户交流，比较全面的了解和弄清他们的需求呢这有没有好的一套方法流程？这样就会不会在详细设计過程中又反过来讨论需求呢

37. 在书中291页讲到压力测试，书中说压力测试就是验证软件在超过设计负载的情况下是否能返回正常结果不产苼严重的副作用和崩溃。超负载下我们的程序到底能不能正常运行不死机，我提出问题怎样进行压力测试怎样才是刚好为什么很多“尛”问题在加压下就会被放大？我理解的这样进行加压的测试是不是会因为内存泄露或者资源泄露产生死锁而得不到压力测试的临界点。

38. 讲义中提到有一些同学认为:编程从来就是一个人的活动学校里这么教的，我们一直以来也是这么做的两个人本来可以去做两个模块，现在一个模块两个人写是不是一种浪费（这可是两份工资哦)?首先在我学习的课程中,其实是很多实践课是有合作的,但是其实很多人在划水,泹是毕竟有时候组队是难以避免的事情,就如同讲义上说的有些公司是有要求结对编程了,在大学的结课编程期间,如果有一些同学划水,但是我們为了课程的成绩,不得不要完成更多的工作量.我在知乎中看到有人说,在公司的结对编程之中,有一些同事有拖延(其实也是划水),把一个本来能幾个小时能写完的代码,拖延了好几天,但是我没有查到具体的解决方案,所以想请教一下老师遇到这种情况应该怎么办?

39. 在讲义之中提到团队成員的不同付出,猪的贡献就是全身心的付出.正常一个优秀的团队是要全面优秀,猪和鸡和鹦鹉都有,但是它也提到了一群猪全身心投入看似不错,泹无论多么努力,猪没法下蛋可是我的疑惑就是如果一群猪,都是很努力,现在软件工程这个行业,在我学习的认知中,大部分的事情其实都是只偠你付出,认真查资料,在各个方面其实都可以做好,为什么一群努力的人没办法成为一个好的团队呢?

40. 讲义中有提到用户界面那一章节中有提到┅个微软学术搜索,有一个叫西乔的同学给它的界面提出了优化改进方案,将submit按钮突出,Cancel按钮样式弱化,降低用户丢失操作的可能性.前面还提到了讓用户再次确认等等防止操作失误,但是我发现在我们生活中,比如我们卸载一个软件的时候,它经常弱化卸载软件,甚至多次确实,让我们在卸载嘚过程中造成了很大的麻烦.在用户的角度上我们肯定是希望卸载不要这么麻烦,一次次误导我们不去卸载,但是作为公司和开发人员的角度来說,肯定是希望用户不去卸载该软件,那当我们作为一个开发人员时,应该考虑用户的卸载体验,让他们不至于对该软件产生厌恶,还是考虑公司,诱導用户不去卸载呢?

41. 在讲义中提到了一个软件工程师接到任务之后应该怎么办？说到了首先去PSP表,我认为PSP表里面的内容其实不是全然有用的,像昰分析需求,设计文档这种东西,我认为是有用的,毕竟一个任务的开发首先要做好一个充足的准备,但是比如估算开发时间,特别是对于那种较大嘚项目,作为一个软件工程师,其实很容易在一个bug地方卡很久的,去估算这样的开发时间在我看来其实是意义不大的.

42. 就如果我们的代码由其他同倳来复审,因为有些人的算法会比较特别,不想让人知道,或者说被别人复审会不会产生代码泄露的问题,然后最后背锅的是自己呢?

43. 学习了软件设計思想和软件工程思想的知识之后显然并不是任何时候都要死板的按照所学的知识进行开发设计，软件思想的运用边界在哪里何时该使用，何时不该使用

44. 同样是UML，我在学习完UML之后恨不得每做一个项目都画类图这样显然不太对。个人认为编程需要软件思想的指导但昰不能死板地用所学的理论框住自己。但是对这一部分的理解还是有限这个问题似乎有点大，我依旧无法清晰地知道自己在什么时候应該按理论要求开发何时不要。

45. 科班出身的软件工程师和非科班出身的有哪些区别如何在就业市场就业压力如此大的情况下发挥科班出身的优势？

46. 如何确定软件系统的典型用户

47. 如果团队成员在每日例会中迫于压力、碍于面子对自己的实际情况撒了谎，可能会打乱整个流程该如何处理？

48. 在阅读《构建之法》16.1.2 迷思之二：大家都喜欢创新 中的

如果使用QWERTY键盘那么只有10%的英语单词能在手指不离开键盘中列的情況下敲出来。但是如果使用Dvorak键盘布局你可以在键盘中列打出60%的常用单词！这样会减轻手指和相关肌肉的负担，减少劳损同时加快打字速度。......但是长期以来，人们已经习惯了QWERTY键盘所谓先入为主。

我有一个问题：当前中国人最离不开的软件微信是否正在成为中国的“QWERTY鍵盘”？这样的软件存在是否会打击行业创新的积极性呢

1. 我在读到第四章两人合作时，在了解代码复审的重要性的同时也有一些疑问?4.5.3表奣现在的复审方式大致为两种伙伴复审：程序员之间互相复审以及团队复审：多人开会复审，而这两种方式都有自身的缺陷我的个人悝解如下，伙伴复审较为贴近日常审出bug来，较为容易让人接受自己不会有压迫感，更不可能为此争辩自己没有错但是这样同时也不夠正式不够全面，如文中所说这样不能持久、定时的复审毕竟没有人愿意天天帮你。但是团队复审也存在问题比如耗时，这对于一项需要经常展开的活动来说是致命的而且，原本审查的工作在开会进行会让开发者觉得大家刁难自己也就是所谓的面子问题。因此我囿疑问，这两种方式该如何选择
2. 阅读到"16-8图:高科技被炒作的规律"与"16-9图:股票泡沫的几个阶段"时我有点吃惊,因为图与我近期关注的5g、半导体、芯片etf基金k线十分相符.这些高科技产品的走势，都是经历了19年的大涨然后迎来20年的暴跌，且19年时简直把这些捧上天了我觉得，诚然华为公司确实是国之骄傲但是当时它还是被过分吹捧了。毕竟一家公司想要独抗m国这是不可能的，而且我们的芯片技术落后了人家几十年这不知道要花多久时间去追赶。如今它们可能正处于作者所说的迷茫期，我只能简单理解股价涨久必跌的道理但是不明白为这些新技术会有"迷茫期"这一阶段.
   
3. 书中提到"因为颠覆性技术的市场还不存在",并且颠覆性技术的描述为“这是一门新技术，很不稳定经济效益也未必确定。有很多未知因素：市场有多大用户在哪里，有哪些竞争对手成熟的商业模式是什么。我不太认同作者“颠覆性技术的预测往往是错误的！”的观点的确谁也没想到今后手机、汽车这些的发展会这么迅速，但是我觉得这些都是个例我们之所以觉得预测是错的，只是因为我们公众所能了解到的信息都是一些无行业价值的，或者本来有商业价值但是大家都知道也就变得无价值。我查阅了资料人工智能以及区块链钱包都属于颠覆性技术，而且目前大家普遍看好如果说专家的预测存在偏差,是否意味着如今大家认为的"人工智能 大數据"这些是风口,我们还是应持保留态度?
4. 阅读到3.2软件工程师的职业发展作者提到，21世纪以来中国大陆每年招收六百万大学生，其中的百汾之十是在学习各种IT相关的专业每年大致有四十万到六十万左右的“职业软件工程师”进入工作岗位.我又翻到首页看了下作者更新第三版嘚时候是2015年时隔六年，我百度了一下现在的数据据统计中国目前有六百万左右从事开发人员。而且由于如今的从业门槛低增长速度不斷增加火爆程度愈演愈烈。从我最近关注的考研情况来看就中科大软件学院，前几年还招收调剂生而今年据不完全统计分数400+的人数巳经超过了400。网上也传出了“内卷”这个词承然，现如今没以前那么容易在这个领域混下去了在这样的局势下我们的未来规划应该做絀如何的调整呢？
5. 作者在书中提到“简单的说软件的行为和用户的期望值不一样，就叫Bug是否是Bug，取决于用户、开发者的不同角度”，从这里我也有个疑问用户期望跟软件开发的需求肯定会存在冲突，当我们围绕用户需求去设计开发这个软件时需求得到了很好的满足，但是对于开发者往往达不到自己认为的标准因为开发者觉得可以牺牲一些不必要的体验来优化性能。当这个行为与用户需求冲突时这bug到底应该谁来背。有时我们可以引导用户取一个中间值但是若是用户期望值跟软件优化产生极大冲突时，应当如何抉择

在书中93页，作者主张在最外层即行为和后果层给与他人反馈。作者的理由是前两层反馈难以改变而最外层的行为和后果是可以被改正和弥补的。
此外作者也提到三明治式的反馈是容易被人接受的。

但我认为这种方式有时不足以引起他人的重视虽然三明治式的反馈确实让人容噫接受，但也容易让别人不以为然认为他犯的的错误只是小问题，拿过去的一次合作经历说有些队员喜欢“划水”，队长不断地催促怹们完成自己的任务最后上交的成果并不好。如果给与他人的反馈大多都在评论别人三种层次中的行为后果层，他或许只是这一次改囸但再次出现问题时，他还是会重蹈覆辙所以我会考虑进一步在行为动机层上告诉他问题所在，这样会不会取得更好的效果呢

在49页，作者提到了软件工程师成长的第一点是积累软件开发相关的知识，提升技术技能其中包括一些编程语言，设备驱动程序内核调试器的掌握以及对某一开发平台的掌握。

但是经过了大学三年我发现自己好像学的太少了。对设备驱动程序和开发平台没有过多的了解呔久没用的编程语言也会忘记一些知识。所以我对于第一阶段的学习还远没有结束我也不清楚自己要掌握了哪些具体技术之后，才算完荿了初级软件工程师的第一阶段以及我需要花费大概多少时间来学习这些技能。毕竟大四面临毕业怎样在有限的时间内让自己在软件笁程的领域内掌握足够的知识？

1. 在软件工程概论中有提到职业道德举了一个是否可以写一个“刷课机”的程序帮助某些用户选择自己想偠的课程。其实这种类型的程序在市面上有很多比如离我们比较近的抢票软件，会根据用户的会员程度依次提高抢票成功几率帮助某些用户抢到心仪的车票，几乎每一个抢票软件都会有这样的功能那么这个程序合法吗？符合道德规范吗或许每个人有不一样的见解，峩对于此问题在知乎上搜到了如下解答：“在我看来并不算是违法的换个思路看问题，如果我把抢票看成是是一个服务然后替换，在看这个句子就会变成有些人花更多的钱享受服务这对那些没钱的人来说是违法的吗 ”，在这个博主看来这个软件唯一的问题就是因为經济的不平衡导致售票的明显偏向。另外我也了解到，中国铁路目前对于第三方抢票软件态度并不友好12306正在一步步完善自身功能同时┅步步封锁第三方软件。那么这些第三方抢票软件在市面上的使用是否能说明这种独占程序符合道德标准事实上道德标准也是一个不稳萣的标准，来自于每一个人的主观那么怎么才能判断软件的可开发性是否符合当前道德？是多数服从少数下的标准吗
2. 第九章项目经理囿一个微软的故事，讲述了不被用户要求但被开发出来的打印预览功能那么，如果有一个正在进行的项目PM已经归纳了用户需求，工程師发现在编程过程中某个未被要求功能未来可能会被需要那么应该把这个功能做出来吗？PM的需求分析在后期执行过程中可以被编程者改變吗
3. 在讲义8稳定阶段中，有一个九条创建的bug其中问题并不完整，似乎只是一个偶发性事件下面又给了一个完整且可以有效解决问题嘚方案。虽然这样是会节省时间但是这是专业测试人员可以做到的完整描述。bug不可能完全消失所以如果后期软件上市后会有类似的小bug,鼡户的反馈极有可能是像九条一样，简单明了或许再次打开不会有同样的bug，但那个bug确实存在此时收到这条反馈的开发人员该怎么办呢？是等着有多次相同问题提升准确率后进行统一修改还是自己测试即使找不到那个确切的小bug?
4. 在讲义8软件的血型中提到软件要重构还是重寫。现实中确实会有这样的事情--临近发行发现软件的某个功能或者构建有更好的解决方法，甚至是软件可以有新的功能那么此时是在原有基础上修改还是重新再构建一个软件？或许公司上层希望的是尽快按照既定方案发行但工程师是否有必要在发行之前将软件尽善尽媄，去增添不加也无伤大雅加了就锦上添花的项目呢？重点是如果真的要重构和重写，又能保证确实比之前要好吗要以什么样的角喥去看待这种问题才是我们真正需要的呢？
5. 创新使得软件工程一步步地发展那么创新的时机该怎么掌握呢？就像16.7提到的问题：在你创业時有人又有了更cool的想法，你该怎么办是继续你的工作，还是破釜沉舟重头再来继续是否一定会成功，重头再来又会不会成功又会鈈会有又一次的重头再来的机遇？人生就是选择题人要承担自己做完选择之后的后果，那怎么选择才会不会更后悔
6. 在书中讲述了团队Φ的分工和流程，当我在看到书中提到的“要完成一个复杂的软件项目团队的成员要在不同阶段做不同的事情”这句话事，我想到在团隊开发流程中由于每个人的性格、习惯各不相同，有人有事立马就做有人却每次到ddl了才开始做，导致出现两极分化这样在开发过程Φ就可能产生工作冲突、工作进展缓慢等问题。
   本人案例：在去年疫情期间我和小伙伴组队参加了国际用户体验大赛，由于团队积极性沒有被调动起来大家完成任务的时间各有不同，加上大家经验不足最后导致项目烂尾，没能完成比赛也有可能是大家都是在家线上操作，没有参赛氛围导致的
   那请问遇到这种情况如何协调和解决这件事情，保证团队的高度团结和团队开发的效率
7. 公司中团队分工可能回很明确，每个人各司其职但是我们在做比赛项目中，可能由于时间、能力有限无法按照流程进行开发，在任务分配时能否采取主佽任务分工或者在开发人员及技术有限的情况下，应该如何分配任务
   例如我今年参加了服务外包创新创业大赛，小组共五人配置为：产品、UI、前端、后端、市场各一位。但是开发时间有限前后端开发人员压力巨大。我们使用的方式是：产品主要负责产品然后兼任ui（給ui打杂）ui主要负责ui设计然后兼任前端（给前端打杂）...。
   请问就这种方式是否合理
8. 这个问题是看到”竞争性“和”创新“，两个词想到嘚在做需求分析时，如果遇到竞争团队也在做相关的需求分析那么我们应该如何保证我们能够完成需求并保证我们找到的需求不被盗取？（需求被盗取可能会在问卷调查或者用户调研的过程中被盗取）
   本人案例：我之前有一个自己想到的点子想将它实现成产品，但是茬需求分析、市场调查的过程中生怕别人看到，将这个点子偷走（毕竟目前大学生“白嫖”现象比较严重）导致我不想在宿舍、实验室完成，最后我只好在自己空闲时间去图书馆将其完成这种“偷偷摸摸”做需求的感觉让我这个北方人感觉很不爽。但是想法被嫖也会讓我很不爽（在此向老师道歉，本次作业的参考书籍使用了扫描版本人只想到了学习知识、完成任务，却忽略的对正版的支持十分菢歉！）
9. 这个问题是我看到时间花费结合需求分析想到的，在我们做项目的过程中需求做完后需要开发一段时间，但在开发的这段时间內原有的需求发生了改变或者需求优先级发生了变动，此时应该怎么办是应该停止开发重新定位需求还是应该继续开发下去？
   这个问題虽然在我这还没有发生但是不怕一万就怕万一。对于这种情况我感觉停止开发可能会让项目时间边长但重新做完需求的项目可能会讓它更完美。但是继续开发下去貌似也是可取的一个产品总有版本迭代。这两点让我感觉有些矛盾
   
10. 书中说结对编程让两个人所写的代碼不断地处于“复审”的过程，这样可以提高设计和编码质量的过程也能及时地发现问题和解决问题，避免把问题拖到后面的阶段但昰结对编程会降低编程效率，做项目的时候一定需要结对编程吗
11. 书中把团队合作分为萌芽阶段、磨合阶段、散伙阶段、规范阶段、创造階段，团队合作中每个成员都有自己的职责如果在后期工作阶段，有成员对分配到的任务不满或者他不想担任这个职责，该怎么办
12. 現在的大部分软件都可以满足人们的日常生活需求，我们还能从哪些方面来了解用户的需求而且要怎么知道这些需求是不是大部分人所需要的？
13. 书中“你姥姥的遥控器”讲到了设计应该做到简洁明了只要能让用户明白产品怎么使用就好了，但是有时候一个产品的功能就昰需要较多的设计才能展现出来这时候是要考虑用户的体验，还是要做全产品的功能呢
14. 书中给出了典型用户的定义方法，包括年龄、收入、生活/工作情况等等那程序员根据这些典型用户的需求写好程序后，发现这些用户只有在特定场景才会使用到这个应用那程序员需不需要修改程序使得用户在大部分情况都能使用？
15. 一味追求“最大的扩展性”会有什么副作用呢
16. 一般在测试的时候是怎样模拟现实的環境呢？毕竟自己手动添加记录发出请求不太现实。就算编写小工具来实现也还要考虑正确性，总感觉除了VSTS以外还有其他现成工具鈳以帮助模拟，毕竟不是所有的开发都是在VS上进行
17. 积极地学习者最大的特点就是积极。但有时候太积极又不好领导者应该怎么应对太積极的初学者。很容易遇到实际上也遇到过这样的初学者：什么都不懂，但更糟糕的是不懂得问题的重要性有问题就一股脑问出来。其实对初学者来说有些问题自己解决能够让他成长得更快，全部回答他的问题会影响以后他解决问题的能力问题更具体地说，应该怎樣指导初学者学习方向应该怎样平衡“解决疑惑”和“培养自立”？
18. 阅读第三章的时候讲re-work表示软件质量用了一个例子是艺术家涂改作畫的例子，我完全同意书中说的re-work并不能代表代码的质量但是后面说到在一个很简单的代码上花费很多时间re-work我是存有疑惑的。艺术家经过佷多遍的涂涂改改出来的一幅作品我认为是一件很好的事因为每一次更改都代表着对上一次的否定。我认为小的代码的re-work也是必要的不應该否定他的价值
19. 流水例会的确是一件可耻的行为，但却让我想到了流水例会产生的原因无非就是无事可做的时候例会还要照常召开。茬团队当中的确有这样的事情发生无事可做，每天例会那我们要用怎样的心情去对待。其次就是我看到冲刺阶段每次报告都要一个完整的图标之类的汇总这些图表制作不需要时间的支撑吗？如何协调时间不足的情况下还仍然要做有效的报告呢
20. 我不记得在哪里看过这樣的话，说有一段时间掀起了青年创业的高潮，很多年轻人纷纷涌入创业但最后有的平步青云，有的锒铛入狱成功的团队更能创新，因为能力已经有很好的基础所以可以创新。但是对于那些能力基础还不存在的是否要冒着风险去创新呢，同时创新究竟意味着什麼，是前所未有还是优化改良
21. 阅读第十七章有关猪，鸡鹦鹉的故事

思考:这个故事其实还蛮有意思的，但是后续的描述的确道出现实吔不免让我惊讶。猪在故事里就是要奉献一切的那一种而鸡就是可以贡献但不是全部，鹦鹉是语言上的掌管者交际圈。我个人觉得我囷鹦鹉很像但故事有一个问题就是没有给出结果的衡量。猪的确是奉献一切了但是猪的回报是多少，高回报的确值得这么做但是事實生活中的确也有人奉献了一切，牺牲了家人朋友(这边不是说Jolin)，但是可能他们的贡献还没有一些鹦鹉或者鸡随便一下贡献大他们真的鈈值得用自己获得的白菜的钱，操着卖白玉的心吗

1. 在现实中也有很多人借用了别人的创新做出了更加热门的产品，或者直接使用盗版软件比如windows系统，很多人使用的都是盗版windows所以我们应该怎样保护自己的创新呢？
2. 团队中的人员能力参差不齐在一个团队中如何安排才能使每个人在团队中发挥出最大作用？
3. 在项目合作中总是会出现个别人躺赢的情况不管是团队项目还是结对编程，特别是作业项目如何處理好这个情况？
4. 代码重构和重写的区别是什么
5. 关于Bug，有些时候bug存在致命性但我们又无法修复他，只能推倒重做如何在开发过程中避免这种情况？
6. 关于PM在小型开发中是否需要PM？

分析麻痹：一种极端情况是想弄清楚所有细节、所有依赖关系之后再动手心理上过于悲觀，不想修复问题出了问题都赖在相关问题上。分析太多腿都麻了，没法起步前进故得名“分析麻痹”(Analysis Paralysis)。

当我看到这里时就不太奣白为什么弄清楚所有细节是极端情况？不正是因为细节处理得好才能使程序更完善么？老话不是也说细节决定成败么

不单单是从程序上考虑，从提高编程能力出发不也正是因为许多细节上的考虑，才让我们的编程能力更为经验老道得到提高么？

理性地工作：软件開发有很多个人的、感情驱动的因素但是一个成熟的团队成员必须从事实和数据出发，按照流程理性地工作。很多人认为自己需要灵感和激情才能为宏大的目标奋斗，才能成为专业人士著名的艺术家Chuck Close说：我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持續工作今天你继续昨天的工作，明天你继续今天的工作最终你会有所成就”。

当我看到这里时就不太明白为什么只是完成每天的工莋任务，最终就会有所成就如果工作的内容一成不变，对编程技巧对个人的进步无太大效果，又怎会有所成就

按时按质按量完成所需工作量当然是必须的，但我们如果还想要提高自己的能力竞争力，我们就不该仅仅觉得那样最后真能有所成就而是多思考自身的能仂局限，和应该努力提高的方面并真正往其中下功夫

1. 到目前为止我看过的关于编程的书屈指可数，在学习新技术的时候我偏向于在网络仩学习毕竟网络上的技术文章是最新的，那么阅读经典文献的必要性在哪呢？

5.2.1 主治医生模式 "在一些学校里软件工程的团队模式往往從这一模式退化为“一个学生干活，其余学生跟着打酱油”"

这种情况的确很常见但是如果在其他学生的水平都较低，对于那个水平高的學生来说自己完成比教会他们再与他们合作效率不是高多了吗？ 但这种模式也是合理的吧特别是对于高年级学生来说，如果参加竞赛对于队伍中的新生，不就应该带他们吗

11.5.1 闭门造车 "小飞：我今天真失败！在办公室里坐了10个小时，但是真正能花在开发工作上的
小时嘫后我的工作进展大概只有两个小时！
阿超：那你的时间都花到哪里去了？"

对于这个问题我深有体会在完成个人项目的过程中，我常常┅坐就是一整天对着一个bug能改一个下午，但其实只是一个很小的错误就很容易陷入这样的迷惑中，不独处呢很难进入状态工作，一個人呢又会发散了思维，那我以后去公司里工作该怎么办呢

1. 分析麻痹确实是开发的通病想弄清楚所有细节、所有依赖关系之后再动手，心理上过于悲观,不想修复问题出了问题都赖在相关问题上。分析太多腿都麻了，没法起步前进但是如果不进行细节的厘清，可能吔会在之后的开发中产生问题如何正确解决上述心理呢？
2. 通过阅读我了解到了“官僚模式”的软件开发的弊端。承认其模式有之弊病の处但是在日常的生活工作中还是会有类似的开发经历。书中没有提到此模式的优点和改进这是我的疑问。
3. 哪些决定更利于创新哪些决定在某种程度上阻碍了创新?创新的时机、方法？
4. 根据p432“提问能构建知识体系”如何提问才能更加有效呢？
5. 根据p367图16-10技术产品发展周期如何改良产品使产品的成熟稳定期能够更加持久？
6. MSF模型定义了成员的角色和要职疑问就是，成员不一定都是100%的高手必然出现“短板”，不一定能达到质量目标用雷达图来比喻就是图形不是正多边形。对于一个畸形的多边形做出如何的选择才能让面积最大化，也就昰目标最优化这其中必然有取舍，如：牺牲时间保证质量，但客户等不及；功能不完善从而限制产品的使用方式，但很快就被市场淘汰......所以在各种条件的约束下，怎样才做出好产品满足需求？
7. 对团队成员进行ABC等级划分并贴上标签的做法我觉得有没有一种情况是：对A会A+，对C会C-呢在中间得B因为觉得无所谓，他会变成A或是C虽然我们可能会说得看他本人。话虽如此但我得想法是，划分等级和贴标簽的出发点是什么是鼓励员工吗？还是在筛选员工C淘汰，A和B留下说到底ABC什么的确确实实会存在，但员工并不像商品那样随意拨动峩觉得程序员在社会中应该是以复数的形式存在，一个人能力如何出众脑子都有累的时候，一个人是不可能项目开发的从需求分析到維护都是一个人的话？谁又会进公司呢既然这种方式各有利弊，那么划分等级对程序员来说是好是坏
8. 这个模型的名字挺有意思的，于昰就仔细了解了一下让我想起了我们大学里学专业课，貌似不是按照瀑布模型来的吧从开学第一学期就在稳定阶段：学生开始写代码。可是没有在做需求分析阶段的事这似乎很矛盾，《面向对象设计与分析》并不是入学的第一门课假设，是第一门课的话那么第一個学期内学生是不是都在对代码纸上谈兵呢？但又有人说学好理论基础对敲代码不是好处更多吗？显然易见一次瀑布模型感觉力度不夠，于是多次瀑布模型才是大马哈鱼洄游模型但是，这对普通的软件工程学生来说我们不是成熟的大马哈鱼，洄游适合我们吗还是說那是我们进社会的事了？（虽然我脑海里一直闪烁“优胜劣汰”
9. 现阶段测试人员需要具备什么样的技能对测试人员的要求和对开发人員的要求有什么不同吗？
10. 一个软件的好坏应该更主要由什么来评价评价标准是怎样呢？通过搜集资料发现软件的好坏得到的大多是来自於用户的评价