| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 第一次作业的链接 | 个人博客作业(1) |
对第一次作业中提出的问题的回答
1. 单元测试要由最熟悉代码的作者来写吗？
经过这几次作业，包括个人作业，结对项目和团队项目，虽然团队项目部分我没有负责单元测试，但是个人项目和结对项目的测试部分的经验，实际上单元测试不一定是要代码的作者来写。确实作者对代码最熟悉，写单元测试能检测功能，但是有个重要的问题在于作者设想的功能和题目、项目要求的功能不一定符合，作者写的单元测试能保证代码是否满足作者所设想的功能，但是作者不能保证其所设想的功能能够满足项目或者题目的要求。同时，作者的功能构思时候的局限性依然会反应到单元测试上，构思功能的时候忽略掉的边界条件之类的问题，除非构思测试的时候突然想到，不然还是很难通过单元测试反应出来。当然，作者设想的功能和需求的功能的符合程度，与作者自身的能力和项目管理以及人员之间交流有很大的关系，但是从实际效果的角度上，单元测试的目的是检验代码功能是否满足项目的需求。因此我认为单元测试的最佳人选是对单元功能的需求最了解的人，比如pm和负责测试的人员，当然如果对任务进行拆分的是代码作者，这部分的测试还是要代码作者来进行。总体上，负责测试的人员是保证从分配的任务的角度上保证代码功能的正确性，而功能内部的子模块的正确性还是要作者来保证的。所以，提高作者的水平，让团队内部对于功能的要求更好的传达，占有很大的比重。总之，我的结论是，单元测试不一定是由作者来写，应该是最了解功能需求的人来写，具体这个最了解功能的人与项目人员的组成有关。对于作者来讲，提升自身的能力更为重要，不能总是依赖他人检查出自己的错误。
2.结对编程中如何解决由一方占主导的问题？
这个问题不是很好回答，因为我的结对编程对象是我的舍友，大家的编程水平相近且比较熟悉。对于这个问题没有经验可以分享，但是我我的经验来讲结对双方的能力接近的情况下效率确实可以由很好的提升。课后对这个问题的思考的结果来说，结对编程是更适合双方水平接近的开发者，结对结对双方的水平差距是可能是结对项目的进度一个掣肘，但是双方通过结对方式进行提升的效率更高还是让弱势的一方先提升一定的水平再进行结对的效率更高，我是没有数据支撑的。但是总的来说，结对的对象尽量选着水平相近的开发者。
3. 作为一个软件工程师，是否应该参与用户需求的调研？
在团队项目的期间，我们是团队里面所有人一起参与讨论的。就我们经验来看，光凭开发人员参与用户需求的调研是不足以完全找出用户需求的，但是让开发人员一定的参与用户需求的沟通，可以从实现的角度及时的制止一些难以实现的功能，可以更好的提取出可实现的需求。总体上看开发人员参与跟客户的交流是有益的，但不能代替调研的人员，也没必要太多的开发人员参与这部分，有一个领导型的人物参即可。
4.现在的创新真的不需要成为领域内的专家吗？
这个问题的想法还是没有变，在高科技领域的很多方面，能够做出足够有突破性的，还是要有必要的专业的积累的。当一个行业处于早期的时候，没有太多的技术积累，这时候的创新就相对容易，而随着行业的发展，行业内的技术的积累越来越多，创新的成本就越高，很多创新是基于之前积累的技术的。比如说现在的汽车行业，内燃机车已经接近行业默契，技术壁垒和专利壁垒限制这我们国产汽车在这方面的发展，而电动车还是一个新兴产业，我们存在弯道超车的可能。很多时候不需要大量专业知识的就可以做出足够创新的领域是设计领域，而类方面的更注重创意这类对技术积累要求比较弱的方面。总之，不需要成为专家就能做出足够的价值的创新，要么是对创意要求很重的设计类行业，要么是新兴的行业，行业内的技术积累较少，这样才有可能在少量的技术积累的情况下做出足够的创新，取得成果。
5. 如何磨合团队，如何避免假团队和建立起团队内部的互相信任
这个问题还是偏大和抽象，总结经验来说，磨合团队，建立起互相信任的核心是保持人员之间的良性的互动。双方的互动应该是积极的，让人能够感受到是向着目标推进的。这涉及到交流的方式，同时还与团员的积极性有关。这方面主要依赖PM对团队内的统筹，调动团队的积极性，让团队内的沟通是积极有效的，摒弃和制止负面和情绪化的沟通。这方面很多是管理学的部分，这里也没办法展开太多。
这个学期实践中掌握的知识点。
需求阶段
需求阶段主要掌握的是NABC分析框架。掌握NABC框架可以有方向的对我们的项目的需求进行分析。
设计阶段
设计阶段掌握的知识点是《构建之法》164页的对功能的分类方式，将我们要实现的分为杀手功能、外围功能、必要需求和辅助需求这四个方面，让我们可以很好的对项目要实现的功能进行定位和取舍。
实现阶段
主要是结对编程的方法和特点，这个之前结对编程任务中学习掌握的。
测试阶段
团队任务中我负责的不是测试部分，主要是在结对编程中掌握的单元测试的方法的必要性，如何进行测试，如何看测试的覆盖程度等等。
发布阶段
这个阶段不是很多，主要的是ZBB, 团队对于查出来的bug零容忍，最终发布前修复所有已知的bug。
维护阶段
发布之后的运维阶段主要是事后诸葛亮会议，总结alpha阶段的开发和功能方面的不足，为之后的beta阶段做准备。
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
这一个学期下来，掌握了很多软件工程的方法和知识，同时亲身实践了很多其中的方法，收获良多。软件工程的核心基础还是自身的编程能力和设计能力。其中的很多方法可以提高效率，带来一些提高，但是基础的还是自身的编程能力，设计能力等，这些方法是锦上添花的，基础不牢，只掌握这些方法可以成为一个好的管理人员，但是不能成为一个好的开发人员。我的目标还是从事开发方面，因此基础方面还是要牢靠。
另一个，软件工程是一个团队合作的工程，作为开发者也不是孤身一人工作的，在提升自身的基础上，还要学会团队合作，处理好团队内的人际关系，才能让项目很好的推进下去。在提升自己专业能力的同时还要学习团队合作方面，人际交往方面的知识和技巧。