| 这个作业属于哪个课程 | 2021春软件工程实践|W班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 1.课程回顾总结 2.个人技术总结 |
| 其他参考文献 |
课程回顾与总结
寒假作业二
新的解答
问题1：re-work
问题来源：
“有人试图用“re-work”来表示质量，那么改动少的代码最初质量高，因为re-work的次数少。笔者认为，re-work只是表明在软件开发过程中花费的时间，re-work的多寡并不跟最终的质量成正比。”
我的疑惑：
那软件质量与哪些因素有关？re-work次数主要反映了什么？
新的思考：结合复习软件质量和测试的笔记，里面写道软件质量的因素有需求分析、软件设计、编写代码、软件测试、规格模式、软件文档。结合本次团队开发的经历，在进行软件开发的前期，我们经过了需求分析、原型设计、数据库设计和系统设计，并且书写了相关的文档，方便开发过程查看，这些前期的工作每一项都必不可少，如果没有做某一项，势必会造成一定数量的re-work。当然开发过程也很重要，所以我觉得re-work次数反映了前期准备的到不到位和开发过程的细致细心程度。
问题2：goto语句
问题来源：
“函数最好有单一出口，为了达到这一目的，可以使用goto。只要有助于函数逻辑的清晰体现，什么方法都可以使用，包括goto。”
我的疑惑：
“goto语句在我的印象里，老师一般都不太提倡使用，因为可能会使程序难以理解，难以查错，并且可以使用其他语句来代替。所以goto语句是否应该被使用，其存在的合理性是什么？
新的思考：
整个软工实践过程中，我主要是负责前端开发，没有使用过goto语句，加上并不太擅长一些后端的开发语言，所以对此还是没有太多新的认知，还是维持原思考。即：在不具备垃圾回收机制的语言中，使用goto语句是合理的，使用其可以简化程序，也不容易忘记释放资源。
问题3：结对编程
问题来源：
“结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力的下降。”
我的疑惑：
我一直以为结对编程甚至团队编程时，是大家主要负责自己更擅长的事情。这种经常互换角色的操作，其实会不会不利于编程？因为可能互换后我对这一部分的工作并没有那么熟悉，反而做的更不好。
新的思考：
结合我与队友结对编程的实践经历来说，首先我要肯定结对编程的好处，它确实是一个很棒的开发方式，之前我会觉得应该做各自擅长的事情，但结对编程的过程中，我和我的队友其实并没有这么做，并且做到了角色的互换，尽管我们对于对方的任务领域并不擅长，但我们仍然可以和对方进行讨论，检查对方所负责的任务，提出相应的改进建议。这提高了我们的效率，并且不至于后期脱离原本的目标而导致大改。
问题4：迷思之三：好的想法会赢
问题来源：
“原始布局设计的优点失去了原有的价值，反而变成了弱点。但是，长期以来，人们已经习惯了QWERTY键盘，所谓先入为主。”
作者观点：
好的想法不一定会赢。
新的观点：
之前我的观点是好的想法会赢，只是可能时机未到，或者没有坚持或者改变的决心。现在我认为好的想法会不会赢，要看后期投入如何，还要看时机。比如本次团队开发，有些小组的想法确实很新颖很棒，但是他们可能后期存在一些工作的到位或者其他原因，最终得分并不高。又或者拿我们组举例，假设我们的Fidle也是一个好的想法，β后期我们的投入与产出比也不错，但是却无法上线，因为涉及到信息发布的问题，所以这其实也没有赢。
问题5：迷思之五：要成为领域的专家，才能创新
问题来源：
“研究表明，70%的创新者说，他们最成功的创新，是在他们拿手领域之外发现的。”
我的疑惑：
我一直以为，创新的基础，是要他已经掌握了这项技能或者知识。正如作者在第三章技能的反面那里说的魔方的技能层次6——能够设计出新型的魔方，但这个层次6之前的层次5是要求已经对魔方玩法的掌握达到了顶尖水平，甚至可以说是该领域的专家？但为什么在拿手之外领域，更容易创新呢？
新的思考：
拿我自己来讲，我很害怕在意的事情（比如期末考试）被自己搞砸，所以每次我都会按部就班复习，刷题，而不会说是这个题很难我很感兴趣但是老师说不考我还去在考前研究它。但对于自己不太在意的事我就可以放心大胆的去做，不会特别在意结果有没有达到自己的预期。所以代入此情景，既然可以称之为某领域的专家，此领域的成果对他们一定很重要，而其他自己不太擅长的领域相对也就不那么重要，所以他们可以放心大胆地去做，去创新。就算搞砸还可以来一句：“我本来就不擅长这个领域欸”。
做中学
需求阶段
我的工作：需求讨论、功能结构图绘制、博客撰写
具体讨论内容：在需求阶段，我们将全组人员划分为需求小组和原型小组，一起讨论但又各司其职。需求讨论我们主要是确定产品的定位，同时参考其他相关软件所具备的功能，进行适当筛选，最终通过发布问卷的方式，明确用户需求，真正抓住痛点。
我的收获：在此阶段，我学到了需求分析的相关内容，对NABCD各自的定义有了更明确的理解，意识到用户意见的重要性。同时学会了提炼产品功能，并使用XMind绘制功能结构图。
设计阶段
我的工作：原型讨论、前台和后台的原型设计和修改、功能模块层次图、会议记录、博客撰写、评审表制作、学习新技术
具体：原型讨论我们主要确认整个产品的配色和风格以及大致的布局，方便之后对于原型的制作。
我的收获：在此阶段，我熟悉了Mocking bot的使用，掌握了母版的使用，学会了制作轮播图，发掘了许多有关UI设计的网站。同时学习了对产品功能进行模块划分及功能模块层次图的制作。
实现阶段
我的工作：前台我的二手、任务、活动部分以及举报功能的实现，其中任务和活动只负责了结构和布局，交互由其他同学来写。后台axios跨域问题的解决以及部分博客的撰写和PPT制作。
我的收获：在此阶段，我将小程序的开发从文档落实到实战，学习了小程序的开发，加强了对生命周期函数的理解。还有第一次使用了Vant-weapp组件，减轻了不少的工作量。β阶段也对vue开发有了更深入的理解，尤其是跨域问题的解决（后面会附博客）。最重要的是前后端及时的沟通很！重！要！，因为你可能很久没解决的问题，可能只是数据库为空，或者不是你这边的问题。
测试阶段
我的工作：对自己负责的部分进行接口测试；在项目基本完工后对整个产品进行功能测试。
我的收获：在此阶段，我意识到测试的重要性，之前一直没有重视测试，最终导致α阶段的产品存在许多意想不到的bug。在β阶段的时候，我们吸取了这个教训，预留了时间来进行测试来发现bug并改正。
发布阶段
我的工作：对小程序代码进行上传和发布。协助组员进行问卷调查。（主要因为我是小程序的管理员，而体验小程序需要我的同意）
我的收获：上传很容易，但想要发布却很难。α阶段时我们审核通过却没有https开始的接口，β阶段我们拥有https，微信公众平台却审核不通过了（好苦）。导致最终只能使用体验版进行问卷调查。还有就是团队合作真的很重要！！！我们的问卷得来全靠组内成员的共同努力！！最重要的是开发一个产品或许不太难，但维护一定很难，需要定时收集意见进行产品更新维护，这样才会有人继续使用的吧。
理解和心得
个人项目
通过阅读《构建之法》对软件工程这门课有了一个初步的理解。通过个人编程的WordCount项目，让我意识到自己对java的掌握真的很差（还好不打算做后端开发），这次作业多亏了和朋友一起使用测试用例进行测试，发掘了一些本来觉得不会出错的地方，比如正则表达式判断的书写。可惜的是最终写的程序并不能测试过大的文件（比如150MB的）。而软件评测作业中，我最终选择对三个IT问答网站进行评测，发掘各自优缺点和bug，并提出自己的相应意见。这个过程中，我认识到想要之后从事软件测试相关的工作的话，要具备耐心和细心的特质，不然的话很难发现bug。
结对编程
结对编程的初体验，首先让我意识到沟通的重要性。得意于我跟队友的不断沟通所以我们不管是需求分析、原型设计、还是之后的开发过程，都觉得少了很多的麻烦，有人陪你做同一件事，并可以帮你解决疑惑并提出建议，真的很棒。结对编程前我不懂为什么要结对编程，结对编程后我真的感受到这种开发方式存在的合理性，在实践中体会到什么叫1+1>2。
团队项目
团队项目中，因为我本身是组长。首先要对所涉及的任务有个全面的了解和大致的估计，方便之后的工作划分。其次要对整个作业进度有个全局的掌握，进行适时的调整，防止最后时间太紧而出问题（比如α阶段，时间安排不合理导致后期赶工且没有能进行充分测试）。
在这个项目中，我同时也是前端开发。开发的过程中，仅仅书写好自己部分的代码是不够的，还要考虑与其他部分的跳转，交互。测试的时候也要记得真机调试，很多问题只有在真机调试才会暴露。
个人技术总结
vue-cli3开发解决axios跨域问题
概述：本篇技术博客是针对我们使用vue-cli3进行后台开发过程中使用axios进行交互时遇到的一些问题总结，主要是跨域问题的解决。