| 这个作业属于哪个课程 | 2020春|W班 (福州大学) |
|---|---|
| 这个作业的要求在哪里 | 个人作业——软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 对这段时间的学习和实践所得做一个总结 |
| 作业正文 | 下文 |
| 其他参考文献 | 无 |
一、回望
（1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强软件工程专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
之前真的很少编程，直到软工实践开始我才觉得自己是这个专业的学生。通过这么多次的软工实践，我在软件工程方面的能力以肉眼可见的速度增长着，第一次知道开发不仅仅是写代码，还需要需求分析、原型设计、系统及接口设计、数据库设计、编码、测试、交付验收等环节以及alpha和beta版本的开发。第一次知道如何制作原型，同时感叹它的伟大，一个好的原型能让你在开发的路上少走弯路。第一次知道代码管理工具，同时也感受其带给团队开发的便捷。许许多多的第一次……不仅提升了自己对软件工程的认知，还提高了实际的动手操作能力。虽然每次作业我都尽力完成，但是和大佬们相比我仍有很多不足。代码质量、代码结构、以及代码风格上都有这样那样的不足，常常急于动手没有做好规划，写代码想到哪写到哪。原因大部分归咎于习惯不好，这些都是需要我在以后的工作学习中去注意的点，要想得心应手打代码的话，还是路漫漫其修远兮……
（2）你在第一次作业的个人简历中制定的这门课程结束后，你预期你将增长的能力、技术、技能；和你针对你的目标绘制的学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？
感觉有点跑偏了，原先是想在web端发展，没想到后来做了个移动端。说起来惭愧，一开始抱着挺大的热情想好好规划一下这学期。直到一个又一个软工实践作业接踵而至，我的梦想完全破灭了。其实每次做作业都蛮痛苦的，看作业要求博客我只觉得脑子里嗡嗡的，要求又多又杂，感觉自己就是个无头苍蝇。软工实践占用了不少课余时间，团队开发阶段基本每天都在编码，没有什么闲暇时间。每次交完作业的那一刻不知道多快乐，但我知道很快又有新任务了，完成作业已经有点吃力，所以也没有当初那么热情，我的计划就这么一次次搁浅了。（我感觉还是兴不兴趣的问题，为啥我一看代码就头疼，倦了）但也不是完全没有收获，经过一学期的学习以及这两次的训练我已经具备一定的审美能力和基础的美工操作能力；在与团队成员的沟通合作上也得到了很好的锻炼；对于安卓前端开发的技术、技巧也有了更深入的了解。
（3）请总结这门课程的实践总结和给你带来的提升，包括以下内容：
统计一下，你在这门软件工程实践中，一共完成了多少行的代码；
大概9k多行。
软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业名称 | 完成的代码量/行 | 花费的时间/h |
|---|---|---|
| 准备篇 | 0 | 3.5 |
| 热身篇——疫情统计 | 650+ | 30.8 |
| 结对第一次—某次疫情统计可视化（原型设计） | 850+ | 17.5 |
| 团队作业第一次——种子队伍选拔和团队展示 | 0 | 5.6 |
| 结对第二次作业——某次疫情统计可视化的实现 | 2000+ | 30 |
| 团队作业第二次—团队Github实战训练 | 500+ | 8.4 |
| 团队作业第三次—项目需求分析 | 0 | 8 |
| 团队作业第四次—项目系统设计与数据库设计 | 0 | 10.5 |
| 个人作业——软件评测 | 0 | 10 |
| 团队作业第五次——站立式会议+alpha冲刺 | 2000+ | 10*6 |
| 团队作业第六次——beta冲刺+事后诸葛亮 | 3000+ | 7*7 |
| 个人作业——软件工程实践总结&个人技术博客 | 0 | 10 |
哪一次作业让你印象最深刻？为什么？
结对第二次作业。说多了都是泪，第一次结对合作，第一次学爬虫，第一次使用嵌入式数据库……以及对一些概念的模糊，原因主要在于前后端没有对接清楚。导致最终整合的时候问题巨多。交作业的前一晚熬夜拼命调试改bug，差点因为交不上作业而崩溃了。
累计花了多少个小时在软工实践上？平均每周花多少个小时？
累计花了240+个小时在软工实践上，平均每周240/17=14+个小时
学习和使用的新软件；
IntelliJ IDEA:用来编码
Axure RP 9、MockingBot：原型制作
XMind：思维导图绘制
MuMu模拟器：安卓模拟器应用程序
Hbuilder X：一款支持HTML5的Web开发IDE
学习和使用的新工具；
StarUML：UML开发工具
Postman：接口测试工具
ER Win：数据建模工具
junit：单元测试工具
github：代码管理工具
学习和掌握的新语言、新平台；
markdown语言：学会了写博文，运用md对博文进行排版
博客园平台：看到了很多技术大牛的文章，受益颇多
Github平台：进行项目的托管，有效的提高协作开发的效率
学习和掌握的新方法；
用爬虫爬取数据、单元测试方法、代码性能测试、代码覆盖率测试
工程能力的提升；
复杂代码编程能力，项目设计能力，代码重构能力，代码阅读能力
团队合作上的提升；
从一开始的拘谨，到后来的互帮互助，我和团队成员之间的交流渐渐多了起来。从alpha冲刺的跌跌撞撞，到beta冲刺的游刃有余，离不开团队成员对我的帮助，我才能一路走到了现在。对于分配到手的任务，从一开始的不知所措，与后端沟通之间出现的摩擦，到后面渐渐走上了正轨，前后端完美配合，这才是我理想中的合作。
其他方面的提升；
软件开发能力：从一开始对软件开发的知之甚少，到经历并完全熟悉软件开发的整个过程；
抗压能力、责任心：因为是团队协作，自己如果没有做好很有可能会影响到别人的工作，所以还是蛮担心的。为了按照进度完成好自己负责的模块，有那么几天我凌晨才睡，还有在deadline将至时突然出现的bug真的让我心惊胆战，只能先稳住自己的心态，好在最后都一个个解决了；
交流能力：自己平时比较寡言，不是很善于表达。与不同团队成员之间的交流促进了工作的进展，也锻炼了自己的交流能力。
计划、总结能力：没有计划总结的习惯，总是匆匆开始，然后拍拍屁股了事。站立式会议让我学会了对自己每日的成果做总结，以及每天开始之前做好规划。我觉得这也是一种很好的学习方法。
二、团队总结
1.你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？
我担任前端角色，并完成了该角色的任务。没有适不适合，只有你想不想做好。之前我异想天开的认为前端只要写写显示界面就可以，有了团队开发的经验，我觉得前端人员花费的时间和精力远远不止这些。写html页面是很容易纠错，但是排版什么的的确要花费一番功夫，要是有什么可视化的工具就好了（可能已经有了？？）。但在写js时稍微不留神就会出现这样那样的错误，你必须要考虑的足够周到，要有全局意识，代码风格要好（改起bug来才不那么费劲），这个方面还是要慢慢积累，有了经验下次就会注意起来。
2、 如果你是组员，你觉得你的组长分工安排是否合理？你对组长的选举有什么建议？
大部分是合理的，有时候也会出现分配不均，我觉得这主要取决于任务难度以及个人能力，分工安排确实是一项不简单的工作。我认为民主选举挺好的。
3、 你这学期经历过换组吗？你对换组有哪些看法？谈谈你在这个过程中的感受。
没经历过0.0。其实我没有什么太大的体会，因为只要把任务交接清楚，自己的工作做好，我认为换组是没什么太大影响的。但对于被换组的同学来说，的确会增加负担，你可能要学习新技术来融入新的团队，也相当于是一种考验吧。以及对于组长来说，可能要重新划分任务结构，帮助新组员融入这个团队，辛苦幸苦。
4、 分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建之法》第17章 人、绩效和职业道德）
《构建之法》里面提到的关于团队发展的阶段共有四个，分别是：萌芽阶段、磨合阶段、规范阶段、创造阶段。
1.萌芽阶段
刚组好队创建了一个群聊，大家有意无意的在水群，找寻一下存在感。有些茫然没有方向，不知道接下来等待着我们的将是什么样的考验。一切都听小组长的指挥吧~~
2.磨合阶段
经常开会，每个人都有自己的独到见解。其他人则会在此基础上认真思考，提出自己的观点。一个敢说，一个敢评。当然偶尔也会有意见不合的时候，这时候我们的组长大大出马，或做出最后的决断或发起一个投票倾向于大多数成员的选择。
3.规范阶段
每个人都有自己的编码风格、习惯。为了让团队协作发挥最大的作用，我们事先约定好了编码规范并统一了开发工具。经过了alpha冲刺，大家都很认可团队的工作流程和工作方式，接下来组长主要扮演促成者的角色。同时lhf同学也担任了前端的领导者，为前端提供方向和指导。
4.创造阶段
就我个人感觉来说，我的团队已经达到创造阶段了。我们的注意力都集中到实现目标上，最终让我们的产品问世。团队成员间相互支持，相互依赖，之前我是一个不喜欢问问题，不喜欢麻烦别人的人。在这次开发中，其实我有很多问题都是在队友们的帮助下解决的，一方面我虚心请教，一方面他们也乐于解答，这样做团队的效率达到了巅峰。
三、人月神话
1、怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？请在随笔中用数据证明上述内容或侧重选择之一。
（1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
产品七日记忆为针对生活在当下快餐文化影响下的青年人设计的匿名交流软件。当代许多青年生活在众多的压力之下，而那颗渴望美好的心在与现实对比的强烈反差下无处寄托。我们的产品正是为解决这一痛点而诞生的。七日记忆旨在抛开现实加之的各种身份，在茫茫网络中找寻志趣相投或者臭味相投的朋友。又或者不在交友，只希望领略世间的种种人、事、物，然后事了拂衣去的“渣”男、“渣”女。
（2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
我们团队有着完整规划性的开发流程，包括需求分析、设计、实现、发布，至于维护可能还没达到真正意义上的维护，只是在用户反馈过后修正少量的bug。我们采用github来进行项目的托管和团队的协同开发，在每次冲刺开始之前都做了详尽的规划，并按时发布了alpha和beta两个版本的软件。熬夜是有的，但不是临时的；大牛也是有的，但不是一夫当关的。每个团队成员都各司其职，很好的完成了自己的任务。
（3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
整个系统项目托管在开源的github平台上面。此外，项目相关的文档也均汇总在团队博客里详见，可以根据文档内容对我们的应用有一个全面的了解。
项目后端源码
项目前端源码
项目系统设计与数据库设计
源码及文档附上，代码是可以编译的！task应该在博客里面已经列的很清楚了，倒是bug没有详细的记录，改一个是一个。
2、写下属于你自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析，文字部分字数要求在100字以上，可以使用你自己喜欢的方式表达（如图文结合、视频）..
任何事都没有表面看起来那么简单。（一个简单的html界面，很可能是前端人员千辛万苦排版排出来的，所以请不要轻易否定我们的努力）
所有事都会比你预计的时间长。（今天安排做两件事，改前一天的bug和写界面，而时间往往只够做前面那件，所以无可避免的要熬夜了（呵呵哒，写代码一时爽，改bug火葬场））
会出错的总会出错。（写图片上传部分代码的时候，明明前一天写好了代码也测试过了，第二天还是出错了。继续改好了代码，在自己手机上运行好好的，又被队友告知他不能使用，真的是无奈。事实证明，就是代码有bug...该来的总会来，你别想逃）
如果事情有变坏的可能，不管这种可能性有多小，它总会发生。（在模拟器上已经测到不想再测了，打包成apk之后，什么毛病都来了，真的心态崩了，这也算一种可能性吗？还是必然？好在不是什么大问题，几经修改就搞定了）
四、建议
对下一届同学的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？请写下你对后来人的期许。
计划计划计划一定要做好计划，凡事都是如此。每一天，每一学期，每一学年，都要做一个明确的计划。学过的东西要捡起来，而不是学了就完事了，过几天就忘。
对于软工实践课程，你有哪些建议？
我希望就是在大一刚入学的时候就能接触到这样的实践课，而不是大三下的突然出现，着实把我吓了一跳。在这之前除了作业，我几乎没有怎么花时间编程。突然出现这样一门课，我第一反应就是工作量好大，对于一个没有动手能力的人来说确实有点困难（是我的锅）。所以就是希望能有一个循序渐进的过程，这样三年积累下来，也不至于现在这么菜……哎
对于助教工作，你有哪些建议？
不情之请，如果能为基础不太好的同学多提供点帮助就好了~~（比如我这个菜鸡）
对于自己今后，你有哪些建言？
也许你在这里并不是很出众，但是不要灰心啊！希望你早日找到自己的那份归属感，不要随波逐流，自己喜欢才好，然后努力地让自己闪闪发光。
五、个人技术总结
前端上传base64图片到七牛云总结
概述：这篇文章主要使用的是七牛云提供的对象存储服务来存储图片。
六* 阅读笔记
参考论文文献：
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
摘要 ：开放源码软件开发的支持者认为，与传统的封闭模型相比，使用这种模型产生更好的软件。然而，很少有经验证据支持这些要求。在本文中，我们提出的试点案例研究的结果，目的是：（一）了解结构质量的影响；（二）计算出的结构质量分析的代码由开源风格开发交付的好处。为此，我们测量了100个应用程序编写的Linux的质量特性，使用的软件测量工具，并与工业标准，该工具所提出的结果进行了比较。本案例研究的另一个目标是调查的问题，在开源的模块化，这种特性被认为是至关重要的开源这种软件开发类型的支持者。我们有经验评估的应用程序组件的大小和交付的质量通过用户满意度测量之间的关系。我们已经确定，在一定程度上，应用程序的平均组件大小与此应用程序的用户满意度呈负相关。
开源已经成功地生产了一些令人印象深刻的产品，比如Linux操作系统，开源软件系统的进化以极其迅速的方式发生，比典型的“封闭”项目的进化速度快得多。但是任何事物都有两面性，开源正在向传统的软件开发行业提出一个重要的挑战。一个问题是开源开发过程没有很好的定义，项目通常由最初的创造者指导，他负责管理系统的一切活动（如发布新版本、配置管理）。然而有一些关键的开发活动，如系统测试和文档却被忽略了，需求由程序员自己定义。由此很容易看出，开源哲学既有优点也有缺点。
文中提到他们使用了一套能够自动执行代码测量和与用户定义的支持语法标准进行比较的综合工具，Logiscope。并根据四个基本标准进行评估，即可测试性、简单性、可读性和自描述性，使用测量值。而我认为其中最重要的就是可读性，github上有很多开源代码，但是我真的看不懂？？可能大佬们的脑回路跟我就是不一样。虽然我自己写的代码质量也不是很好，至少我在一些关键的位置上还是会写注释的，一来怕自己忘记，二来也帮助别人看得懂。以前写代码从来不考虑代码结构、代码的可扩展性和可移植性这些，想到哪里写到哪里，写出来的代码质量当然不高咯。 说到底还是没有这个习惯，只能在一次次的实践中慢慢改正了！