软件工程提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 作业所属课程 | 软件工程班级博客 |
| 作业要求请点击链接查看 | 作业要求 |
| 我在这个课程的目标 | 学习如何用工程化方法构建和维护软件 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过回顾整个课程的学习，思考总结获得的收获 |
一.以前提问题的博客
二.对曾经提出的问题的解答
1.第3章 软件工程师的成长
问题：
什么是过早的优化？什么是合理的优化？如果全局过于大，又是否要去了解完全局后，再决定是否优化以及怎么优化？
解答：
就目前，以个人看来，当整体架构不清晰、不完整时，去花大量时间优化局部，属于过早的优化。而合理的优化，个人觉得有两种，一种是，对局部进行架构时，在不影响整体进度的前提下，花费较少的时间，得到更好的改进；另一种是，当整体功能已经完善时，根据对全局的重要性，有选择地对相应的模块进行优化。对于全局过大的问题，个人认为，如果是团队合作的项目，则根据团队的沟通交流，来决定是否优化；如果是个人的项目，因为全局过大，在未完成项目前，暂且不优化。
2.第4章 两人合作
问题：
在这里使用驾驶员和领航员用作类比是否不恰当？其次，是否专精一个岗位比经常交换好？
解答：
对于类比是否恰当的问题，是因为当时理解产生了偏差。
结对编程中有两个角色：
1.驾驶员：控制键盘输入。
2.领航员：起到领航、提醒的作用。
这两个角色是可以互换的。
--第4章 两人合作
两个角色可以互换这句话，当时以为是说，现实中的驾驶员与领航员可以互换，因为这两者是很难互换的，所以产生了疑惑。现在再看书，明白其已经定义了一个新的驾驶员和领航员，与现实中的不同。至于，是否专精一个岗位，现在看来，在两人合作中，经常交换比专精一个岗位，更利于全面的思考和解决问题，因为对同一问题往往有不同的想法，各有优劣。但在团队合作中，专精一个岗位比经常交换，更有利于效率的提升。
3.第4章 两人合作
问题：
如何正确地给予反馈，是否还要考虑情感因素，来选择最内层或是最外层。
解答：
我觉得应该考虑情感因素，来选择最内层或最外层。对于批评，客观大部分比主观更容易让人接受，但对于赞扬，主观大部分比客观更让人心情愉悦。因此，对于批评等让人容易产生不好情绪的反馈，应该选择最外层：行为和后果；而对于赞扬等让人产生良好情绪的反馈，应该选择最内层：本质和固有属性。
4.第16章 IT行业创新
问题：
伽利略的自由落体定律和开普勒的行星运动规律算不算“牛之队”在背后支持？
解答：
这个问题先放一边，来看看诺贝尔的物理学奖和化学奖。近代以来，诺贝尔的物理学奖和化学奖常常不是一个人获得，而且往往不是一个国家的，是来自几个国家的科学家共同分享。他们在不同的国家，做着相同领域的工作，他们之间可能有交流，也可能没有，但他们的成功，来源于这个领域前人所做的基础，同时也将给后人更高的风景。所以，我想或许对于做科学研究的团队而言，团队支持这个词应该有其新的时代意义。广泛而言，全世界在相同领域做研究的人，或许属于不同的国家，但对于这个领域、对于他们彼此而言，都算是团队支持。至于伽利略的自由落体定律和开普勒的行星运动规律算不算“牛之队”在背后支持？自然可以算，也可以不算。
5.第16章 IT行业创新
问题：
随着人类社会的发展，独立推出发明创造是不是将越来越难？
解答：
曾经听人说，乔布斯是互联网时代的最后一个个人成功者。仔细想来，这句话有其道理，现在推出的互联网产品，很难把它归功于一个人，都是归功于一个团队，一个公司。所以我想，随着人类社会发展，生活越来越智能，发明创造所需要的知识、能力、规模，越来越多，越来越强，越来越大，独立推出发明创造将越来越难。
三.在项目的各个阶段中学到的“知识点”，
需求阶段
在需求阶段，找到软件的相关用户，了解和挖掘其对软件的需求，并衡量各个不同需求的优先级，综合各个方面，对最终需要实现的需求进行调整量化。
设计阶段
在设计如何解决需求时，要考虑解决需求的方式，是否利于后续功能的扩展和添加。
实现阶段
在实现阶段，多与团队中的人沟通交流，不仅有利于推进团队进度，还能了解学习团队成员对一些问题的解决方法。如果有新的想法，要及时地提出并讨论。
测试阶段
主要的测试是单元测试，同时了解了压力测试，回归测试等。
发布阶段
在确定发布日期后，尽早地了解学习发布细则，避免一些耗时或难懂的问题，导致发布日期延后，并尽快准备发布材料，确保准时发布。
维护阶段
收集用户的反馈，分析其内在需求，并做出改进，及时地解决用户的问题，提升用户体验。
四.结合在个人项目/结对编程/团队项目的经历，谈谈理解或心得
对于结对编程，个人觉得事先制定计划和不断地沟通交流很重要，尤其是沟通交流。由于沟通交流不及时，结对编程的工作进展并不顺利，最后做出的成果也不尽人意。
对于团队项目，首先想说说换人制度，据了解似乎没有主动跳槽的大佬，而每个团队决定换人的方式也是各式各样。作为一个被换到另一个团队的人，尽管在另一个团队，接触了解学习了另一个项目，可是我觉得有两点问题，第一点是，刚到另一个团队，需要时间去学习新的知识，难以马上给团队做出贡献，而团队的其他人在上个阶段就已经完成学习；第二点是，换来换去，不管是对原来的项目还是现在的项目，对整个项目的具体进程，都只了解一半。
同时在团队项目中，我感受到了PM在团队角色中的重要性。尽管整个课程中，我都没有当过PM，但是通过观察接触多个PM以及其工作，发现如果团队中有一个优秀的PM，不仅能很好地设计、分配、监督任务，而且还能调动团队的动力和积极性，促进团队成员之间的沟通交流。最后，整个团队循序渐进地就完成了一个优秀的项目。
