介绍自己
有一个可能比较少见的爱好，就是喜欢发呆，在一定的时间内清空大脑，可以放松自己的精神，来达到更高的工作效率。
现状、经验和计划
至于怎么选择了这个专业的，实话实话，高考结束后我的第一志愿是材料学，但由于同省有同学成绩高于我，并且填报了一样的志愿，所以被录取到了信息学院，又由于对其余几个系不感兴趣，因此在专业分流时选择了信息安全专业，经过大学三年的学习，发现相对于其他理工科来说，自己还是比较喜欢计算机的，也就坚定了继续学习的决心。
我认为比较重要的技能有Overall , Comprehension , Design , Implementation , Communication , BigData，但是估计自己现在只有1-3分，期望最终达到5-6分。我计划的提升方法目前有：1. 阅读github上优秀的开源代码。2. 在他人代码的基础上进行修改。3. 自己动手写勤写代码。4. 阅读相关书籍。5. 请教老师和同学。
心得体会
首先是我为什么要来上课并且认真参与，博客中讲的有一点我十分赞同，就是“认真听讲是一种能力”，从我自身的例子出发，初中后期觉得上课讲的不是很难，就经常走神，但当上了高中后想认真听课时才发现，真的是形成习惯了，很难让自己专注起来，只能通过不断的提醒让自己改过来。但是文中说课程有用无用不是一个大学生的格局能判定的，我不是很赞同，因为我觉得大学的学习，一方面是能力习惯的提升，另一方面知识的学习也是很重要的，毕竟我们不是花四年的时间来养成习惯的。而且我认为大学的课程也应该是与时俱进的，或者至少应该是不断调整进步的，而不应该是几年甚至十几年都没什么变化。
大学的大多数课程给我的体验是师生之间交流比较少，基本上集中在考前的答疑上，如果答疑课不去，甚至就变成了零交流，但若是让我直接找老师，又总有一种“畏惧”心理，就导致沟通越来越少。如果老师布置的作业对我来说有些困难，我更多的是会选择向同学请教，并花更多的时间，把作业完成。
我的看法是，如果你的工作借鉴或者引用别人的资料并且没有注明出处，相当于把别人的工作据为己有了，当然是抄袭，而且感觉这种现象在博客上尤为泛滥。不过我认为借鉴别人的工作还是很有必要的，很多事情我们没有必要从头做起，有巨人的肩膀，为什么不站上去呢，但是在这个过程中要记得注明出处就好。
**未来打算 **
我对于未来的打算是在来了msra之后才逐渐明朗起来的，希望将来可以从事学术研究方面，但是感觉自己差的还太远，首先就是知识的广度和深度，我一直以为只有在对一个领域有了一定的了解或者说知识储备量之后才可以谈创新，所以这个学期，我希望自己可以从阅读思考和代码方面有一个提升，一方面是大量阅读相关的书籍论文，建立自己的知识体系，另一方面就是提升自己的代码能力。
本课程计划
我希望通过这门课程，可以学到真正的实践级别的软件开发相关的知识和提高自己的代码能力（大学期间代码写的实在是太少了），目前的代码量，之前从来没有注意到这方面过，所以也不太会估算，大概有一万行吧，以python居多，因为前两年浪费了许多时间，所以会愿意多花一些时间来进行弥补，毕竟感觉这门课是长期受益的，也值得花时间去学它。
博客阅读
“在失望中寻找希望”阅读感想
虽然承认这个事实很让我难过，但是对于本科期间的学习，很遗憾的就是除了课本上的那些知识以外，我很少学习其余的，作为半个科班出身，现在才发现自己的知识和能力差的太远，就像文中所说，“多么无知，多么机械”，计算机的学习没有一个流程跟套路，并不是我按照怎样一个顺序按部就班的学下来就可以达到怎样的标准，希望之后的我再回顾这篇博客时已经有了长足的进步。
《构建之法》提问
这本书跟我之前读的技术方面的书籍有很大的不同，同时也让我了解到，软件工程只会编程是远远不够的（当然，编程还是很重要的）。
1. P79 第四章 两人合作
他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。
通过这次黄金点游戏的作业，我感受到了结对编程确实可以提高任务完成速度，但同时也产生了一个疑问，完成任务的过程中对于出现的问题，如果有两个人都不能立刻给出解决方案，都需要思考学习，那么在这种情况下如果一起学习或者思考，会不会由于学习习惯和知识储备不同导致效率太低呢。
2. P105 第五章 团队和流程
MVP的指导思想和渐进交付相似，但是它更强调更早获得用户反馈，为此可以在产品完成之前就发布。
我认同用户反馈是十分重要的，但是个人觉得用户的反馈也不能全部相信，有太多不确定或者不真实的可能性，所以我很好奇在真实的企业软件开发流程中，是否会处理这个问题，如果有的话，具体会怎样去做呢。
3. P280 第十三章 软件测试
探索式测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。
对于探索式测试，如果测试流程不可重复，那么怎样来保证测试出来的bug已经被修复了呢。
4. P158 第八章 需求分析
二项选择题。用户只用回答是/否即可。
我觉得这类做法还有一个问题，就是用户如果对两者都不是很赞同/喜欢，也同样会被迫选择一项，这样问卷发起者就会得到一部分并不真实的信息，影响最终的决策。可以加一个“都不想选”的选项，用来过滤掉一些没有参考价值的信息。
5. P253 第十二章 用户体验
微软公司有“吃狗食”的传统，团队成员都尽可能在实际工作和生活中使用自己开发的产品（从内部测试版开始），从而发现问题。
这的确是一个发现问题的好方法，但是如果由于内部测试版不稳定从而丢失重要的数据，会不会造成损失呢，感觉这样子反而得不偿失了。