一.旧五问，新五答
问题1：书中第二章里有一个对比大学四年级学生和软件工程师个人项目耗时的记录表，对比的数据可以很清楚的告诉我们初学者和初级的专业之间的差距，以及这些差距具体表现在哪些方面，但是这里所说的个人项目难度应该是不高的，这一点从二者的差距可以猜测出来，那么如果是接触到较难的项目呢？是不是又能说明很多道理？比如学习能力、工作经验什么的。
回答1：关于这个问题杨老师是这么说的“我猜测之所以不用更难的项目比较，是因为对于更难的项目，初级程序员没有能力完成，而不仅是花费时间更多。这就变成了有和无的比较。比较效果更明显，但是初学者看不到未来的路径”，这里就涉及到如何定义困难的项目了。说一个我自身的例子，考研的时候我数学复习的不是太好，做真题模拟题的时候难题总是啃不下来，但是基础题做得还挺溜，所以每次模拟的时候都在120往上，最后复习时间不多的时候，我选择了放弃难题，多去看一些固定模式的题目和一般难度的题，稍难一些的大题我只做前两问，这样时间也充裕分数也能接受。然而去年考研数学一难炸了，考完试到处一片哀嚎，这个难度的题目，和我一起复习的一个数学大神，做真题的时候稳定140以上，最后考了120多，他如愿去了北航，而我只考了60多。我考试时候的感觉是，如果说题目难度是水深的话，那一年的题难度很多刚好没过了我的鼻孔，所以我能做一做推一推，但是就是差一部分做不出来了，所以淹死的很惨，而我那个同学他数学看了很多难题，最后水即使很深，但可能只到了他的脖子，虽然很难受，但是仍然可以生存。
工程上定义难度也有一些指标，但是对于不同水平或者说不同的人，这个指标只是参考指标，毕竟任何事只要涉及到人就会比较难以捉摸，当然这也是软件工程存在的意义。学期末再来回答这个问题，我觉得这个个人项目耗时记录表的内容很多大程度上取决于项目的难度，在“水深”只到了大学生大腿、工程师脚脖子的时候，那一套软件开发的流程都显得不那么必要，个人似的英雄主义完全可以支撑完成这个项目，甚至不需要写文档做测试；但是一旦水足够深，比如没到脖子以上，摸石头过河的方式就极端不可靠了，就像杨老师说的软件工程是为了保证整个开发过程是可控的。这个回答也是在这学期做个人项目和团队项目的对比下体会到的，个人项目的时候我从来不知道做需求、写设计文档、做测试这些，好像自己就那么做着做着也就做出来了，但是团队项目复杂了很多，如果不按软件工程的模式来控制的话，最后一定是失败的。
总之，在这个项目没有“淹死”做对比的两组人其中之一的情况下，水越深，说明的道理就越是软件工程是必要的。
问题2：第三章里说到技能的反面，举例说了魔方的事，有一部电影叫《当幸福来敲门》，里面威尔史密斯落魄生活的转折点就是因为偶然间他给经理展示了当时并没有多少人会的魔方，尽管他拼的很慢也很捉急，但是这给那个经理留下了深刻的印象。那在工程师成长的路上怎么权衡自信和自知之明的界限比较好呢？
回答2：我觉得杨老师很棒的一点在于，他讲软件工程这门课，不仅仅在培养你能力，很多时候还在培养软件工程师的素养。虽然网上喷程序员的人很多，说程序员死板、不会来事，但是说实话虽然人类社会的高级也体现在人的勾心斗角，但是制约全人类高效进步的也是人的这些小心思。老师上课的时候给我们灌输了很多工程师应有的一些思想，比如守时、严格按照文档行事、工作上只对事不对人等等。虽然我现在仍然只是一个学生，但是我觉得按照规范的开发方式多做一些项目，认真的去做psp，工程师就会对自身的能力有很准确的评估，那么只要互相之间没什么险恶的小心思，自行和自知之明的界限就不存在了，因为彼此之间清楚了能力水平，不会出现问你这项任务你多久完成，你谦虚一番多说一些所需的时间的情况，那么这个项目完成起来会顺利很多，这个过程会走的很平稳。
问题3：很多种团队模式各有各的好处，各有各的坏处，总结起来就是适合的就是最好的，那在实际的公司，新组建的团队采取什么样的模式呢？如果当前模式不太顺利，是在做同一个项目的时候进行调整？还是做完一个项目再做调整？
回答3：这个问题没实际工作还是不好回答，但是就这学期团队项目来说，我们当然是在同一个项目中调整的，都是刚认识的同学，第一次做这样的项目，彼此不了解、能力不平衡，只能在做项目的过程中逐渐熟悉了解各自，然后逐渐调整，有的人就主要去编码，有的人去做测试，有的人去做需求，效率也就高了起来。但是我对实际的公司的情况仍然未知。
问题4：我是第一次接触软件工程的，所以里面所有的概念知识都很新鲜，觉得收获都很大，那对于已经工作了的底层的程序员，这本书他们看起来会有什么新的收获？又有什么现实里的作用？
回答4：无法回答。
问题5：软件工程讲的是软件宏观的概念，这本书里有用了很多例子来说明，那对于不满足于程序员身份，想要升职的人来说，是认真学习一本java实战有助于升职？还是挖掘软件工程里的内容有帮助？
回答5：就我目前的认识来说，一本java实战像是武侠小说里的内力，软件工程书更像是具体的武功，所以我觉得没有深厚的内力单纯的去练武功毫无用处，有了深厚的内力却不会武功也起不了很核心的作用，只有在学好基本功的基础上再挖掘软件工程的内容，才会有较大的作用和收获。
二.新五问
问题1：软件工程用来指导我们如何可靠高效的完成做软件这项工作，我觉得在软件工程里提到的很多开发模式做一些改动也可以在别的领域适用，与开发大型软件相似的，比如研发新火箭，这些领域也会有各种各样的难题，这应该需要一个更大的团队，有更细的分工和更高的要求，研发火箭出现的一个bug可能就会造成一次惨剧，那这些领域又有什么好方式可以保证这个项目的可靠性呢？是不是也可以做一些改动用于研发软件呢？对我们又有什么借鉴？
问题2：204页说到spec最大的敌人是乏味，但是我在网上看的几个spec都满足了乏味这个特性，我一个在华为的程序员同学也告诉我华为的文档也是晦涩难懂，极其枯燥，在这种旧的体系下，我们毕业去了公司要是发现那些大牛们所写的spec也都是乏味的，轮到我们写的时候应不应该遵照公司的习惯？
问题3：结对编程在实际的工作中存在吗？如果存在的话是存在于开发的哪个阶段呢？
问题4：282页说到软件测试工作中“侵官之害甚于寒”，在不通知测试人员的情况下，自行修改bug确实不可取，但是“如果急需验证某些问题，可以通知测试人员，让测试人员尽量早日完成”，这样听起来也会耽误一些事，能不能让开发人员和测试人员搞一个类似结对改bug的活动，来集中处理一下？
问题5：关于13、14章的内容，书里认为测试人员是必须有的，那能不能让“测试人员”在开发过程中和开发人员结对编程，然后到了需要测试的阶段再分化出来，这样的话开发和测试的效率会不会高一些？
三.致学弟学妹
这门课是我上过的最奇特的课之一，“做中学”的思想真的很关键，一旦抛开了这个思想那这个课也就和其他课一样平庸了，人们眼高手低这个特性在工科里真的很致命，我在大学里只听课考试的科目现在都没什么印象了，但是那些经历过严格课程设计和毕业设计用到的课程，都还记忆犹新，因为只听老师讲和自己真正动手去做差的不是一点两点，自己编程的时候可能都会忘了加“；”号，而软件工程这个课也真的要在自己亲手实践的过程中才能学到知识，所以千万不要在任何一个环节偷懒，如果掉队了哪怕没了分也要赶上来，因为后续的每一步都是在之前的基础上继续的，如果你漏掉一环就意味着漏掉了软件开发过程中的一部分知识。关于杨老师，越听他话的同学收获越大，我感觉他教学目的不是教学生而是软件工程师入门培训，希望你们能珍视这次上课机会。
四.重头来过
如果重头来过的话，我会在个人项目和结对项目中也采用规范一些的开发方式，比如写spec、wbs、版本控制、测试等等，因为回过头来看之前的工作，觉得很粗糙，程序的可读性很差，也没有文档，是在团队项目的对比下萌生的这种念头。
五.对老师说的话
我觉得只要不是被迫当老师的人，都是有教书育人这个信念的，我有两个北师大毕业的同学现在已经当老师了，只不过是高中老师，看她们在朋友圈发的这半年工作中的酸甜苦辣，我也能感受到一些教书的不易，她们感慨高中的学生还是像我们当初一样对未来毫无计划，很不听话，杨老师更感慨的是学生都是成年人了居然还是这个样子，这些想法是好老师才会有的···我是真的不想当老师，因为我怕我满怀激情去教学生去带学生，可他们总扶不上树，还到处惹事。杨老师是我最尊敬的老师之一，在这门课的教学里费了很大的心血，真的很辛苦，另一位最我尊敬的老师是张文忠老师，本科的时候教了我精密机械设计，课程设计的时候经常早上八点多来晚上十一点多回去，有时会和我们一起在教室吃外卖。我是跨专业的学生，所以很幸运在第一次接触计算机专业的时候遇到了这门课，杨老师讲的很多东西对我来说都是新大陆，在自己动手做了做以后体会更深。除了知识以外很重要的是杨老师讲的软件工程师的素养，很多时候还是希望多听一听的，但是课程时间真的很有限。希望老师能将这样的模式坚持下去，多注意身体！将来我要是来你们实验室打扫卫生的话可不要赶我走啊！