软件工程实践总结
“做中学”最佳实践
| 这个作业属于哪个课程 | 2021春软件工程实践|S班 |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 回顾问题、总结阶段收获、谈谈心得理解 |
| 其他参考文献 | 《构建之法》 |
第一部分 课程回顾与总结
问题所在作业链接：软工实践寒假作业（2/2）
1问题回顾
1.1问题一
1.在阅读《构建之法》3.1 个人能力的衡量与发展 中的
初级软件工程师如何成长呢？我认为有下面几种成长
......
3.对通用的软件设计思想和软件工程思想的理解。这一方面就比较虚，什么是好的软件设计思想？什么是好的软件工程思想？一个工程师开了博客，转发了很多别人的文章，这算有思想么？另一个工程师坚持做任何设计都要画UML图，这算有思想么？
我有一个问题：学习了软件设计思想和软件工程思想的知识之后，显然并不是任何时候都要死板的按照所学的知识进行开发设计，软件思想的运用边界在哪里？何时该使用，何时不该使用？
尝试解答：从这次的软件工程实践来看，软件思想的在整个软件开发过程中都有体现。软件思想的运用并没有边界，其实在平时编程的时候不管是做算法题还是做大小项目，其中都有软件思想体现在其中。至于何时使用与不使用的问题，我认为软件思想是一种思想，并不是方法、技巧更不是技术，并没有具体的“使用”一说，更多的是对工程师的指导，是刻在脑中的，就像是一个工程师的“世界观”指导着软件开发的“方法论”那样。
继续分析：学习完《软件工程》课程，也即将圆满结束《软件工程实践》课程，我所感受到的软件思想一直都是比较抽象的存在，好在经过理论学习，并经过亲手实践，还是有能够有自己的理解的。邹欣老师说的没错，需要把软件思想运用到实际中才是有用的。然而比较无奈的一点是，软件思想的存在是为了指导做好软件的，但是有了好的软件思想并不能百分百保证有好的软件，好的软件思想是做出好软件的保证，是必要条件而不是充分条件。这个事实似乎会打击人的积极性，实际上软件思想始终在纠错，克服人的惰性，对于有责任感的工程师，必要条件也是必须要达到的条件，要始终记在脑中。
1.2问题二
2.在阅读《构建之法》3.2 软件工程师的职业发展 中的
21世纪以来，中国大陆每年招收六百万大学生，其中的百分之十是在学习各种IT相关的专业（计算机科学与技术、计算机工程、计算机软件、软件工程、管理信息系统等）。扣除读研究生（最终大部分也会走上工作岗位）、出国等分流，同时考虑到培训机构给就业市场贡献的大量劳动力，每年大致有四十万到六十万左右的“职业软件工程师”进入工作岗位。
我有一个问题：科班出身的软件工程师和非科班出身的有哪些区别？如何在就业市场就业压力如此大的情况下发挥科班出身的优势？
尝试解答：在先前的问题思考中，提到了一个知乎上的回答：
两者之间的差距在于非科班缺少根基，他们会去学习那些更有“价值”的东西，而忽略了基础。
从我的角度来看，科班出身的软件工程师确实会更加注重基础的学习和积累，毕竟课程设计里面会包含《计算机网络》《操作系统》等较为基础，学起来要沉得住气、能够形成自己的体系，却又不太容易的学科。最近也有在复习这些知识，复习之后会发现有些知识拿去解释开发中遇到的问题是那么的合理，原来都已经有了答案。我想，这应该就是科班和非科班的区别，也是科班出生的优势所在。
继续分析：在导论课上听程老师说：“干我们这一行的太难了，学生物工程的能当码农，学土木工程的也能当码农，你凭什么能保得住你的饭碗？“现在来看，程序员这一行的竞争已经水深火热，水平一般在这一行走得会很艰难。我们也应该看到自己的弱势，非科班的程序员更加注重有价值的，也就会更偏重于编码能力的培养，而大学生由于培养计划，用于学习、锻炼编码能力的机会比较少，这是我们的劣势所在。要成为一名有竞争力的，既要有扎实的计算机基础，也要有成熟的编码能力，前路漫漫，还需继续努力。
1.3问题三
3.在阅读《构建之法》10.1 典型用户和典型场景 中的
阿超：所谓“Person-a”，就是典型用户，吴石头/石头他爹就是我们系统的两个典型用户。我们的确需要了解我们软件系统的用户（不是公司的商业客户），那么，什么是典型用户？在产品开发的过程中，我们经常需要描述一组典型的用户。以前大家通常是以一些抽象的名词来表示用户，如“家用电脑初学者”、“经验丰富的系统管理员”，现在我们建议用一个“典型用户”来代表。典型用户不再是一个抽象的概念，而应该是一个活生生的人物。典型用户一般有哪些特性？一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
我有一个问题：如何确定软件系统的典型用户？
尝试解答：在软件测评的作业中，通过实践体验了一次典型提炼描述过程：收集可能用户的相关数据并对数据进行分类，从分类好的数据中提取出用户的特点，将这些特点放到用户身上，生成各个典型用户。大致过程和之前从网上查找的资料一致，体验之后对整个过程有了更清晰的理解。
继续分析：自己做过典型用户的提炼，感觉自己并没有做的很好，主要是数据的收集和分类，因为不是专业的分析机构，也没有和相关机构合作的机会，需要的信息只能通过网络查找，但是网络上的数据很难保证权威性，有时相同的统计内容给的数据是不同的，就拿中国的程序员数量来说，各种数据五花八门，最后只能根据其他数据的辅助，选一个比较靠谱的数字作为结果。可能通过其他数据的辅助来筛选数据是一个比较好的方法，但不管用什么方法，都应该可以保证收集到的数据是可靠的、有效的。
提出新问题：没有别的方法了吗？有时候数据并不是那么好收集，有别的方法确定典型用户吗？
1.4问题四
4.在阅读《构建之法》6.1.2 敏捷流程概述 中的
冲刺期间，每天要开一个每日例会，团队成员大多站着开会，所以又称每日立会。大家依次报告：
我昨天做了啥
我今天要做啥
我碰到了哪些问题
每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。
我有一个问题：如果团队成员在每日例会中迫于压力、碍于面子对自己的实际情况撒了谎，可能会打乱整个流程，该如何处理？
尝试解答：通过团队作业两个阶段的每日立会，我的体验是这个问题出现还挺难的，甚至这个问题根本就不成立（可能是我们组的Scrum Master做的太好了，导致像我这种拖延症也能老老实实的跟着进度走）。因为是每日立会，每天都有，那对整个项目来说，团队一天的工作量不会太大，而每个人的的任务又是对每日任务的细分，粒度是很小的，还不至于将整个计划打乱；此外，每个人都在会上作了计划，有了计划之后，拖延的情况会有所缓解；而且，项目管理工具辅助让每个人的工作进度保持透明，撒谎是很难的。即使是排除了以上因素，导致了任务的延期，因为任务的粒度比较小，还是能够及时补上的。而打乱开发流程，很难出现，但是出现的话，也因为有相关的任务记录，可以再分配出去，补起来还是比较容易的，但是对“捣乱者”的惩罚是必不可少的。
继续分析：我觉得每日立会的思想很不错，将每个人的工作细分到比较小的粒度，降低个人因素对项目造成的风险。但是要细分到什么粒度呢，这个就有点难了。在我们小组中是按照每个阶段计划内的功能分解成更小的功能，再根据可能需要的时间，对小功能再进行划分。这是一个不错的划分方法，在团队开发中，一般都能够按时完成，也不会出现任务太少导致摸鱼的出现。
1.5问题五
5.在阅读《构建之法》16.1.2 迷思之二：大家都喜欢创新 中的
如果使用QWERTY键盘，那么只有10%的英语单词能在手指不离开键盘中列的情况下敲出来。但是如果使用Dvorak键盘布局，你可以在键盘中列打出60%的常用单词！这样会减轻手指和相关肌肉的负担，减少劳损，同时加快打字速度。......但是，长期以来，人们已经习惯了QWERTY键盘，所谓先入为主。
我有一个问题：当前中国人最离不开的软件微信，是否正在成为中国的“QWERTY键盘”？这样的软件存在是否会打击行业创新的积极性呢？
尝试解答：现在来看，我依旧不能承认微信正在成为中国的“QWERTY键盘”，微信依旧在改变，即使存在一些痛点，但我也看到了微信的改变，比如在手机端以外朋友圈等功能的拓展，可以看到微信并不是一成不变的。而对行业积极性问题，可以从视频号这个功能看到，微信把短视频引入，获得了不少的视频号用户，对于抖音、快手等短视频平台造成了不小的影响，但是抖音的先发优势还是微信无法动摇的：实打实的短视频用户，营销策略，是微信得不到的。核心的技术微信并没有学到家。冲击是有的，但是有价值的软件被注意只是时间问题。
继续分析：我认为其实想微信这样的软件，面临的压力还是不小的，因为用户基数大，做出的变更影响到的用户很多，而且难免用户会抱怨这种变化，人数还不少，比如我就不用微信的视频号，但是微信把视频号塞给了每一个用户，还在各处推广，导致公众号文章中的视频嵌入方式多种多样，是视频号视频的还要跳转视频号页面，割裂了阅读体验。这种变更往往需要大量的调研，导致变更可能会跟不上热度，影响产品开发的积极性。但是难能可贵的是，至少在目前，微信还是敢于去改变的。
提出新问题：微信加入视频号功能可以一味的否定它就不是创新了吗？微信这样已经不可或缺的软件，我们还在期待它能带来什么样的创新？
2阶段收获
2.1需求阶段
需求阶段，我主要和其他三位队友负责团队作业的用例的提取、用例图的构建、类图和数据库的初步设计。在这个阶段最大的收获就是明确了需求阶段的主要任务。因为是第一次这样完整的体验一次做软件的过程，即使从书上学到了不少理论知识，但是实践的时候还是晕乎乎的。刚开始并不知道我们需求阶段要做些什么，以为在项目NABCD分析的那一个阶段就已经进行的差不多了，就以为需求阶段进一步深入要做用例图、类图、数据库设计，到最后成果展示的时候，老师就提醒我们在需求分析阶段是没有类图产出的，即使有也只是很抽象的类图，不会和具体的内部设计挂钩。这个时候我们才意识到我们的工作超前了。而且老师还指出我们的用例图设计的太简单了，只有一层的关系，但是在《面向对象分析与设计》这门课上，老师的要求是没有复用的用例就没有必要单独画出用例，和单老师说的有点冲突，但是最后我们还是对用例图进行了修改，将重复的用例提取出来，丰富了用例图的层次。此外，我还学习到了问卷对需求分析的重要性。这一个阶段也为之后的阶段思考要做什么起到了警示作用。
2.2设计阶段
在团队作业中，我的主要工作是和另外两个同学一起在上一个阶段的基础上细化类图的设计，细化数据库设计，画出ER图，设计数据库表，并制定接口文档。在这个阶段我最大的收获是学会了画ER图。ER图在数据库这门课的学习中ER图只在概念设计阶段中出现过，因为主要是概念，而且画图比较麻烦，并没有加以重视。而在设计阶段，我和其他两位同学分工完成了ER图的设计，亲手实践，设计出了比较完善且庞大的数据库概念模型，对具体的数据库设计打下基础。在之后的开发流程中，基本上没有修改过数据库表，足见这一阶段ER图的重要性。
2.3实现阶段
实现阶段收获最大的就是学会了Java Web后端框架。到课程结束，不管是结对作业时学会的SpringBoot+SpringMVC+JPA，还是团队作业时学会的SpringBoot+SpringMVC+MyBatis Plus的基本用法都能够掌握。现在回想那段零基础学习的日子，特别是结对作业的那一周，焦虑得不行，到处找学习资料，曾经一度想放弃，打算用Web程序设计课上学的PHP手撕后端，但又觉得不太现实。最后学会使用SpringBoot+SpringMVC+JPA，真香。这不仅仅是对技术上的锻炼，更是对学习能力的一次大考验，是我整个课程中最大的收获之一。
2.4测试阶段
测试阶段最大的收获是学会了单元测试，并使用JUnit和JProfiler进行辅助测试和优化。在之前写代码的时候并没有测试的意识，只是用自己觉得可疑的数据测试一下就算通过了。在学这门课的时候才真正接触到并学会了单元测试的方法。在团队作业的时候，《软件质量与测试》这门课也正好讲完白盒测试，就在团队项目的作业中实践了一下，也算是“做中学”在另一门课程中的实践吧。
2.5发布阶段
发布阶段也收获了一个很重要的技能——在服务器上部署前后端项目。因为结对作业的时候前端的进度还比较赶，就由我来先学着部署前后端项目。记得那天晚上因为学nginx部署前端，到了晚上两点多才睡，虽然这个技术是在编码和软件工程之外的，但是工具的使用还是必不可少的。部署完看到自己搭建的论文系统网站还是很有成就感的，学到的技术还可以为以后搭建网站打下基础。
3心得理解
作为目前为止时间跨度最长（从寒假到暑假）、占用时间最多的一门课程，《软件工程实践》带给我的收获也没让我失望。每一个阶段从发布作业时的茫然，到提交作业时的自信，这之间的过程都是汗水浇灌，能力野蛮生长的过程。相信每个人都能从中得到很多的锻炼。就我而言，从寒假作业中的撰写博客、绘制思维导图、使用GitHub、单元测试、使用性能检测工具，到结对作业的使用原型工具、学习Spring框架、部署项目，再到团队作业一起编写各种文档、使用项目管理工具，这一系列技术上取得的学习成果已经十分丰硕，而非技术层面的感悟更让我印象深刻。
1.分
分而治之。分解的思想在每一次作业中都有体现。个人编程作业，不同的功能划分为不同的模块来写；结对作业，作业的需求需要掰开来理解，原型的实现要分模块来搭建；团队作业，一整个大的计划需要分解为符合一天工作量的小计划，再分解为成员的计划逐步完成。在课程中遇到的很多问题都是很难一步到位的，分解是解决大难题的好方法，很庆幸在个人编程作业开始就用到了分解的思想。分解让人能够更加清晰的看待内部的问题，而且对分解的每个部分作出具体的要求，往往能够保证整体的质量。而分解又是困难的，对于分解的粒度往往难以把控，需要根据经验和实际情况的指导，进行合理的分解。
2.合
合作。大多数软件背后都不是一个人在战斗，不能不承认有完完全全的独立开发者，但是这样的人少之又少。在这次的课程中，我看到了合作能够带来的将不可能变为可能的力量。在结对作业中，对需求的理解需要两个人互相支撑，对原型的实现需要两人合作完成；团队作业更是不用多说，每一个部分都是需要成员来共同完成的。合作带来的成果可以是超出想象力的，看到论文系统，体验了β冲刺后的《逐梦校友圈》，真的非常惊艳，很难想像自己竟然也参与其中，又想了想，自己好像还挺重要的。没有合作的话，完成这样的系统，我需要学习更多的技术，学技术还好，审美这些东西是很难去学习的可能永远都是学不会的。合作让团队能够集合各种优点，特长，带到项目中。
3.坚持与计划
将这两个放在一起，是因为放在一起才是有效的。给我印象比较深的是团队作业的两次冲刺，每次冲刺开始都会有一个计划，每天在PM的监督下坚持完成任务，最后成品效果都很不错；而自己的技术学习计划，有计划没有坚持，到现在并没有很好地按照进度学到应该学得的技术。没有坚持的计划是空谈，而没有计划的坚持是盲目。坚持与计划是项目圆满完成的保证。
第二部分 个人技术部分
第一次作业“准备篇”中的计划，正如前文所说，没有坚持下来，进度上有些落后，现在还停留在5月份的动画学习阶段。
我在团队开发中担任了后端的开发角色，解决了查询优化，图片传输等问题，从开发中学到了后端SpringBoot+SpringMVC+JPA，SpringBoot+SpringMVC+MyBatis Plus框架的使用，以及一系列开发工具的使用。
在个人技术总结中，主要谈谈后端接收微信小程序图片上传问题使用到的技术。
链接：
个人技术总结
概述：一种后端使用JSON接收前端上传图片的技术，适用于前端不便使用表单提交文件的情况，且该方法相较于其他传输方法有适用平台广、更符合RESTful思想的特点，难点在于对图片信息进行Base64格式的编解码。
