作业要求来自https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
粗略阅读了《构建之法》的1-5章节，发现这本书的语言很便于人们阅读，会运用大量例子来解释其中的原理，很少会因为读不懂专业术语而读不下去。不过，在阅读这几个章节时也遇到了一些疑惑，所以记录下来探讨一下。
第1章 概论
1.2.5 软件工程的目标——创造“足够好”的软件
这一章节主要讲述了什么是好的软件，什么叫做“Bug”，还有怎样创造“足够好”的软件。
好的软件的评判标准可以分为4点：
- 用户满意度——用户使用时发现了很多Bug，影响了用户使用软件的效率
- 可靠性——某个软件经常会崩溃，某个操作系统会时不时死机
- 软件流程的质量——软件团队和开发流程的问题太多，导致团队成员无法互相协作，按时交付软件
- 可维护性——某个软件太难维护了，按下葫芦起了瓢，修复了一个问题，另一个问题又出来了，也没有足够的文档，维护人员表示需要更多的资金和时间来维护这个软件
而怎样创造“足够好”的软件则需要做到3点：
- 研发出符合用户需求的软件说明
- 通过一定的软件流程，在预计的时间内发布“足够好”的软件说明
- 通过数据和其他方式展现所开发的软件是可以维护和继续发展的说明
至于什么叫做“Bug”，我看了这一段文字，我对这个说法感到很疑惑。
什么是Bug呢？简单地说，软件的行为和用户的期望值不一样，就叫Bug。
在我的认知里，Bug是功能上的一种漏洞，而不是一种功能。一个程序如果在需求设定拥有A功能，而A功能整体或部分无法正常运行，就出现了Bug。但如果A功能可以按照设定正常运行，而用户希望A功能更加完善或者再出现B功能，我个人认为这不叫Bug ，而是完善和升级。我查了资料，有这样的说法。
bug是一个英文单词，本意是臭虫、缺陷、损坏、犯贫、小虫等意思。现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug（漏洞）。
——《百度百科》
根据我的经验，我曾参与几个游戏的内测，主要测试游戏的漏洞然后反馈给官方，如出现黑屏、手机不兼容、点击不反应的状况等等，其次是反馈作为玩家希望官方对于游戏有什么改进，一般会把“软件的行为”和“用户期待值”分开处理。但是我还是不太懂，我的困惑是究竟Bug是指一种功能还是一种体验。软件行业也有一句著名的笑话：这不是缺陷，这是一个功能！（It's not a bug, it's a feature!）那这句话该如何理解。
第2章 个人技术和流程
2.1.2 好的单元测试的标准
这章节讲述了何为好的单元测试的标准。单元测试应该准确、快速地保证程序基本模块的正确性。单元测试应该测试程序中最基本的单元，如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成）。从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。关于单元测试的正确性，我看了这一段文字，不是很理解。
100%的代码覆盖率并不等同于100%的正确性！
我的疑问是什么是代码覆盖率？代码覆盖率的意义是什么？什么能等同于单元测试的正确率？我查了资料，有这样的说法，解决了部分问题。
代码覆盖是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，所得比例称为代码覆盖率。
——《百度百科》
代码覆盖率的意义
- 分析未覆盖部分的代码，从而反推在前期测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？需求/设计不够清晰，测试设计的理解有误，工程方法应用后的造成的策略性放弃等等，之后进行补充测试用例设计。
- 检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。
- 代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去，可以作为测试自我审视的重要工具之一。
在以往打代码的时候，我很少注意提高代码覆盖率，一般在单元测试只确保了正确率和寻找设计盲点，了解了代码覆盖率的意义之后以后会留意代码的质量。不过，究竟存不存在什么数据能等同于单元测试的正确率我还没探究到。
第3章 软件工程师的成长
3.2.4 职业成长——自我评估
这章节是教我们如何做自我评估的。有一部分人有足够的喜欢做最有挑战、最有风险的项目，而另一部分人则想在自己目前的能力做最能把握的项目，再慢慢提升。对于很多刚毕业的大学生，对自己的技术没有做充足评估，可能会面对工作时会夸大或者过于谦虚对自己能力的描述。其中，我看了这一段文字，我对这个说法感到很好奇。
很少有人能在学校里掌握这么多知识后应该在实际工作中不断学习和不断成长，根据自己的情况选择在哪个方面追求“专和精”，在哪几个方面达到“知道就好”的水平。
我现在在学习软件不同方面的基础知识，但对这些基础的学习面对即将实习感到不踏实。上文有提及到SDE（初级软件开发工程师）的要求是：入门。在学校里学到一些技能，尚未在实践中得到充分锻炼。我看了“做CRUD需要的核心技能和扩展知识”的图，了解了软件开发工程师是应该如何逐步往上学习的。
我目前还处于学习基础的状态，能知道一些基本需求的实现，像图上所说的增删查询，但还处于“知道”的水平，未到“熟练”。那对于刚毕业的学生来说，对于专业的学习究竟要到哪种程度才足够有自信面对各种面试，如果只懂得基本需求的实现，是否很难得到对口行业的录取。相比起不同技能都懂一点，是不是专精一个技能比较吃香点，我对此抱有一些好奇。
第4章 两人合作
4.5.3 不间断地复审
这章节介绍了结对编程为什么要不间断的复审、复审的内容还有结对编程和传统开发过程的复审区别。结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。
开发中的复审主要包括：
- 设计复审
- 代码复审
- 测试计划复审
- 文档复审
结对编程和传统开发过程的复审区别是：
1. 传统意义上的伙伴复审，即程序员之间的互相复审，复审人缺乏对程序的深入了解，减弱了复审的效果；不能持久、定时地进行复审；对需求和设计的不了解导致无法实现全面有效的复审。
2. 团队复审是指多于两人的团队就某一程序实体进行的复审，团队复审的缺点在于一起开会讨论的时间很少；牵涉的人员众多，理解程度不一，复审的速度和效果不能得到有效的平衡；由于成本问题，无法对所有的设计和代码进行深入的复审；由于人员众多，有面子问题。
我看了这一段文字，我对这个说法感到很认同。
结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。
一个完好的编程，其中肯定会遇到一些问题，而作为“驾驶员”的编程者不一定能找出所有问题，所以作为“观察员”的审查者可以以新的思维看待这个程序。但是这种方式并不能长时间进行，两人角色不断互换，思维容易混乱，精神长期紧绷。那么，究竟在何种情况下才使用结对编程呢？我查了资料，有这样的说法。
对于那些程序员没有完全理解的任务上，程序员期待更多的创造性，挑战，以及 高复杂度，此时使用结对编程最有帮助。在简单的，程序员都完全了解的任务上，结对编程导致生产力的净下降。
——《百度百科》
根据我的经验，我也与同学结对编程过一个程序，当时我们是先同时作为“驾驶员”完成自己部分的代码，然后期间遇到问题时再以“观察员”去审查自己和对方的代码查找问题。比起同时处理一段代码，我更喜欢这种在已有的逻辑基础上把所有问题按顺序条理出来。不过如果双方在编程的格式上有不同的风格，这样的方法会花上一倍或以上的时间去理解，所以注重规范编程格式是个良好的习惯。
第5章 团队和流程
5.3.6 渐进交付的流程（EvolutionaryDelivery），MVP和MBP
这一章节主要详细介绍渐进交付流程和MVP。渐进交付流程可以理解为：当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的evolution循环中进行[开发→发布→听取反馈→根据反馈做改进]。如下图所示。
而MVP方法是指：MVP——MinimalViable Product，最小可行产品，又称为MinimalFeature Set，最小功能集。具体的做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。
其中，我看了这一段文字，我对这个说法很理解。
MVP的指导思想和渐进交付相似，但是它更强调更早获得用户反馈，为此可以在产品完成之前就发布，它也强调产品的核心价值（产品最区别于竞争产品的地方），为了突出核心功能，别的辅助功能可以不考虑或者用别的平台提供的服务来代替。
我知道有很多软件都是通过信息收集然后分析，推出产品后再根据用户反馈进行维护更新。不过我认为这种方法适用于有资金、有固定技术人员维护的公司或大团队，而像私人或小团队的开发可能没有那么多精力在不断完善一个软件上。所以我觉得MVP方法无论是大公司大团队还是私人小团队都很适用。我查了资料，有这样的说法。
The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on.
这段话大概意思是MVP思想出来的产品可能会引起一些人的共鸣，而他们就会付钱支持和反馈体验。我有关注一个正在进行个人游戏开发的程序员。他和很多人一样，在没有什么资金的情况下，会先做一个有基本功能的游戏小demo来获取用户的游戏体验和反馈。通过用户的提议改善并且更新一些新奇的辅助系统，获得了大量好评，甚至很多人愿意众筹来支持这位游戏开发员。我的疑问是，是不是所有有能力的大公司大团队都可以采取MBP——Maximal BeautifulProduct（最强最美产品，MBP）的思路来开发软件，以此获得更大的竞争力？