软工网络15个人作业4——alpha阶段个人总结
一、个人总结
1.在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；
2.请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。
第一部分 硬的问题
| 类别 | 具体技能和面试问题 | 现在的回答 (大三) | 毕业找工作时 |
|---|---|---|---|
| 语言 | 最拿手的计算机语言之一,代码呈多少? (偏web前端， PC/Mobile App) |
js，代码量（没有概念，学习的时候和课设的时候编写过） | |
| 语言 | 最拿手的计算机语言之二,代码量多少? (偏后端， 数据处理,网站后台机器学习，等) |
java，代码量：大概一两千，两三千（为什么你们都明确自己的代码量？） | |
| 软件实现 | (阅读代码的能力， 实现，单元测试) 1.你有没有在别人代码的基础上改进? 2.你是怎么读懂别人的代码的? 3.你采取了什么办法来保证你的新功能不会影响原来的功能? 4.你在开发中碰到最复杂的bug是什么? 5.你是如何解决的? 6.这个bug出现的原因是什么? 7.你在将来应该怎么去避免bug再出现? |
1.有在别人代码的基础上改进 2.先读懂主要功能 3.多运行看自己的新功能是否对原来功能产生影响 4.编译时的各种报错 5.根据报错的内容一步一步修改（有的时候真的很苦恼） 6.大部分原因是自己不熟悉对于命令的使用 7.多学习多练习 |
|
| 软件测试 | (测试方法、测试工具测试实践代码覆盖率) 1.你如何测试你自己写的代码? 2.你如何测试别人的代码? 3.你掌握了多少种测试工具和方法? 4.你写过测试工具么? 5.你如何对一个网站进行压力测试和效能测试? 6.你如何测试一个软件的人机界面(Ux/UI) ? |
1.编译运行使用JUnit4 2.编译运行使用JUnit4 3.JUnit4 4.没有 5.利用压力测试工具和效能测试工具 6.利用相应软件并查看执行效果 |
|
| 效能分析 | (效能分析，效能改进) 1.你写过的最复杂的代码是什么? 2.你是如何测量和改进它的效能的，用了什么工具，如何分析的? |
1.象棋 2.根据运行情况以及JUnit4测量，用的工具是Junit4，一般根据运行时间以及运行情况（是否出错）进行分析 |
|
| 需求分析 | (需求分析， 典型用户，场景，创新) 1.你做过多少个有实际用户的项目，用户最多有多少? 2.你的项目有什么创新的地方? |
没有做过有实际用户的项目 | |
| 行业洞察 | 1.你最感兴趣的领域是什么? 2.这个领域过去10年经历了哪些创新? 3.你分析过这个领域前10名产品么?请分析一下他们的优劣。 4.你要进入这个领域，应该如何创新? |
1.设计领域 2.各种设计层出不穷 3.没有 4.抓住用户的痛点 |
|
| 项目管理 | 1.你参与过项目管理么?请描述一下两个当下流行的开发方法在你的项目中的具体应用情况; 2.请问你如何决定项目中各种任务的优先次序，有什么理论来支持你的做法 3.如果你突然发现项目不能按时完成，你作为项目领导，有什么办法? |
1.参与过。敏捷开发：根据相应的迭代促进项目的进行；MVP：项目中尽量先完成最核心的功能 2.首先是根据每个项目中打基础的任务最先完成，其次核心功能的相关任务优先完成，最后完成其他功能的相应任务。 3.首先与团队商量对策，如果加班加点也无法完成就只能相应的删减一些非必要的任务，比如界面设计等等，保证其核心功能的完整度 |
|
| 软件设计 | 1.你做过架构设计，模块化设计，接口设计么? 2.请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果? |
1.在设计项目时的架构设计/在程序编写时的模块化设计和接口设计（就只是做过皮毛） 2.架构设计了解整体构造，便于具体实施项目；模块化设计可以保证整个项目的完整度；接口设计可以减少不必要的代码，使程序更简洁明了。应该没有做过其他的设计方式，可能做了也不知道叫什么（比如这三种）。 |
|
| 质量意识 | (代码复审/代码规范/代码质量) 你是怎么做代码复审的，你加入我们团队后，能帮我们提高代码质量么，请具体说怎么提高? |
代码复审从需求和规格说明/代码设计/效能/可维护性/可读性等方面进行。 要提高代码质量，要明确每一行代码存在的必要性，尽量不写冗余的代码；再从代码规范着手，以便于日后修改和查看。 |
|
| 工具/社区 | Software Tools (performance tool, version control, work item, TFS) 1.你在各种开发平台(web, linux, PC， mobile, machine learning)都使用过什么样的工具， 2.自己写过什么工具来改进工作效率? 3.给社区贡献过什么工具和代码? 4.Github有分享代码么? 5.你写的技术博客坚持了多久，读者最多的是哪一篇? |
1.如题例举的开发平台上好像没有用过什么工具（用过也忘了） 2.自己没有写过改进工作效率的工具 3.工具-没有/代码-存在码云，应该可共享 4.Github没有分享代码 5.博客作业算是技术博客的话，应该是一年；读者最多的是201521123094 《Java程序设计》第1周学习总结 |
|
| 团队协作 | Work with others (协同工作，提供反馈，说服别人) 1.请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取了别人的意见，改进了自己的方案? 2.你如何说服懒惰的同伴加紧工作，实现团队的目标? |
1.在项目中我们都是一起讨论解决方案，从中选优；或挑选最优的点子组成解决方案 2.将属于他的任务分配给他，并要求按时完成；在大家做任务的时候也会不断催促他进行自己的任务。 |
|
| 理论素养 | 你上过什么数学,计算机或其他理论课，请举出具体的例子，说明你学到的理论知识如何帮助你解决实际问题。 | 高数/概率论/线性代数/数字逻辑/离散数学…… 算法的思想在各种编程中都起到了较大的作用，解决问题时多方面应用学到的算法 |
|
| 自我管理 | 1.全年级你专业排名多少? 2.你从刚入学(大学一年级)到现在的排名有变化么? 3.如何解释你的排名的变化 |
1.从大三上学期的成绩来看目前综合排名13 2.有变化 3.刚入学心态还在放松状态，之后通过自己的努力慢慢进步；其他同学有转向其他专业的意向（毕竟大三要开始谋出路） |
第二部分：软的问题（这份问卷感觉有的没有合适自己的选项）
-
保持高标准，不要受制于破窗理论(broken windows theory)。
当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。”a) 从来没听说过； b) 我就是这样随便过来的； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了。
a) 不懂啥是靠谱的设计； b) 随便应付一下即可； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。
a) 从来不看书； b) 看了就忘； c) 有时分享。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
DRY （Don't Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式。
a) 从来没听说过； b) 听说过，但是认为意思不大； c) 这要讲场合。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。
a) 从来没听说过； b) 出了问题再说吧； c) 想做，但是不知道怎么衡量效果。 d) 能够在多种语言和架构中做到 e) 不但主动做， 还会影响同事一起做好
Selection: c -
通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。
a) 从来没听说过； b) 把原型直接用于产品，不然就浪费了； c) 不用原型，一直在产品中直接改。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。
a) 从来没听说过； b) 按我的想法设计，用户以后会适应的； c) 大概同意，但是怎么接近用户呢？ d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。
a) 做完了，就知道花费了，不用事先估计； b) 大概估一下，不必在意时间 c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。
a) 一直用鼠标和GUI； b) 到时候问牛人； c) 正在学习命令行工具。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。
a) 只用老师教的一个； b) 随意； c) 没有任何定制。 d) 会定制，并且分享给其他人 e) 还会学习和使用各种编辑器的扩展。
Selection: c -
理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。
a) 从来没听说过； b) 模式没用； c) 每写100行程序，我就尽量用一个模式。 d)有实际使用的经验 e) 能用具体代码说明模式的利弊
Selection: b -
代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。
a) 从来没听说过； b) 用QQ，u盘即可； c) 领导要求才用。 d) 经常用 e) 不但主动做， 还会影响同事一起做好
Selection: d -
在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加 log。
a) 从来没听说过； b) 只会printf； c) 加log 太麻烦，我的代码不会有bug 的。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事，不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设，你认为不可能发生的事情在现实世界中往往会发生。
a) 从来没听说过； b) 太麻烦，不用； c) 想用，但没有时间。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: a -
只在异常的情况下才使用异常 (Exception), 不加判断地过多使用异常，会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。
a) 从来没听说过； b) 抓住所有异常 c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
善始善终。如果某个函数申请了空间或其他资源，这个函数负责释放这些资源。
a) 从来没听说过； b) 随缘； c) 有时这样做。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
当你的软件有多种技术结合在一起的时候，要采用松耦合的配置模式，而不是要把所有代码都混到一起。
a) 从来没听说过； b) 没有实践的机会； c) 代码都在一起比较好管理。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
把常用模块的功能打造成独立的服务，通过良好的界面 (API) 来调用不同的服务。
a) 从来没听说过； b) 拷贝代码过来用也可以 c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
在设计中考虑对并行的支持，这样你的API 设计会比较容易扩展。
a) 从来没听说过； b) 并行不会出错的； c) 任何代码都应支持并行。 d) 考虑在适当的层次支持并行 e) 不但主动做， 还会影响同事一起做好
Selection: d -
在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。
a) 代码都在一起比较好改； b) 随缘啦； c) 没搞清楚啥是V，啥是M。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
重视算法的效率，在开始写之前就要估计好算法的效率是哪一个数量级上的（big-O）。
a) 从来没听说过； b) 我的数据量不大，无所谓； c) 不会有效率问题的，现在CPU 都快了。 d) 主动测试程序效率，以验证估算 e) 不但主动做， 还会影响同事一起做好
Selection: b (偶尔测试) -
在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。
a) 从来没听说过； b) 想用，但不知道工具 c) 主要靠肉眼观察算法效率。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: b/c -
经常重构代码，同时注意要解决问题的根源。
a) 从来没听说过； b) 任何修改都可以叫重构； c) 每天应该重构两次。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: b (好像不是) -
在开始设计的时候就要考虑如何测试 ，如果代码出了问题，有log 来辅助debug 么? 尽早测试，经常测试，争取实现自动化测试，争取每一个构建的版本都能有某些自动测试。
a) 从来没听说过； b) 我的代码不会出问题的； c) 项目没有安排时间，我也没有提这事。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
代码生成工具可以生成一堆一堆的代码，在正式使用它们之前，要确保你能理解它们，并且必要的时候能debug 这些代码。
a) 从来没听说过； b) 从来不看那些代码； c) 那些代码没有bug。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d(一般没有进行debug) -
和一个实际的用户一起使用软件，获得第一手反馈。
a) 从来没听说过； b) 用户太蠢，不值得听反馈； c) 想做但是没有机会。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: e -
在自动测试的时候，要有意引地入bug，来保证自动测试的确能捕获这些错误。
a) 没听说过； b) 不必这么麻烦； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
如果测试没有做完，那么开发也没有做完。
a) 从来没听说过； b) 签入代码，就是做完了； c) 。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c (c大概是部分做完吧） -
适当地追求代码覆盖率：每一行的代码都覆盖了，但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件。
a) 从来没听说过； b) 覆盖20% 就好了； c) 要覆盖至少60%。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
如果团队成员碰到了一个有普遍意义的bug, 应该建立一个测试用例抓住以后将会出现的类似的bug。
a) 从来没听说过； b) 每个bug都是特殊的； c) 测试用例不值得加 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: b -
测试：多走一步，多考虑一层。如果程序运行了一星期不退出，如果用户的屏幕分辨率再提高一个档次，这个程序会出什么可能的错误?
a) 从来没听说过； b) 如果有问题，用户会报告的，我们不用测这些； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
（带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜。
a) 从来没听说过； b) 我们决定用户的期望； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
（带领团队） 不要停留在被动地收集需求，要挖掘需求。真正的需求可能被过时的假设、对用户的误解或其他因素所遮挡。
a) 从来没听说过； b) 用户不说的，我们不做； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
（带领团队）把所有的术语和项目相关的名词、缩写等都放在一个地方。
a) 从来没听说过； b) 都记在我脑子里； c) 大家看代码就好 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: c -
（带领团队）不要依赖于某个人的手动操作，而是要把这些操作都做成有相关权限的人士都能运行的脚本。这样就不会出现因为某人休假而项目被卡住的情况。
a) 从来没听说过； b) 我们没有休假的，没关系； c) 出了问题再说 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
（带领团队）要让重用变得更容易。一个软件团队要创造一种环境，让大家有轻松的心态来尝试各种想法 （例如，模块的重用，效能的提升，等）。
a) 都听领导的； b) 团队严肃紧张最好； c) 不必尝试，失败的可能性太大。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
（带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的进度安排更可靠，质量更高。
a) 没有时间总结，直接做下一版； b) 总结用处不大； c) 如果上级有要求，就做一下； d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
Selection: d -
（带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？
a) 我没看见矛盾。 b) 和稀泥，过得去就行 ； c) 如果没有捅到上级那里，就打哈哈，希望他们自己搞定； d) 有明确和一致的处理矛盾的原则 e) 不但有明确和一致的处理原则，而且对于影响团队士气的任何事情追究到底
Selection: d
二、回答问题
我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答
1. 复杂性、易变性是什么意思？怎么样的编程作业才算加入了软件特性？
Answer：复杂性主要还是指超多的代码量；易变性是指看上去容易修改但是实际并不容易修改。在我看来拥有软件特性的编程作业应该有较多的代码量，可扩展，不是完全难以理解的程序。
2. RUP是什么？
Answer：“RUP是一个通用的过程框架，适用于大型软件的开发。它的突出特点是用例驱动，以架构为中心，采用迭代和增量的开发策略。”简单来说，就是一种开发方法。
3. 敏捷开发与RUP有什么不同之处？
Answer：最主要的区别就是敏捷开发适用于小型项目，RUP适用于大型项目。
4.我们在开发软件的时候，要用到哪些测试方法？什么阶段用什么方法？
Answer：单元测试[程序内部数据测试]，集成测试[单元测试之后]，效能测试[单元测试，整合测试之后]，回归测试[发生修改之后重新测试]，验收测试[软件测试过程的最后一步]等。
5. 为什么领域外更有创新者？
Answer：正所谓当局者迷旁观者清。
（其实上述问题我在之前的博客也有给出相应的解答，这里改进/增加了一些新的看法）
三、再提问题
同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
1.在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。
2.列出一些事例或资料，支持你的提问 。
3.说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
- 一个模板可以是这样：
我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。【或者】我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
4.【附加题】：请将问题提交至豆瓣：https://book.douban.com/subject/27069503/， 并在博客中给出链接
在豆瓣页面的最下方 “读书笔记” 那里发言， 《构建之法》的作者会亲自答复问题
Question1：PM的工作到底是什么样的？
教材上比较详细的提到了PM是做开发和测试之外的所有事情：
典型的软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理——PM。
——《构建之法》第9章_9.1
但是我在Alpha阶段似乎误解PM的工作，看到许多团队的PM都在引领着每个团队，在开发上、流程上、心态上都需要付出非常多的精力。
那PM这么做到底对不对呢？PM的工作到底是什么样的？
Question2：怎么样的功能才是MVP功能？
MVP——Minimum Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。具体的做法是：把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见。
——《构建之法》第5章_5.3.6
我们在项目的时候，虽然明确最重要的功能，但是用户要使用的应该是我们这个项目——整个项目，那我们是不是应该将这个项目的全部功能简单的实现？这样子的话，MVP功能到底是怎么样的功能？
Question3：作为测试人员前期如何投入到项目中？
教材7.2.4中提到的MSF的基本原则之一：各司其职，对项目共同负责中说到：
团队中的每个角色都有自己的职责……
表7-1 MSF 团队模型和关键质量目标
| 关键质量目标 | MSF小组角色 | 出口条件 |
|---|---|---|
| 按约束条件交付产品 | 项目经理 | 项目经理们的项目是在时间/资源的条件内交付的么 |
| 按产品规格说明交付产品 | 开发 | 我们是否按照功能说明完成了各项功能 |
| 保证所有问题都得到处理 | 测试 | 我们发现了所有的问题，而且都有处理方案吗 |
| 产品部署和后续管理 | 发布管理 | 客户是否能快速方便地部署产品和进行后续管理 |
| 让产品更好用 | 用户体验 | 产品是否适应用户的使用习惯?易学易用 |
| 让客户满意 | 产品管理 | 客户是否(在总体上)满意我们的项目 |
——《构建之法》第7章_7.2.4
这里提到测试人员的职能，但是没有详细的介绍测试人员的具体工作，经过Alpha阶段，我有一些疑问：测试人员前期要做什么工作？测试人员如果前期没有加入到开发工作，后期如何了解整个项目并进行相关测试？测试人员具体要测试什么？即，作为测试人员前期如何投入到项目中？
虽然教材14章也有提出相关的问题以及解答：
- 测试的角色（Test）要独立出来么？
- 独立出来的测试角色怎么才能发挥作用？
- 有些成功人士或公司认为独立的测试角色不应该存在，你怎么看？
——《构建之法》第14章_14.2
在后面的总结提到了一个团队如何培养和安排各个角色，但是还是不太清楚。
Question4：代码复审到底怎么做？
阅读到第四章的代码复审，这里提到：
代码复审的正确定义：看代码是否在代码规范的框架内正确地解决了问题。
——《构建之法》第4章_4.4
其中代码复审的形式包括自我复审、同伴复审以及团队复审。
还阅读了“代码复审的核查表”，大概了解代码复审的内容，但是对于代码复审应该怎么做，还不是特别清楚；特别是在微信小程序中，好像没有特别需要做的代码复审？！可能是自己不太了解对于代码复审的定义。
Question5：什么是有限状态自动机？
一直想提出的问题是在教材11章中提到的
我们在计算机理论基础课上都学过有限状态自动机（Finite State Machine，FSM）……
——《构建之法》第11章_11.2.3
刚看到这个的时候，我的想法是，“有吗？什么时候学过？”。这样一概而论（或许真的有吧，我又没听课了？）的写在这里，好歹可以给一个介绍或者链接呐，毕竟总会有人不懂，难道这本书只是出给专业人士看的？对软件工程感兴趣的人会去查相关资料，但是如果能给出相关参考给人的感觉会好很多（可能作者有所遗漏吧）。
然后我默默的百度了
有限状态自动机（FSM "finite state machine" 或者FSA "finite state automaton" ）是为研究有限内存的计算过程和某些语言类而抽象出的一种计算模型。有限状态自动机拥有有限数量的状态，每个状态可以迁移到零个或多个状态，输入字串决定执行哪个状态的迁移。有限状态自动机可以表示为一个有向图。有限状态自动机是自动机理论的研究对象。
——百度百科
虽然没有特别理解，说不定什么时候用到了，自己也不知道。（术语呐……）
