| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春北航计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 系统学习软件工程相关知识，培养自己的软件开发能力与团队协作能力，接受一定的实战锻炼 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾曾经提出的疑问，为软件工程总结。 |
链接到以前提问题的博客
请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
单元测试必须由最熟悉代码的人（程序的作者）来写
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更合适的人选了。
——第 2 章 个人技术和流程 (P_{25})
问题：个人认为这个要求有一定道理，但如果这样会不会更好：
- 首先，由作者自己写一份单元测试初稿。
- 因为作者对自己的程序了解程度是最深的，他最清楚自己的程序在哪些地方容易出错，也最了解哪些地方应该被测试。
- 其次，由测试人员去完善。
- 如果让作者对每一个模块去完整地写一个单元测试，第一，很浪费开发人员的时间；第二，因为每个开发人员对自己程序的单元测试反而有所偏重，很可能会导致测试不完善；第三，团队协作时，成员的单元测试长得千奇百怪，不一定是最高效的测试方式。
这里维持我原来的观点。
我在 敏杰开发 团队中进行测试时：
- 测试方法论：后端狠，前端稳
- 前端随发布随测，团队成员的开发环境覆盖了windows、ubuntu1604/1804和mac xos，浏览器覆盖safari、chrome。
- 单元测试主要针对后端展开，前端主要以表格枚举测试为主。
- 后端目前为所有模型接口的CURD行为与权限添加了单元测试，共12个case
我们的测试方法就是先由自己去撰写单元测试，完成功能的基本覆盖，然后再由团队其他成员进行查漏补缺性测试，保证测试的正确性与完整性。这比完全由程序的作者撰写单元测试的效率更高。
专和精的关系
当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”，还是 “演奏家满场奔走，操作各种乐器”呢？当工程师设计软件的时候，工程师的设计、修改错误 等活动大致等同于交响乐的谱写完善阶段，两个职业都假设一旦程序/乐谱写好，它们就会被正确地执行。当一个运维工程师在维护一套系统的时候，运维团队要了解各个模块的作用、维护知识，以及和硬件、商业模式相关的各种事件的需求，如果这大部分运维工作都是一个运维工程师来完成，那么这位工程师的确是“全栈”，
——第 3 章 软件工程师的成长 (P_{53})
个人认为这一段没有很好地解释专和精的关系。
问题：对于程序员来说，是全栈好？还是专注一个领域好？
- 全栈工程师，也叫全端工程师，英文 Full Stack developer。是指掌握多种技能，并能利用多种技能独立完成产品的人。从学习编程开始，我就曾听说过这一名词，而且很多开发者都一次为目标。
- 然而，熟练地掌握前端、后端、客户端方向的知识内容，很难想象需要多长的时间，大多自称为“全栈”的工程师，都停留到各个方向的“略懂”，并不如专精于某一领域的工程师。
- 其次，国内的大厂一般不会在自己的招聘上书写自己需要招聘全栈工程师，因为大厂的发展靠的是分工合作，不指望一个人什么都精通。
- 而对于小型敏捷团队来说，我们可能不得不全栈。技术栈全面一些，在沟通上是有益的，相对会加速开发过程。
这个问题之前也在博客的评论区跟助教讨论过：
- mio4：一般创业公司会有很多全栈岗位，个人觉得主要原因是缺人，只能一个人干多个人的活。不过开发的效率不一定高，主要是因为难招到靠谱的人。
在我们的团队中，前端、后端各司其职，完成自己的工作任务，但是我也认识到，的确技术栈全面一些，在沟通上是有益的，相对会加速开发过程。我们团队的 PM 就是全栈型人才，有他在场衔接前后端的时候，开发效率大幅提升。
结对编程
既然代码复审能发现这么多问题，有这么好的效果，如果我们每时每刻都处在代码复审的状态，那不是很好么？事实上，极限编程（Extreme Programming）正是这一思想的体现——为什么不把一些卓有成效的开发方法用到极致（Extreme），让我们无时无刻地使用他们？
结对编程有如下的好处：
- 在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有相互激励的作用，工程师看到别人的思路和技能，得到实时的讲解，收到激励，从而努力提高自己的水平，提出更多创意。
- 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
- 在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。
——第 4 章 两人合作 (P_{78-80})
问题：个人认为，书中只提到了结对编程的好处，没有提到弊端，没有解决一下问题：
- 结对编程特别适合于知识的分享和传递，能够帮助开发者快速熟悉自己所不熟悉的领域，对于新手，效果最为明显。
- 但是如果两个人水平相似，并且对正在工作的领域都比较了解，结对编程似乎比较浪费时间的嫌疑。
- 结对编程对于结对对象要求较高，如果两人不和，可能陷入很多的争吵，导致进度停滞不前，甚至影响团队协作。
- 结对编程让两个人所写的代码不断地处于“复审”的过程， 但这种代码复审由于双方是共同开发者，可能会导致两人复审的思维一致性，从而忽视相同的问题，复审并不细致。
这个问题我在亲身经历 结对编程 后有了新的感悟。
我和我的队友水平相似，并且对正在工作的领域都比较了解，尽管双方是共同开发者，仍然有很多思维差异，对方的优点恰好拟补了我的不足：
- 结对伙伴复审非常仔细，对测试质量把控很高，这帮助我检查出很多潜在的问题。
- 交流中的领航作用很明显，为项目定义了很多设计要求。
- 学习能力和编码能力强，解决了很多问题。
使得我们的效率有很大提升。
同时，我俩的结对编程也属于第一次合作，双方的快速磨合也证明了，结对编程的门槛没有我想象的那么高。
敏捷流程
在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。
——第 5 章 敏捷流程 (P_{108-124})
问题：如何选择开发方法？(P_{124}) 页的表格给出了通过分析简单问题选择开发方法的建议，除此之外是否还有更好的选择方法？
共同推选一个开发方法，短暂尝试、不断微调是最好的选择方法。
没有绝对完美的第一选择，只有通过不断的调整不适合团队的方法，才能更好地推进项目。
PM 做开发和测试之外的所有事情
Program Manager——管事不管人
——第 9 章 项目经理 (P_{185})
问题：如何理解“管事不管人”？如果单从字面意思理解，“管事不管人”会不会导致“事”无法得到落实，不断拖延？
PM 如果得到团队成员的支持，会是什么样的呢？
反之，如果得不到团队成员的支持，PM会是什么样的呢？
问题：PM 如何才能最大限度地得到团队成员的支持？在没有一个很好的 PM 的人选时，如何选择 PM 才能更好地帮助团队？
依旧以我们团队举例：
- 我们组的 PM 是由大家推选出来的，能带领我们前进的全栈型人才，这就自然地得到了所有人的支持。
- 在没有一个很好的 PM 人选时，初期应该共同商议，在短暂的磨合期后推选出一个 PM。
- 将任务分配到任务组，再分配到个人头上，PM 的“管事不管人”，指的是关注于每一个任务，但关注任务的同时，也就相当于关注了人。
是否原来的问题还不明白？如果有，请分析。
软件工程是一门实践性很强的课程，学期初所提出的问题在后面的结对编程和团队开发中都有了很深刻的实践，所以我对原来的问题都有了较为清晰的认识。
是否产生了新的问题？如果有，请提出。
本学期的软件工程课程证明，远程敏捷开发是完全可行的。
马克·扎克伯格称：“就我们这样规模的公司而言，我们将在远程工作领域中成为最超前的公司。”他预计在未来5到10年间，该公司50%的员工可能将远程工作。
那么，面对远程办公可能成为的新常态，敏捷开发需要作出哪些改变才能使工作更加有效率？
请问你们在项目的需求/设计/实现/测试/发布/维护阶段中都学到了什么“知识点”。
| 阶段 | 知识点 |
|---|---|
| 需求 | NABCD分析法：从Need、Approach、Benefit、Competitor 和 Delivery 六个方面，分析目标用户。 |
| 设计 | 宏观规划：从前后端分离设计开始，抽象整个项目，分析可能的各种情况。 |
| 实现 | 使用 Github 进行软工开发管理、Django REST framework 后端开发 |
| 测试 | 单元测试框架、代码互审 |
| 发布 | 宣传项目、收集用户反馈 |
| 维护 | 不断跟进用户反馈，通过反馈发现 bug，改善用户体验 |
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
个人项目
个人项目与往常的开发并没有太多不同。
在经历了 OO 和编译后，我对代码规范有了更深刻的理解，也能更好的按照需求完成任务。
结对编程
从这次实际体验来说，我更多担任驾驶员的角色，我的队友更多是一个领航员。我们属于交替分工，交替复审。我主要负责核心功能的设计、封装和测试，队友主要负责 IO 处理、异常和 UI。在项目规范的设计上，主要是由他用“断言”的方式来制定规范。这次结对的过程并没有出现冲突、争吵等问题，双方的相处还是很和谐的。
代码复审既保障了代码质量，规范代码标准，同时帮助双方理解代码，为自己的设计提供便利，也保障了测试质量，及时检查出 Bug，不造成更重的修改负担。
同时，结对编程带来的责任感，使得自己不希望对对方产生影响，更想把自己负责的部分写好。
出现问题也时不再是一人挣扎解决，有队友帮助，效率更高。
团队项目
作为团队的后端，我第一次接触 Django REST framework 框架，也是第一次前后端协同开发。
我之前并没有深入地使用过 Github 除了代码托管以外的其它功能，这次从 Github 的项目管理开始，我也学习了开发工作流、Issue 交流、燃尽图分析等功能。
单打独斗和团队协作是大不一样的，沟通是团队协作中最影响开发体验的因素，通过 Scrum meeting 不断地交流需求，修改功能，和大家一起讨论解决问题，不断地被 push，才能更好地完成任务。
个人认为，软件工程的目的，和其他学科的类似工程方法，例如土木工程、车辆工程等，其核心是一致的，都是为了降低系统的复杂性、提高可控性，以此提高效率。
如果我们只是考虑写一个只用一次的程序，我们当然不用管那么多。但大型软件之所以称之为“工程”，是因为软件开发过程非常复杂。在工程中，我们在开发一个软件功能时并不需要完全了解整个系统的所有细节，只需要专注于某个局部。这样，相比于系统规模，减少系统内部的逻辑耦合就更为重要，这也是软件工程的核心目的。
软件工程本身是一个很大的范畴，软件工程方面的研究也纷繁复杂，但最终目的都是要减少程序员工作的负荷并提高软件需求、设计、实现、测试、发布、维护的效率。