| 这个作业属于的课程 | 软件工程 |
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/zswxy/computer-science-class1-2018/homework/11813 |
| 我在这个课程的目标是 | 对构建之法这本书提出的问题 |
| 参考文献 | 《构建之法》 |
1.关于代码规范的一个疑问
对于第四章4.2中的4.2.4 “断行与空白的{}行” 中提到的标准我表示不赞同。
虽然代码规范因人而异，书中提到格式C不够清晰，进而选择更清晰的格式D。
本人以前也常用格式D，但是后面改成了格式C，因为很多的语言书中都采用了格式C，并且格式C也属于现在大家比较公认规范的一个标准，以下两个例子一个是网上找的规范的例子，另一个是我用IDEA自动生成的代码，两种都用的是格式C，如果格式C不好的话，为什么IDEA的自动生成要用格式C而不是格式D呢？所以我认为格式C才是更好的标准，格式D过于发散。
2.‘从用户的角度考虑问题’具体可以有什么角度？
第十二章12.1中的12.1.2 “从用户的角度考虑问题” 中提到了 “设计不同于传统的数学题，是没有唯一的标准答案的”。后又举了邮箱地址、翻译等例子，但是看完后这些内容我只知道要从用户的角度考虑问题，我还是不知道具体要怎么考虑。
在搜索资料的同时，我发现书后12.3评价标准中作者的总结解决了我的大部分疑惑。作者列举了“尽快提供可感触的反馈系统状态”、“用户有控制权”、“一致性和标准化”等原则，让我对这个问题有了比较清楚的认识。
除了作者自身总结，我还通过网上搜索，发现了更多的考虑角度。简单来说，就是控制感、归属感、惊喜感、沉浸感。
控制感：给予用户控制感，让用户做用户想做的事情就是好的用户体验。
归属感：抽象上来说是一种意识形态上的认同感。举例就是“母校是一个自己天天骂三百遍，但别人骂一句就能拼命的地方”。
惊喜感：产品能在不经意的某一步超出用户的心理预期，触达用户心理最柔软的那片地方。
沉浸感：（我自己总结起来就是）傻瓜式操作+及时反馈+无其他信息干扰=上瘾/沉浸
3.关于书本第十三章“验收测试”中“可用”→“预览版”的疑问
在书本13.2“各种测试方法”的“验收测试”中提到了——如果所有场景都能通过，就是“可用”的，这种版本也就是“社区预览版”和“技术预览版”的由来。那么，既然已经“可用”了，怎么还是“预览版”，而不是“正式版”。如果这样都不能达到“正式版”的要求，那我们得达到什么要求才能把版本当作“正式版”？
通过查询网上资料，我了解到了“预览版”和“正式版”的定义。
预览版：尚未稳定的测试版。主要用于软件未来版本的改善与修正。
正式版：总结了之前预览版的BUG并修复完善后的版本。
通过这个定义，大概可以推出一个流程：经过测试确定“可用”→发布“预览版”供用户使用→通过反馈收集测试过程没有发现的BUG问题→修复收集到的BUG信息→修复完毕后发布更加完善的“正式版”。
所以我们在软件测试过后得到的版本只能称之为“预览版”，毕竟实践出真知，还没投放市场之前，就算所有功能都是可用的，实际上仍存在很多问题，必须经过“预览版”到“正式版”之间的过渡，同时“预览版”也不是我之前认为的功能不齐全的次品，“预览版”其实已经属于接近完善的版本，功能基本实现才能称之为测试版，只是测试版还需进一步考验才能晋升为正式版。
4.对于16章创新16.1.5“迷思之五”的解释，我有其他见解
"要成为领域的专家，才能够创新"这句话确实我也不赞同，但是我有其他的看法。
“事实上在WWW/HyperText协议刚出现时，一些计算机专家非常看不起这个玩意，专家们认为，一个文本文件上有一些文字，有些是蓝色的，用鼠标一点，就能打开另一个文件，网页上都不记录状态，这算什么难度，这又是什么创新呢？”这是书本中原话，单从这段话看，创新者不是专家的理由似乎是专家对于一些创新不屑一顾，认为其是微不足道的。
我觉得要创新与是不是领域的专家并没有必然联系。你不是该领域的专家，就能更容易在该领域创新，这句话也显然是错误的。透过现象看本质，你会发现，创新成功的人，最重要的一点是打破了思维定势，只是对该领域了解越深的人，就越容易陷入思维定势罢了，因为你对这个领域太过于了解。所以这个迷思的本质我认为应该是：谁能打破思维定势，谁才有可能能够创新。
还有另一种解释方法，就像书中提到过的“认知阻力”，正是因为专家对于自己领域内的东西过于了解，专家看到的东西与普通人是截然不同的，看问题的角度便会不同。
5.关于17章提到的团队合作的几个阶段，作为团队的一个普通成员（而不是领导者），要如何顺利的完成过渡？
书本17.5提到了团队合作的几个阶段，萌芽阶段→磨合阶段→规范阶段→创造阶段。书本中对于这四个阶段的特征做了说明，以及对领导在几个阶段要做的事做了详细的举例。但是对于一个普通的团队成员要做到什么没有详细的描述。
反复读了几遍书本内容后，我自己总结了各个阶段，一名普通成员应该做的（纯属个人看法）
萌芽阶段：尽快适应新的团队环境，尝试去了解其他成员，并弄清自己的定位，积极配合领导开始最初的工作。
磨合阶段：如果自身属于技术能力较强的人员，可以适当发挥自己的技术领导能力；注意与队友共事、交流的方式是否存在不妥；不要惧怕团队合作，加强自己的自信心和热情；碰到确实无法解决的困难，敢于寻求帮助。
规范阶段：团队的规矩已经定下，尽量不要试图打破规矩；时刻牢记团队的目标和决心；承认成员之间的差异性，并且要学习尊重成员。
创造阶段：（这个不清楚）