一、个人总结
| 类型 | 具体技能和面试问题 | 现在的回答（大三） |
|---|---|---|
| 语言 | 拿手的计算机语言（偏web前端，PC/Mobile App） | 了解了一点CSS和HTML5 |
| 语言 | 拿手的计算机语言（偏后端，数据处理，网站后台，机器学习等） | java、C++ |
| 软件实现 | （阅读代码的能力，实现，单元测试）有没有在别人的代码基础上进行改进，你是怎么读懂别人的代码，你采取什么方法不影响原来的功能，遇到的bug是什么，怎么解决，bug出现的原因 | 有在别人代码上进行修改；通过添加注释来读懂，遇到bug能解决的就解决，不能解决就询问他人或者查询资料或者能找到代码主人进行交流更好。 |
| 软件测试 | （测试方法、测试工具、测试实践、代码覆盖率）你如何测试自己的代码？如何测试别人的代码？掌握了多少种测试工具和方法？写过测试工具么？如何对一个网站进行压力测试和效能测试？ | 使用调试功能来测试代码。没有掌握测试工具，没有写过测试工具。对网站的测试还是用测试工具比较高效。 |
| 效能分析 | （效能分析，效能改进）你写过的最复杂的代码是什么？如何测量和改进他的效能的，用了什么工具，如何分析的？ | 没写过特别复杂的代码。 |
| 需求分析 | （需求分析，典型用户，场景，创新）你做过多少个有实际用户的项目，用户最多有多少？你的项目的创新之处？ | 本次的记账小程序，用户12个。创新是能够根据用户的消费情况给出合理的消费建议 |
| 行业洞察力 | 你最感兴趣的领域是什么，这个领域过去十年有什么创新？你分析过这个领域前十的产品吗？请分析一下他们的优劣。你要进入这个领域，如何创新？ | 我感兴趣的领域是制作网站。但是没怎么进行深入了解。 |
| 项目管理 | 你参加过项目管理吗？请描述两个当下流行的开发方法在你的项目中的具体应用情况。如何决定各个任务的优先顺序，有什么理论支持你的做法？如果项目不能及时完成，有什么办法 | 本次项目开发参加，开发方法：结构化方法、面向对象开发 |
| 软件设计 | 你做过架构设计、模块化设计、接口设计吗？请说明以下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么成果？ | 没有做过。 |
| 质量意识 | （代码复审/代码规范/代码质量）你是怎么做代码复审的，你加入我们团队后，能帮我们提高代码质量吗，请具体说怎么提高？ | 浏览代码看是否能够用更加简洁的方式来写，查找潜在的BUG。 |
| 工具/社区 | 你在各种开发平台（web，linux，PC，mobile，machine，learning）都使用过什么样的工具，自己写过什么工具来改进工作效率？给社区贡献过什么工具和代码？Github有分享代码么？你写的技术博客坚持了多久，读者最多的是哪一篇？ | 没有。 |
| 团队协作 | 描述你在项目中如何说服同伴采取你更好的方案？或是听取别人的意见改进自己的方案？如何说服懒惰的同伴加紧工作？ | 分析自己方案的可行性和特色。给同伴一个deadline给他紧迫感。 |
| 理论素养 | 你上过什么数学，计算机或是理论课，举出具体的例子，如何帮你解决问题 | 高等数学，操作系统，计算机组成原理，c语言，数据结构，java等 |
| 自我管理 | 全年级你专业排名多少？你从刚入学（大一）到现在排名有变化吗？如何解释这种变化？ | 没有具体了解。 |
二、回答问题
我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答
part one
p334 16.1.2 迷思之二：大家都喜欢创新
现在大众认为钻石很值钱，买的人也不少。钻石和石墨都是由碳原子组成，我们大胆设想一下，如果有人发明了一种在常温常压下能把石墨变成钻石的方法，可以廉价地生产大量的钻石，那么目前钻石产业链上的公司和从业人员，以及已经购买、储存了钻石的人们会有什么反应？他们会非常喜欢这个创新么？
……
可以看出，在算法和数据库领域，创新的想法一开始往往不被接受，而那些建立在前人基础上的“线性扩展”则往往有着更好的命运。而这些决定还是很有经验的期刊审稿人做出来的。
文中的反问“已经购买、储存了钻石的人们会非常喜欢这个创新么“，他们之所以会不喜欢，是因为损害了他们的利益，当钻石变成了廉价的大量的存在，也就不再有其超高的价值，而他们之前购买钻石所付出的大量的金钱也就不再值得了，所以他们才会排斥这样的创新。
我个人认为最富有创意和意义的钻石创新，是骨灰钻石。
骨灰钻石化学原理在于钻石的基本成分是碳，而人体含有18%的碳，火化后的骨灰含有2%的碳，可被提取制炼钻石。
被火化的人骨灰转变成“晶莹的钻石”，实现了让最亲爱的人“真正永垂不朽”之目的。
——参考资料骨灰钻石
但是，骨灰钻石的制作需要非常昂贵的费用，而且中国还未掌握这项技术。
当然，打造这样的“骨灰钻石”价格也不菲。最初的时候，制成０．２５克拉的钻石，需要４０００美元的工本费。如果要制作更大的钻石，譬如一克拉，那就得花上２．２万美元。不过，随着技术的成熟，现在，和上述克拉数相同的“钻石”，价格已分别降为２５００美元和１．４万美元了。
——引用自骨灰钻石 缅怀永挂心头
所以，如果有人发明了一种在常温常压下能把骨灰变成钻石的方法，大家还会不喜欢这个创新吗？创新的出现往往产生利益相关的一系列事情，而大家往往第一考虑的都是自己的利益。
part two
p252 12.1.5 不让用户犯简单的错误
“不让用户犯简单的错误”（Fool Proof）的原则当然是大多数人都同意的，高明的设计能让操作者不需要花费格外注意力，也不需要经验与专业知识即可凭直觉完成正确的操作。
经常看到新闻报道，说司机把油门当成刹车踩，结果造成交通事故。那么在设计汽车时，为什么不能把刹车和油门分开呢?把又问当成刹车这对于司机来说就是一个非常简单的错误，但是为什么在汽车出现了一百年的今天油门和刹车放在一起的设计还一直沿用呢？
在突发事件时，大脑作出的应急反应（无意识的）就是向神经信号更密集的右脚发出肌肉发力的动作。这个动作是源于人类DNA中原始的“受惊逃跑”（人类保留了未进化动物祖先留下来的，遇到危险马上逃跑，因此下意识会向腿部发出信号）。
而未经驾驶训练的人和经过驾驶训练的人，在应激反应下存在“是否会把脚移动到刹车”的区别。因此，实验证明了刹车放在油门旁边的必要性，也强调了驾驶训练的重要性。
——引用自既然油门和刹车设计在一起容易出事，为什么不把它们分开设计？
在紧急情况下，油门刹车这个设计可以说是用户体验非常不好，但是因为这个与人类的天性相关，设计目前无法改进，所以至今踩错油门这样的简单错误还时有发生。驾驶训练非常重要，并不是“不需要经验与专业知识即可凭直觉完成正确的操作。”
part three
p42 2.1.3回归测试
所以，对于“回归测试”中的“回归”，我们可以将其理解为“回归到以前不正常的状态”。
回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。单元测试是回归测试的基础。
回归测试的自动化具体指的是什么？
我在这里找到了答案。
关于什么是自动化
James Bach 曾经在一篇博文提到，自动化测试这个名字是非常有误导性的。它让一般的人误以为就是测试完全被自动化了，就像一个自动的咖啡机一样，我只需要把杯子放在那里，按一个button就够了。James说更加准确的叫法应该是“工具辅助的测试”。当然他还有另一层意思，就是好的测试用例是没有办法100%被自动化的，测试人员的经验，逻辑判断和探索性的测试方法都不能被有效自动化。我非常同意这个观点。作为这个论断的补充和扩展，自动化应该是审视软件研发活动的每一个环节，去发现那些可以被工具化自动化的重复性活动，然后去实现。广义的自动化应该包括但不限于以下环节：
-测试环境的搭建和管理
-测试环境的检查，监控和报警
-测试代码的编译和测试构建
-测试代码的静态检查和报警
-测试用例的分发和执行
-测试结果的保存与管理
-测试报告的生成
-测试优先级的建议
——引用自自动化测试的意义在哪里？
part four
p146 7.2.6保持敏捷，预期和适应变化
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化。
预期变化和期望变化有什么区别？
预期：是对未来情况的估计。
期望：指人们对每样东西的提前勾画出的一种标准，达到了这个标准就是达到了期望值。
预期变化与期望变化最大的不同就在于，期望变化是有个标准，而这个标准一般情况下是不会变的，预期变化则是对用户需求的一种估计，而一般情况下用户的需求都是在运动中的，会变化的，所以要保持敏捷。
——参考资料 百度百科
part five
p277 13.2.11内部/外部公开测试（Alpha/Beta Test）
在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这是开发团队会让特定的用户（Alpha/Beta 用户）使用正处在开发过程中的版本，用户会通过特定的反馈渠道（E-mail、BBS、微博等）与开发者讨论使用中发现的问题，等等。这种做法成功地让部分用户心甘情愿地替开发团队测试产品并提出反馈。
如果在公测阶段用户体验非常不好，这会不会导致正式版本上线后用户已经不再愿意使用该软件，即使问题已经修复？
我在网上没有找到相关这种问题的资料，我想可能是因为中国人太多，即使那些公测用户不愿意再使用，也只是很小很小的一部分，即使这部分用户流失也无伤大雅，因为还有基数庞大的中国网民。这就和广告宣传的力度有极大的关系了。
#三、再提问题
同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。
列出一些事例或资料，支持你的提问 。
说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
一个模板可以是这样：
我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。【或者】我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
##question one P63
>我看了这段文字“获得了相应公司和行业的认证，工程师就可以更容易地获得相应的工作、合同机会。”有个疑问是，现在有许多教育机构收费很高专门培训学生考证，这样出来的人员真的是高精尖的人才吗？如果不是那这种认证真的具有非常大的权威性吗？
##question two P89
>我看了这段文字“在结对变成中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多。程序的出事质量会高很多，这样会省下很多以后修改、测试的时间。”有个疑问是，如果一位程序员能力非常的强，而且也很自律，那结对变成对他来说不是一种拖累吗？如果他自己一个人在同样的时间里能做更多的事情啊。
##question three P195
>我看了这段文字“PM经常和人、管理流程打交道，经常处理“不确定性”，在反复多次对“不确定性”进行处理的过程中，一个团队的风格和习惯就慢慢形成了。”有个疑问是，当一个团队的风格和习惯形成之后，若PM更换，新PM不是原团队的成员，那这个风格是新PM去适应呢？还是团队成员去适应新PM新的风格？
##question four P222
>我看了这段文字“要注意团队成员估计一个功能所需的时间，如果时间超过两周，则需要再次细化。”有个疑问是，如何再次细化呢？根据我的实践，成员估计的时间是基本上都会比实际使用时间短一些的，所以估计时间超过两周有可能实际时间比两周更长，实际过程中出现的一些问题是不可预见的，所以这个再次细化是该如何操作呢？
##question five P316
>我看了这段文字“在稳定阶段的初期，团队只要决定需要修复那些缺陷，然后团队成员就会进行必要的设计、实现、测试工作，并签入代码修改。但是随着项目进展和发布日期的临近，团队还要保证修改方案不会给产品带来负面的影响。”有个疑问是，这个保证如何保证？谁来保证？有个例子就是eBay，当他开始决定对用户收钱之后用户就大量的流失了，难道在修改这个计划之前团队没有经过讨论吗，未来和市场有些方面都是不可预见的，做到保证不带来负面影响是不是太困难了？