有始有终，课程总结
有始有终，课程总结--软件工程实践总结&个人技术博客
第一部分：课程回顾与总结
1.给自己的总结博客起一个有意义的标题。
有始有终，课程总结
2.给出以前提问题的博客链接。
跳转链接：软件工程实践2021第二次寒假作业
3.请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
1.我看了P25的对话，我不是很理解对话中提到了任何一个需求都可以表示成一个单元测试。我查了下百度有个叫‘需求覆盖’的说法，但也没说任何需求都可以对应一个单元测试，但根据经验，貌似任何需求都确实可以对应一个单元测试，感觉只要涉及某种输入输出情况肯定可以对应单元测试的。但对于性能的需求貌似不是用单元测试的吧，这个疑点不太明白？
解答：学习了软件质量测试后，我学习到了软件测试流程：单元测试->集成测试->确认测试->系统测试->验收测试。其中单元测试是采用白盒测试方法的，是逻辑驱动覆盖测试的。而集成测试同时采用黑盒和白盒测试方法，而黑盒测试方法又是需求驱动的测试。而集成测试是多个单元组成的更大单元的测试。故单元测试的小单元是实现需求的一个必要逻辑代码块。而P25中的需求如果是包括性能需求的，则是由系统测试阶段中的性能测试来测试的。
2.还是P25的对话，最后两句对话可以得知单元测试如果不是写着玩玩的，在模板被使用下还是很有必要写单元测试的。我有个问题：我以前从来没写过单元测试，即使经常出现bug，但我总觉得单元测试从性价比上还不一定有找bug来得快？我查了下知乎关于开发要不要单元测试，发现很多人也说时间成本太高了，认真的话可能的有2/3时间在单元测试，而且有人说大部分公司都是选择不写单元测试的，即有这样一个现象：所有人都赞同单元测试非常重要，然而很少人做单元测试。根据我以往的经验，没有单元测试开发除了在用户没有具体提出的要求如输入异常检验这类东西没有实现好，其他功能在‘正确’使用下最后也都没有问题。所以我对单元测试的必要性不太认同，只觉得可以但没必要？
解答：缺陷越早发现，代价越少。在一些比较复杂的项目如果没有进行单元测试，看这个测试过程：单元测试->集成测试->确认测试->系统测试->验收测试，如果为了省事跳过单元测试，甚至集成测试，就会导致一些原本可以及早发现的缺陷拖到后面才发现，这时候修改的代价将很大，如果舍弃单元测试，大量缺陷确认测试、系统测试、验收测试才发现将得不偿失。所以如果可以，尽量全面得进行单元测试。
3.看了P32的效能分析，但效能分析什么时候终止，是主观判断吗？ 我查了下效能分析貌似不能直接得出算法是否好，而是通过人对数据的判断，这样可以逐步升级算法。如果有被硬性要求还好说，但根据经验没有要求的话往往直接凭感觉已经优化到极致了就不优化了。难道效能分析程度是取决于人而不是需求吗？
解答：这题问的不好其实，效能分析是性能优化的一种手段，目的是找出消耗时间较大的函数、代码段，而不是优化性能，因为效能分析是手段。可以帮助我们进行性能分析，帮助性能优化对症下药，避免盲目优化。所以当没有在进行性能优化时，自然就不需要效能分析。
4.书本中提到软件测试人员的代码能力要很强，我认为说法不太正确。书上的解释是因为测试人员是最后一道防线。感觉意思是测试人员写的代码没专业人员测试所以对原代码质量要求高，不然出问题就麻烦了。但我还是不太懂，这不就是在说没有经过专业测试的代码必须由代码质量高的人写才安全，这貌似和测试人员代码质量要求高没什么关系，而是没人能测试的代码质量要求高才对？
解答：单元测试往往是由开发人员自己测试自己的代码的，所以不存在这个问题。单元测试->集成测试->确认测试->系统测试->验收测试中。显然开发人员的代码缺陷即使在单元测试没发现，后续测试还有测试人员把关；而测试人员的代码如果有问题，往往会因为代码是自己测试的，自己测试往往会忽略一些错误，所以测试人员代码质量要求高。这里指的是非必要情况，测试人员避免写太多代码，如果非要写，质量一定要高。
5.P324页形容全栈工程师为‘一个乐团的优秀小提琴手在交响乐演出的时候在台上跑来跑去，搞定其他所有乐器’，有这个问题：我认为这个形容不够贴切，软件又不是边开发用户边使用，应该形容成‘一个电音从业者，使用用各种演奏声音合成一个乐曲然后发布’。这样一来全栈人员的就有其存在意义了。虽然很明显，全栈开发不了太大的项目。但我有个困惑，很多知名的软件一开始立项和前期研发只有一两个开发人员，但后期产品火爆再招人不断升级产品不也是最开始的那个全栈起了个好头吗，全栈不也可以成就一个大项目嘛。
解答：虽然‘一个乐团的优秀小提琴手在交响乐演出的时候在台上跑来跑去，搞定其他所有乐器’可能没‘一个电音从业者，使用用各种演奏声音合成一个乐曲然后发布’贴切，但‘一个乐团的优秀小提琴手在交响乐演出的时候在台上跑来跑去，搞定其他所有乐器’更易于理解。全栈的演出也许效果不是那么好，但后续可以组建乐团，后续的演出同一首曲子也会更好。所以全栈确实可以为一个好的项目打下雏形。
4.是否原来的问题还不明白？如果有，请分析。
基本都明白了。
5.是否产生了新的问题？如果有，请提出。
暂时没有。
6.软件工程这门学问有很多“知识点”，这门课强调“做中学”——在实践中学习知识点。请问你在项目的需求/设计/实现/测试/发布阶段（一共5个阶段）中，每个阶段收获最大的知识或能力是什么？
需求阶段：写文档能力。
设计阶段：ER图、功能模块图。
测试阶段：我是前端，所以测试收获了接口文档的使用和F12后console的一些错误处理和手段。
发布阶段：了解了一些其他团队的一些项目，收获硬核知识倒是没有。
7.结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
个人项目：因为细节一些细节问题，代码得了零分，心得就是下次小心一点。还有对github使用理解不够，导致了一些问题耽误了挺多时间，理解了磨刀不误砍柴工的道路。
结对编程：结对编程作业一还没进学校，但通过腾讯会议还是有条不紊的完成了，结对作业二编程过程中总体上没有很大的困难都是一些小bug，由于是同一个宿舍的队友，沟通方便，我认为结对编程配合得好确实是一个不错的选择，能互相督促，由于有两个人遇到bug解决起来也会比较自信，而适当的自信有效提高debug能力，形成良性循环。
团队项目：团队作业经历了好多次作业，非编程部分由于各个任务组长合理的打分，让组员自愿领取，大家也都参与到了文档的编写中，我认为团队合理的任务分工机制可以有效带动组员。编程部分我们也进行了合理分工，总体上我在前端部分是属于活比较少或者比较简单的部分，组长不仅有效组织团队，而且在遇到问题是也起到表率作用，特地开会议手把手教学一波接口文档使用。并且在组员沟通上，小组群和前端交流群里面的沟通交流有效的让一个团队活起来。因此我认为团队项目的开发，一个优秀的组长必不可少，然后组员的交流也必不可少。
第二部分：个人技术总结
在Vue中使用Vditor编辑器
概述：Vditor 是一款浏览器端的Markdown编辑器,支持所见即所得、即时渲染(类似 Typora)和分屏预览模式。
