1. 介绍自己
我是吴雪晴，科大信息学院的大四学生。将于九月底入职msra 秦涛组实习。
个人并没有什么特殊的才能，代码也写的不好，幸运地被选入了这个实习项目、与各位代码能力很强的同学一同学习工作，感到十分荣幸_(:з」∠)_
兴趣爱好方面，我是个非典型死宅，能宅着绝不出门。
2. 现状、经验和计划
在你一生中身体最健康，精力最旺盛的时候，能在大学全职学习和研究，这是少有的机会。请说明一下，你是怎么选择了这个专业的？
其实我算是ee专业的学生吧，大一、大二时的主要兴趣点在于单片机。随着单片机的学习深入，我开始慢慢地发现自己对软件、编程的兴趣远大于对硬件的兴趣，便顺应潮流开始学习ai方面知识。
离成为一个合格的 IT专业毕业生，在专业知识、技能、能力上还差距哪些？
| Skills | 课前 | 预期课后 | 提高方法 |
|---|---|---|---|
| Programming: Comprehension | 5 | 7 | 多阅读、使用好的开源代码，尝试复现结果并分析代码功能 |
| Programming: Design | 4 | 7 | 1. 阅读他人的代码，尤其是写的好的开源代码；2. 使用优秀的开源代码框架，熟悉其设计 |
| Programming: Test | 2 | 5 | 参与目标为写小产品的项目，通过编写面向用户的代码（而非research中主要目的为实验的代码）逼迫自己完善代码测试、增强代码鲁棒性 |
| Programming: Performance | 3 | 6 | 1. 常看开源代码，分析其优化、加速方法；2. 尽量熟悉各平台的各种性能分析工具，熟练掌握至少一种 |
| Basic Design Principles & Patterns | 3 | 6 | 1. 读书、读博客；2. 看开源代码，熟悉什么情况下应该使用、什么情况下使用design patterns反而是累赘；2. 自己实现时尽量尝试使用 |
你为何要来上课并且认真参与
我希望能参与一些更工程、更以用户为导向的项目。大学期间，个人参与的项目多为课程实验性质，或是research性质，主要作用是完成作业，或者尝试实验，而产品的设计、代码风格、鲁棒性等并未被重视，因此很多时候为了速度会牺牲很多软件开发应该重视的东西，如上表中我认为比较重要的design、unit test、performance，还有跨平台等等……我希望能为自己积累更多的工程项目经验，也能进一步锻炼自己的代码能力。
阅读博客的心得
师生关系（教学的基础 - 师生关系）
在大学中，师生关系其实是比较淡泊的；说实话，我感觉大部分课程的师生关系更像是stranger - stranger关系：老师只要讲课就可以，学生爱听不听，只要完成考试就可以。
在这门课程中，我认同coach - trainee的关系。因为这是一门非常重视实践、而非一味考试就可以的课程，因此只有和老师之间积极沟通反馈才能获得最大的收获。
之前在科大，我们也上过的软件工程课程，当时我们师生关系并不算太愉快，一个主要原因就是我们和老师需求不一致，也没有沟通成功。我们学生的主要困难在于学习技术、代码设计和管理（说实话当时的我们都是菜鸡），而老师显然更注重人员管理、分工、市场调研等非技术层面的知识。因此老师给出的很多要求（如精确预估进度、项目中更换组员等）我们无力完成，另一些要求（如组内互评等）我们感到累赘，而我们的困难也无法得到老师的指点、只能自己摸索。一年之后，我们的代码能力也都有了一些提升，希望这次课程中尽量少出现类似的情况。
上课听讲（Scalers：大学生上课为什么一定要认真听讲？）
这里的很多观点我不认同，而且我认为信息学院的大部分学生都无法认同。挑几个主要的点来说。
一定要记住，你在平时放的水，最后一定会流到你的脑子里的。其实我是不相信一个认为老师没水平的大学生，水平要高过老师的，老师站台讲台上，你就好好听讲。你在大学里面认为那个老师是水货，这个故事的另外一个版本是，你走上社会以后，你认为你的领导没水平，但是更真实的版本是，你没有水平。
我个人认为，上课不听讲，完全不等同于平时放水。学习的最终目的是学会知识，而每个人应该有理由选择自己适合的学习方式。这篇文章无法论证为什么听讲一定是一个优越的、其他方法无法取代的学习方法；就我个人的经验而言，对于很多老师照本宣科的科目，阅读课本、刷题就足以达到和听讲相当的学习效果，甚至更好。
而关于如何找到正确的学习方法，个人认为需要多尝试，比如一开始应该尝试听讲、刷题、看书、刷网课、实验……等各种学习方法，并且如果感到一种方法不够一定要及时尝试其他方法或者求助他人，慢慢便能找到自己的方法。
课程有用无用不是一个大学生的格局能判定的
这一点我相信大部分信息学院甚至科大学生都不能认同；科大在eecs科目的课程设置一直受到吐槽。具体不详细展开了；个人认为，部分基础的、“不太实用”的“过时”课程，如微机原理、信息论，确实有其存在必要，而且我认为这样的科目虽然学来头疼，但大家都能判断其重要性并认真学习；但科大的部分课程设置（不点名）实在匪夷所思，勉强水过也就罢了。
关于抄袭（最新软件工程总结，项目模板，软工作业下载）
实际生产中，个人认为只要不违法，都不能算是抄袭，以完成工作为重。但是学习过程中，为了锻炼能力，还是要尽可能原创代码，因此我认同课程杜绝抄袭。
几年后，你可以做学术研究、做软件项目、做其他专业的工作，做公务员，出国深造，回家继承家族企业... ，不同的选择有不同的努力方向, 你今天是怎么为将来准备的？
家里没有家族企业继承，如果有的话很想继承一波。既然没有，性格上个人倾向于在企业 / research lab中研究。今天的我在努力接触参与研究，希望能够在毕业前摸到科研的小门槛……
你在这门课的计划是什么？
锻炼代码能力。至于具体的安排，应该需要入职之后适应节奏后确定。
3. 提有质量的问题, 给认真的反馈
构建之法一年前读过，一年后重读，有了许多新的感慨。较快地把书本过了一遍，之后慢慢对部分章节细读。
关于结对编程（p81）
文中提到，结对编程的一部分功能是发扬复审的优点，但是我们之前的课程中结对编程只用于完成小项目，而团队项目中没有相关的技术；既然复审对于大项目很重要，在大项目中结对编程如何利用？
关于燃尽图（p112）
这也是之前的软件工程课程中老师明确要求、最后却流于形式的程序之一。因为我们由于工程能力、代码能力的不足，加上新手的过度自信，很多时候我们根本无法预估工作进度、给出燃尽图，或者预估一周做完，结果一周一周地拖；并不是有心拖延，而是能力确实有限。在这种情况下，应该如何处理？
与此相关的另一个问题在于，书中的方法如何惠及代码能力、工程能力仍不充足的学生？一年过去了，也许我们的代码能力已经有所长进、不至于出现一年前的问题，但假如做一个全新的领域，或超出我们的能力的项目，仍然会出现个人能力有限、完全缺乏对工作进度进行预估的能力的现象。这种情况下，应该如何处理？
关于PM（p192）
PM本身的重要性无可置疑，但是对于软件工程课程中，如何设置PM我有一些疑问：大家都是cs专业的学生，都试图提升自己的专业能力，谁愿意去？以及，对于一个小团队，并没有庞大的市场需要应付、庞大的队伍需要统筹管理，设置PM是否重要？根据我之前的项目经验，大部分产品设计、流程规划都由大家讨论完成，组长主要工作是应付老师（
这里同样有一个更general的问题：学生组队做项目的模式往往是熟人结队的性质，能否很好地进行正规化、专业化、流程化？甚至，这种正规化是否需要？对于人数少、关系密切、沟通较顺畅的小团队，正规化会不会反而引入了不必要的官僚风格以及沟通障碍？
关于图形建模 （p234）
说实话，看到这里的大部分方法，我的第一反应是我们上过的数据库课程，要求根据用户需求绘制数据库设计图，再设计代码；但是由于作业、考试题较为简单，往往很快就能想出代码，绘图反而十分浪费时间……
我这里的疑问也很类似：对于简单的问题，图形建模会不会浪费时间、流于形式化，或者也有其必要之处？如果简单问题确实不需要图形建模，在实际管理中如何区分两者，从而减少形式主义、但正规化程序设计？
关于用户界面设计（p270）
其实书中只提到了一个小问题，即软件设计者和界面绘制者如何分工，接下来就开始讲述具体如何设计界面了。但我对这个仅仅被提到了的问题产生了很大的兴趣：软件设计者和美工应该如何分工？如何合作？彼此如何依赖？
在之前的软工课程中，我们的队伍也有幸有一位美工，当时我认为我们只需要随意设计一个界面、把接口留好，后续“插入”美工的作品就好。但因为当时的沟通不畅、美工理解的功能和我们理解的很不一样，接口上也难以调和，主要的界面还是我们自己设计的。由于美工通常不会编程，较难和编程人员一起修改接口、进行调试，应该怎么处理？另外，美工的工作可能和软件设计本身都强相关，这种时候美工和软件开发人员的工作强依赖，如何处理？