一、个人总结
在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；
请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。
| 类别 | 具体技能和面试问题 | 现在的问答（大三） |
|---|---|---|
| 语言 | 最拿手的计算机语言之一，代码量多少？（偏web前段） | javascript，代码量大概一两千行吧 |
| 语言 | 最拿手的计算机语言之二，代码量多少？（偏后端） | C语言，大概五六千行吧，学得还是比较浅显的。 |
| 软件实现 | (阅读代码的能力，实现，单元测试)你有没有在别人代码的基础上改进， 1.你是怎么读懂别人的代码的? 2.你采取了什么办法来保证你的新功能不会影响原来的功能? 3.你在开发中碰到最复杂的bug是什么，你是如何解决的? 4.这个bug出现的原因是什么，你在将来应该怎么去避免bug再出现? |
1.结对编程的时候所做的项目便是在别人代码的基础上改进的，当时开始的时候由于没有一份较为完整的代码规范文件，不清楚命名规则，导致不清楚有些方法所起的作用是什么，（也鉴于本人没有什么耐心，没办法把代码从头到尾地读下去）所以当时只能去运行代码，在一些地方适当加入一些输出语句，或者稍微修改一下代码，看看运行结果是否有变化。 2.为了保证我所编写的新功能不会影响原来的功能，首先肯定要充分了解整体源代码的基本功能，知道自己是在哪个基础上进行修改或添加的，增加新功能后运行出来的结果不影响之前的结果。 3.于我而言在开发中遇到的最复杂的bug可能是逻辑上的错误，单从代码上看没有编译上的错误，可是运行出来的结果却不是自己预期的。 4.遇到这种bug首先自己要理清自己的逻辑，找不出来可以让旁边的人帮忙看一下，毕竟有时候当局者迷嘛，实在不行可以换个思维，看看有没有其他方法可以实现。 |
| 软件测试 | (测试方法、测试工具、测试实践、代码覆盖率)你如何测试你自己写的代码?你如何测试别人的代码?你掌握了多少种测试工具和方法?你写过测试工具么?你如何对一个网站进行压力测试和效能测试?你如何测试一个软件的人机界面(UX/UI) ? | 目前只会在eclipse上做一些简单地测试，之前写代码很少进行测试，所以没有具体用过什么测试工具，更别说自己写测试工具了。 |
| 效能分析 | 效能分析，效能改进 你写过的最复杂的代码是什么?你是如何测量和改进它的效能的，用了什么工具，如何分析的? |
课设时候写的能源收费系统吧，当时写完就只验证一下各个功能运行结果没有问题就结束了，没有进行测试-_-! |
| 需求分析 | (需求分析，典型用户，场景，创新) 你做过多少个有实际用户的项目，用户最多有多少?你的项目有什么创新的地方? |
目前有实际用户的项目只有这次敏捷冲刺写的微信小程序，截止目前用户有43个，这个项目的创新点在于打破了传统背单词的思维，利用了游戏的形式，使用户在游戏过程中，帮助他们不断地巩固对单词的识记程度。 |
| 行业洞察力 | 你最感兴趣的领域是什么?这个领域过去10年经历了哪些创新? 你分析过这个领域前10名产品么?请分析一下他们的优劣， 你要进入这个领域，应该如何创新? |
最感兴趣的领域是人工智能，近年来大数据、云计算的发展，使得AI进入了一个飞速发展的时期。目前也只在人工智能课上学习一些相关理论性的知识，还没有深入了解。我觉得要进入这个领域，首先自身要有过硬的技能，再在技术上谈创新。 |
| 项目管理 | 1.你参与过项目管理么? 2.请描述一下两个当下流行的开发方法在你的项目中的具体应用情况;请问你如何决定项目中各种任务的优先次序，有什么理论来支持你的做法? 3. 如果你突然发现项目不能按时完成，你作为项目领导，有什么办法? |
1.没当过PM。 2.目前我们团队采用敏捷开发，敏捷流程是能尽早并持续地交付有价值的软件，所以我觉得实现主要功能是首要任务，即完成MVP，其次再是界面和一些辅助功能。 3.如果突然发现项目不能按时完成，我觉得应立即讨论决定必须完成的主要功能，然后针对这些功能加班加点地完成，其他的后续再说。 |
| 软件设计 | 你做过架构设计，模块化设计,接口设计么?请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果? | 接口设计，方便了成员之间分配任务时根据接口去完成功能的具体实现，结构更清晰，便于代码的管理和维护。 |
| 质量意识 | (代码复审/代码规范/代码质量)你是怎么做代码复审的，你加入我们团队后，能帮我们提高代码质量么，请具体说怎么提高? | 根据代码规范进行代码阅读和改进，编写一些测试用例找出程序是否存在错误或者缺漏，主要是根据这些来提高代码质量。 |
| 工具/社区 | Software Tools (performance tool, version control, work item, TFS)你在各种开发平台(web, linux, PC, mobile, machine learning) 都使用过什么样的工具，自己写过什么工具来改进工作效率? 给社区贡献过什么工具和代码? Github有分享代码么? 你写的技术博客坚持了多久，读者最多的是哪一篇? |
工具：eclipse、Visual C++、Visual Studio、Dev-C++、CodeBlock、微信web开发者工具。自己没有写过工具来进行工作效率。只有在码云上上传过代码。说来惭愧，所写的博客仅限老师布置作业，阅读量最高的是当年课设写的学生成绩管理系统。 |
| 团队协作 | Work with others (协同工作，提供反馈，说服别人) 1.请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取了别人的意见，改进了自己的方案? 2.你如何说服懒惰的同伴加紧工作，实现团队的目标? |
1.首先一定要先听取对方的想法和意见，如果觉得对方的看法还不错，就采纳对方的意见，如果觉得自己的想法更好，可以说“我觉得不错，不过我认为还可以这样······” 2.鉴于本人也有拖延症的倾向，只能说把一个比较大的工作量分成一个个比较小的任务，每天给自己分配的任务不要太多，在思想上就不会觉得：“啊！这个任务好像要花费很多时间，应该要有一个比较完整的时间，明天再做好了” |
| 理论素养 | 你上过什么数学，计算机或其他理论课，请举出具体的例子,说明你学到的理论知识如何帮助你解决实际问题。 | 恕我观察无能，能说我学习了计算机课程之后电脑或网络出现问题的之后，比较知道可能在哪里有问题了。不过目前给我最大的感受是学过了数学相关的课程之后，再学习计算机的一些课程，会发现原来知识都是想通的，数学中的很多理论在计算机中都有运用到，而且在学习过程中培养出来逻辑思维能力也能比较好的让我们去学习新的知识。学习了一门计算机语言以后，其他语言都是能自学的，其中的“套路”都是想通的。 |
| 自我管理 | 全年级你专业排名多少? 你从刚入学(大学一年级)到现在的排名有变化么? 如何解释你的排名的变化? |
现在专业排名第5，大一的时候大概排20名作业吧，也算是稳步上升吧，可能学习渐渐进入状态了吧。排名高低很大一部分取决于综测，鉴于本人比较懒，很少参加什么活动，em......综测分惨不忍睹。 |
二、回答问题
我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答
问题1：
原文（P1）
程序=数据结构+算法
软件=程序+软件工程
程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量。
——第1章 概论
由上述的说法可以看出，一个高质量的软件需要算法作为基础，但是我们大二时开设的算法课是选修课，有的同学没选，即使选了算法课的同学对于所学的也可能已经忘了。所以我想请教一下，虽然这是门软件工程课程，看似是软件的另一个分支，但最终对我们都要落实于写代码上，所以算法基础对于本门课程后期编写程序是否有影响？对于后期的代码优化我们是否还要再去学习一些有关算法的相关知识。
回答：在Alpha阶段的过程中，刚好我负责的部分涉及到需要考虑算法的地方，在这过程中确实体会到了好的算法和数据结构在一定程度上影响了整个软件的质量，不过这是基于程序部分的，整体来说用的还是相对比较少的，一个软件的质量好坏与否很大一部分因素还关乎到软件工程，在前期的需求分析，还有用户体验，用户界面设计等都在很大程度上决定了软件的质量。
问题2：
原文（P51-52）团队对个人的期望
理性地工作：软件开发有很多的个人的、感情驱动的因素，但是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工作。很多人认为自己需要灵感和激情，才能为宏大的目标奋斗，才能成为专业人士。著名的艺术家Chuck Close说：我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续地工作。今天你继续昨天的工作，明天你继续今天的工作，最终你会有所成就。
——第3章 软件工程师的成长
看了这段文字，引发出我一个问题，为什么说灵感是属于业余爱好者的，而职业人士只是每天持续地工作？我不否认大量地练习确实对于我们的学习和理解会带来极大的帮助，但是也不可否认灵感对于一个职业人士的重要性。前期我们确实需要通过大量地操作来进行入门，但当我们的知识积累到了一定程度后，我们要发生质的变化，我们便要学会思考，进行创新，创新的过程中也不乏许多灵感的贡献。而文中所提“灵感是属于业余爱好者，职业人士只是每天持续地工作”是否会让一些读者陷入误区？片面地认为灵感于职业人士是不重要的？我个人认为这段的表述如果如《程序员的思维训练》中所提的：“R&D精神（Rip off and Duplicate，偷师学艺），三个阶段： 1. 模仿 ；2. 吸收； 3. 创新”这样是否会让读者更全面地认识程序员的整个学习过程呢。
参考资料链接：http://blog.csdn.net/MS_hankwu/article/details/51014169?fps=1&locationNum=2
回答：从一定程度上来看职业人士确实需要严格按照事实和数据出发，站在用户的角度上进行软件开发。不可否认每天持续地工作，由量变引发最终的质变是必然的结果，一日复一日地工作最终是会有所成就的。而相对于业余爱好者确实自有一些，很大一部分可以按照自己的想法来。不过我还是认为不能把灵感和持续地工作简单地归结为业余爱好者和职业人士的区别。我总觉得引用Chuck Close说的这句话，并没有让我很好地理解理性的工作的含义。
问题3：
原文（P263）软件服务始终都要记住用户的选择
我同意第一印象很重要，但是当用户已经是第N次使用你的产品时，你的UI能否为这些用户提供方便呢？
——第12章 用户体验
原文（P351）迷思之三：好的想法会赢
数据显示，如果使用QWERTY键盘，那么只有10%的英语单词能在手指不离开键盘中间行（Home Row，即ASDFG那一排）的情况敲出来。但是如果使用Dvorak键盘布局，你可以在键盘中间行打出60%的常用单词（所有的元音和常用辅音都在那里）！这样会减轻手指和相关肌肉的负担，减少劳损，同时加快打字速度。
那么，这么好的键盘为什么这么少见，为什么大家都不用更好的键盘布局呢？
······
长期以来，人们已经习惯了QWERTY键盘，所谓先入为主。
——第16章 IT行业的创新
从上述两段话中来看，如果当我们的软件出现了需要大范围改变的情况才能大大提高使用效率，但是人很容易陷入先入为主的情况，一旦界面功能设计出现大的修改，就容易让人产生畏难情绪，甚至拒绝接受。就像我们看系列电视剧一样，当我们看了第一部后，如果第二部的演员突然之间换了人，这时有的人就没法接受（即使现在的演员演技台词各方面都比之前的好），有可能降低人们的观看欲望，甚至弃剧。我们该如何权衡两者之间的关系？是继续使用原来的界面，再进行一步步修改？还是放手一搏，说不定会有出乎意料的效果？
回答：在Alpha阶段结束之后，我们团队发布了一个初步的版本，并且找了一些用户进行体验。我们开始发布的版本整体界面过于简单，同时也存在着在手机上播放不了背景音乐的问题，有用户反映整个游戏过程中略显乏味，整体看起来比较单调。我们对于这些bug也进行了及时的修改。在这期间也发现了一个我们没有考虑全面的问题，那就是在游戏界面中没有一个返回或中途退出游戏的功能，这确实也是没有想到的地方，实际上是很有可能出现我不想玩这局游戏了，我想换个等级的情况，这个我们将在beta阶段进行改进。关于上述问题，我觉得对于一些界面功能大的改进不能单单只是凌驾于自己的想法之上的，自己觉得好就好，而没有站在用户的角度去思考问题。在这之前一定要做好充足用户调查，在用户调查的基础之上再去考虑使用原来的界面一步步修改还是直接进行大幅度地修改。
三、再提问题
同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。
列出一些事例或资料，支持你的提问 。
说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
问题1：
P114
敏捷开发的原则：
······
3.经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。
对于敏捷开发原则中所说的发布软件的间隔能短则短，我引发了一个问题：发布间隔真的越短越好吗？那我可以每天发布一个版本吗？对于这个发布的时间间隔是否有一个底线？对于这次我们的Alpha阶段，可以说是充分“遵守”了这个原则了，在第一个版本发布之后，由于在测试当中不断发现问题，我们几乎每天都更新了一个版本。可是总觉得这样的做法不太好，对于一个已经发布了的版本，过于频繁地进行版本更新，是否会让用户认为我们的软件存在许多问题？频繁的更新也容易让用户产生负面影响。站在开发者这方，如此容易就能发布一个新的版本，是否也会让我们在潜意识里认为发现了问题再去进行修改就好了，而不是在发布之前就尽可能的把所有可能出现问题找出来。
问题2：
P124
敏捷流程的经验教训：
·····
2.Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。
直接把原来的“经理”变成Scrum Master的效果真的不好吗？这次的敏捷冲刺中，我们团队就是直接把PM变成Scrum Master，书中P116提到“在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过Scrum大师（Scrum Master）来完成。这一措施较好地平衡了“交流”和“集中注意力”的矛盾。”一切交流由Scrum Master来完成，那是否应该是由一个比较能系统了解整个项目流程和进展的人来完成。也许是因为我们团队人员太少，项目也不大，相对来说PM是比较了解我们项目的整体情况的，所有由她来作为Scrum Master是比较合适的，最终的效果也挺好的。
问题3：
P163
用户问卷调查
这种方法是向用户提供事先设计好的问题，让用户回答。有时候用户在浏览某个网站时，一个弹窗会弹出来，打断用户的思路，不客气地要求用户回答几个问题。用户在问答这类问题是，是否会心不在焉，乱点一气。
作者在文中似乎并未就该问题提出解答。如果我们事先设计好了问卷调查表，应该如何让用户“心甘情愿”地填写这份问卷调查表？就此次我们在冲刺之前进行了一次需求调查分析，并且做了一份问卷调查表，为了尽快得到更多的调查结果，我们大多针对身边要好的朋友或同学发送了问卷调查表，但此做法是否会缩小了调查对象的普遍性，毕竟我们所接触到的大多难免是跟我们年龄相仿的群体。在现实中，我们由于害怕泄露个人信息，也很难为陌生人去填写一份问卷调查表。
问题4：
P182
经验公式：实际时间花费主要取决于两个因素——对某件事的估计时间X，以及他做过类似开发工作的次数N。
Y=X±X÷N //注：Y是实际时间花费。
从上述的经验公式可以看出，如果我们之前名没有做过类似的开发工作，那N就是为0，最终的结果实际时间就是无穷。也就是结果是未知的，这不就是算了等于没算吗？对于一个我们没有接触过的开发工作，这个经验公式还适用吗？
问题5：
P194
PM做开发和测试之外的所有事情
PM应该是整个团队的核心人物，想来应该是一个无论从技术或者管理能力上都应该让人信服和信任的人，试想如果一个连代码都不怎么会写的人怎么能说服队员听从他的安排和意见，如何能得到团员的支持。这样，问题来了，如果一个PM是一个好的程序员而不去做开发，那团队岂不是少了一个骨干程序员，这是否会影响整个团队的开发效率？