软件工程实践总结
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 |
| 这个作业要求在哪里 | 软件工程实践总结 |
| 这个作业的目标 | 回顾与总结 |
| 其他参考文献 | 《构建之法》 |
课程回顾与总结
回顾问题
曾经提出的问题
对问题新的理解
问题1
《构建之法》p204原文
p204 在表9-2种中列出项目可能会遇到的风险和类别，我对其中的技术和环境的风险类别有一些疑问，据我查询资料所了解，产品经理可能不需要了解很多的技术，那么PM要怎么判断一个项目的开发和测试工具、平台、安全性呢？还有法律法规这一风险来源，作为一个产品经理，是否还要求需要对行业的法律法规有一定的了解呢？
当时提出的问题还是因为对产品的经验不足，在当时自己的解答中也提到，公司的法务部分会与PM进行对接来弥补PM在法律层面的漏洞。结合一下实践经历，在我们组开发的STOP项目中，当我们组的羊肉串同学解决了rtmp推流问题时，我就曾经想过把道路上摄像头所拍摄的场景直接展示给用户看，如此还能弥补我们车辆识别算法准确率不高的问题，用户可以自主甄别可停车的空位。这个想法随即被我自己否定，我们的摄像头既然拍摄的是公共场景，那就有点公共摄像头的性质，那若是让任意一个使用我们小程序的用户可以随时随地查询到我们校内大部分位置的摄像头场景的话，我担心会有个人隐私，公共领域隐私的法律风险，而且我认为校方也不会允许这么做。该功能点被否定的另一原因是给每个用户推流对我们服务器的带宽要求太高。结合这个问题，既然我们做的是与摄像头、监控有关的功能，作为PM的我也对相关的法律知识和风险进行了一定了解。
问题2
《构建之法》p61原文：你发现他把时间都花在“解决（低层次）问题”上了，你想考察的“算法技能”、“C#程序设计技能”都无暇顾及。注意，这是在他认为非常精通的编程工具和编程语言中出现这样的问题。你要这样的员工么?
原文谈到一位简历上“精通Visual Studio C#”编程的面试者在被面试官要求用IDE写一段程序之后，漏洞百出。我的疑问是如何界定一个问题属于“低层次”的问题呢？首先我同意书中对面试过程中出现低级错误的观点，但我对“低层次”问题的界定仍然感到模糊，所谓的“精通”当然不该包含文中所说的“少了一个分号”、“怎么设断点”等问题，但一位程序员所谓的“精通”是否应该掌握一门语言的绝大部分内容呢？
到了大三下学期的尾声，大多数准备就业的同学已经经历了面试环节，我遇见了就几次舍友在宿舍进行在线面试的场景，还有在就业创业指导课上说的，对精通一词的定义是很严格的，简历上的精通应该是对一门语言或一个框架的全面理解，包括底层的内部知识。所以现在的我认为所谓的精通是需要掌握大部分内容的。
问题3
《构建之法》p351原文：大家听了很多创新者的故事，有些人想，他们真了不起，第一个想出了这些美妙的想法，要是我早生几十年,也第一个实现那些想法就好了。其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。
在对软件行业有了更深入的了解过后，我认同了作者的想法， 同意大部分成功的创新者都不是先行者。我意识到一个成功的产品有一个与众不同的点子仅仅是成功的因素之一，其他还有如技术、市场、需求、运营、推广等众多因素，只能说作为先行者很大概率能增加成功的几率，但一定不是成功先决条件。
问题4
《构建之法》p85原文：在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。
首先文中的结对编程与我原先预先的结对编程并不相同，我本来认为结对编程就是两个人组成一个团队完成任务，但看到文中的“同一台电脑，同一个显示器，同一个键盘”，我产生了疑问，这种方式是否会降低一个团队的效率呢？两个人做同样的事情，文中谈到的两个都对代码有着最强的熟悉感，能够比其他审核人员更快的找到问题所在，这点我完全同意，但这种方式是否是对开发人员的浪费呢？
在写下这个问题时我还没有经历过一次结对编程，在实践过后我切实感受到了结对编程的好处，比如两个人一起编程之后，降低了所写程序的错误率，并且双方都意识到如果只自己独立变成的话都会犯下没有意识到的逻辑错误等问题。所以我意识到在合适的环境下，合理的结对编程是能够切实提高两人乃至团队的效率的。
问题5
《构建之法》P215原文：如果用户有不同的安全需求，切记要定义不同的角色来适应这些需求。如下面的例子:受欢迎的典型用户—指那些按设计者的期望使用系统的用户，如“网站的购物者”;
不受欢迎的典型用户——指那些有不正当目的的用户,如在一个房地产业主论坛中滥发房屋中介广告的用户，这些用户也许在别的系统中（如房屋中介论坛)是受欢迎的。
书中说到用户可能有不同的需求，同时还要定义不受欢迎的典型用户，但下面又说到”我们的软件不是为所有人服务的“，我认为这中间有一定的矛盾，既然要定义用户，是否应该包含所有的用户使用可能？
这里我认为对用户的模拟用户的全面性是很有必要的，特别是系统安全性方面更应该模拟出有多种需求的用户。在原文中说到的“我们的软件不是为所有人服务的”，我的看法是在功能点上，我们一定有对应需求的典型用户，也有可能遇到不需要使用我们功能点但却误使用我们系统的用户，这也是我们需要模拟到的典型用户。比如在STOP项目中，我们定义的用户是有电动车停车困扰的人，首先定位的在校大学生，其次可能是一些电动车停车困难的小区居民，两者的共同点就是需要使用电动车，我们考虑到了如果一个没有电动车的人有没有可能使用我们的小程序，这类用户就是“不是为其服务的用户”，这也是我们应该模拟到的用户。
做中学
需求
在需求分析阶段，我认为自己锻炼到了沟通能力。在团队作业的需求分析阶段，我们队是有两名PM的，在我与另一名PM分析明确需求点功能点时，有点类似结对编程，双方各自提出自己的意见，做出初步的风险分析，让我意识到有效的沟通是一件很美好的事情，学会了更全面的思考问题，能够将自己代入用户来思考。还有就是锻炼了自己原型设计的能力，强化了自己对原型设计工具的使用。
设计
因为我们的产品是微信小程序类型，所以需要满足微信的诸多限制，这就需要我们团队在设计接口时去阅读微信小程序官方的接口文档，因为微信的接口更新迭代很快，很多搜出来的教程上的用法已经被废弃，才意识到官方文档的重要性。比如我们就在实现阶段才发现原本设计的一个接口由于微信官方新推出的政策导致原接口废弃，我们不得不修改接口设计。
实现
最大的收获就是学习了新的框架uni-app，因为我在寒假的时候就有学习跨平台开发框架的想法，本来是想学习Inoic，正好借着团队需要学习了功能更加强大的uni-app。巩固了自己前端的知识，学习了新的UI框架uview。
测试
学会了根据各种机型来测试自己的响应式布局。锻炼了自己查找问题的能力，利用真机调试等方式，站在用户的角度思考问题，找到页面的不合理性，将其修改得更加合理。还学习到了自动化测试工具的使用，学习到了性能测试和压力测试的相关知识。
发布
结合我们遇到的问题，因为微信小程序不同于web随时部署就能使用，需要微信官方审核通过才能正式上线。微信给予个人开发者每个小程序每年一次加急审核的机会（2小时内审核，正常审核需要一天左右），在α冲刺答辩前夕，我们预留了两天来进行审核缓冲，因为是第一次发布小程序不知道微信审核的效率（官方写的是7天时间审核，实际是工作日1天就能审核完成），所以第一次发布就用掉了唯一的加急机会。造成的结果就是上线之后我们自己测试发现了一堆bug，还有一些比较严重的bug，我们只能加急修复之后重新发布第二版，所幸还是在答辩那天中午审核成功。在这个阶段学习到了测试应该足够全面再正式发布，同时要留足足够的时间来进行缓冲。正式学习到了这些，在β冲刺的发布阶段我们会显得更加得心应手。
理解与心得
个人项目
本学期的个人项目主要是是WordCount编程部分，最大的收获大概就是对于测试的充分性，以及锻炼了自己对需求的理解能力。出现的问题就是仅仅实现了功能并没有进行足够充分的测试就草率地去优化性能，结果就是性能足够但是因为准确率太低根本就没有性能分。最后找到的原因是自己把题目的理解错了，如果是在完整的项目开发中，理解错需求在后期的修改成本是超级巨大的，所以这也让我在后面的项目中对题目和需求的分析会更加仔细和细心。
结对编程
结对编程是我第一次进行比较完整的原型设计，算是入门了Axure的使用，也学会了模仿一写大厂的UI风格。在实现阶段巩固了对Vue框架的知识，因为负责后端的对友的编程能力很强，所以在联调是基本是他在等我前端的页面，而我现在仍然清晰得记得有一些bug就卡了一整天，而这些大都是自己的知识储备不足导致了。我认为这次编程踩过的坑我是非常宝贵的财富，在结对编程后再次前端开发时，很少出现能够卡超过1天的bug，因为好多坑都在结对编程时踩过了。
团队项目
在几次团队编程中我印象最深的是极限编程的那一天，那是我在学习完vue的理论知识后第一次实践编程，那天给我的感觉就像是幼儿园的小朋友在大家中间，什么都不会一路磕磕绊绊，写两行代码就需要百度一下，感觉自己那天作为短板拖队友们的后腿还挺折磨自己的，所幸我们团队还是比较不错得完成了任务，感谢我的队友们。后来的两次冲刺编程，因为对vue的使用越发熟练，一路走来也算得心应手，也不会再拖团队后腿。心得体会就是一个团队的高效率运转会让每个人都工作得十分愉悦，每个成员都很努力地做好所属的工作，并且会与有疑问的成员一起思考。
个人技术总结
博客地址
概述
在uni-app框架中使用官方的动画组件uni-transition在微信小程序上实现底部浮层，因为关于uni-transition的用法比较少，所以觉得可以写一篇博客分享一下。
