标签：选择 谷歌浏览器 自己 出现 硬件 控制 信息 决定 后端
为大众提供一个匿名聊天、倾诉心事的场所。定义为匿名性强、不以交友为目的的聊天软件。针对传播不法、违规信息的用户 及 恶意举报、进行不符合道德交流的行为 制定处理方式。
基本达到目标。
未完成的功能点：
原计划中，客户端是有广告页的，但是实现时发现我们还没达到商业化软件的地步，就没去实现。
有修正功能要点的模块:
原计划中，“漂流的记忆”（漂流瓶）功能，是有点类似“随机接力填写内容”的漂流瓶功能，但是因为讨论研究不足，后来模块实现时变成了传统的漂流瓶功能，最后应急修改了一些，但还是不少地方与初衷不符。
附加功能：
原计划中，是预计不支持图片上传相关的功能的，后来参考了别组的经验，成功在头像和动态处加上了图片上传的功能。
不足部分：
界面UI和一些交互还是不够合理，其中的比如聊天室部分原本打算用热榜形式推荐，后来遗漏实现了，不过有附加增加区分列表的显示。
和alpha阶段相比，软件工程质量是有提高的，其中最明显的就是经过alpha冲刺的经验，我们更加注重前后端的交流，可以看到前后端人员配合更加密切，同时接口的约定不再只是简单的用交流的方式，而是直接细致到共享文档，以便能够留下记录并提高开发效率。同时，提倡将遇到的问题记录到共享文档中，能更好的看到每个人的进度，及时进行开发的必要干涉/
设想的用户量大概为300左右。用户对重要功能的接收程度较好，没有提出关于聊天功能的一些意见或者需要改进的点，但是对于一些界面及
1.美工吧，从用户反馈中来看有点太过于忽略美工的重要性。同时一些用户的交互还是有不合理的地方。
2.小部分模块在整合后的测试还是有发现许多问题，所以还是应该监督好每个人把自己的模块开发好。
和alpha阶段相比，我们让每个人每天的工作细化下去，记录在在线文档中，同时每天晚上对小组成员的进度实时查看并在leangoo中更新，可以看到组员每日记录更加认真，时间规划也更加好。
对于组员的不同意见都是在站会中提出共同讨论解决，一般是组长发表一个自己认为的观点，然后再看组员的其他观点，最终不行就投票决定意见，但是组员都比较和睦，没有出现这种需要的投票解决的不同意见。
原计划中，客户端是有广告页的，但是实现时发现我们还没达到商业化软件的地步，就没去实现。
是有明确的交付件的。大部分功能总体上与原本定义的没有太大差别，小部分功能如漂流瓶没有做到前期预想的类似“随机接力填写内容”的漂流瓶功能，而是更倾向于传统的漂流瓶功能，但是由于原本这只是娱乐功能，便也没有进行更改。
前期在选择技术时选择了ssm，其中环境的配置给我们造成了挺大的麻烦。
造轮子造出来的websocket连接模块，经常出各种莫名其妙的问题。
漂流的记忆模块，开发成果与最初的设计有一定的差异
有预留时间，如完善阶段预留了一天时间，开发阶段预留了两天时间，用于测试和追赶进度。
前端的参考资料以及辅助工具资源不足。其他的整体上还算足够。
各部分模块人员应更认真进行测试，以免后期整合后发现错误修改不便而且对项目进度产生影响。
前后端应该有更多预留时间，以供解决完善发布后出现的一些问题。
只是还是需要巩固得更深一点，以免开发时效率过低。、
因为在alpha冲刺到beta冲刺有一定得休整时间供组员去学习了解新知识，所以这段时间是够组员去巩固知识的。
对于一些硬件的资源，如云服务器和云数据库的限制。
相对alpha阶段而言更好了一些，但仍然有些不足，主要集中在能力差距上带来的偏差。美工上，确实有点考虑不足，最后时间比较紧，只能做一个风格基本统一，没能很充足地进行完善。
后端的话有让同学去进行一系列的单元测试，接口压力测试，但是感觉其中有些部分用户量大的话可能还会出现问题。
变更的组员在站会、讨论提意见方面较为积极，但是在接口的开发和设计方面后期经测试出现的问题较多。
如果未变更项目的开发效率应该会更高。
学到了什么参见总结博客。
有提前让他去学习一系列相关知识并了解项目，应急计划的话就是将原本的聊天功能的实现交给另外的人来做。（因为重新学习netty成本较高）
来自前端管理人员的看法：
有，但是会引起任务分配不均的问题。历史重来的话，我想牺牲一些模块化的优点，将任务分配的粒度更精细一些，使得简单的任务交给能力较弱的人来做，比较困难且重要的任务交给你能力较强的人来做，避免能力较弱的人因为任务难度卡进度，能力较强的人因为任务简单但量大而卡进度。
没有进行重构。
有进行单元测试，开始的uml和现在的状态有些不同，其中一些模块的整体关系，逻辑当初没考虑清楚，甚至到更新uml.
Websocket当属第一，解决这方面的问题至少解决了五六次，前后加起来得有两三天。设计开发时，没想过会这么容易断掉连接，而且也没想到只要稍稍没处理好一处异常，这一块就会全线崩溃。
其次便是朋友的推荐，其中在测试过程中发现许多推荐的朋友不合理的地方，如被封禁用户，黑名单用户等等，这些后期都进行了进一步的完善。
代码复审采用不同模块的人去测试，同时又专门的测试人员进行查看，整体上执行了代码规范。
有时候有些东西在设计时考虑得不够仔细，导致到开发时需要讨论修改，影响了开发效率。
对于一些任务划分应该将简单的任务交给能力较弱的人来做，避免出现项目卡进度得情况。
前端方面，始终没找到能测试mui和h5+的工具，后面谷歌浏览器的真机模式与阿里云的移动测试一直用不了，就没法进行比较数据化的测试。只能开发过程中连接mumu模拟器进行功能点的开发测试，然后利用hbuilderx里的内置浏览器再结合组员的真机进行多种界面的UI适配的测试，最后进行团队内部的模拟用户体验测试。
后端方面，各个模块开发进行了单元测试和postman测试，同时，也进行了接口得压力测试。
完成一项功能模块后便进行测试，同时后面有单元测试和接口测试。
单元测试（IDEA，Junit）
POSTMAN（接口测试）
JMETER(压力测试)
hubilder+模拟器+真机（前端）
结合hbuilderx的控制台日志输出与流程检验。后续根据这些内容，部分地方利用了缓存加载的方式，使得软件的更快捷了一些。
测试效果：界面得使用有进行功能得评估，对程序的实现有较大帮助，大部分模块没有出现较大问题
改进:测试用例可以多一些，同时测试的时间得再长一点。
发布后，出现了大大小小得问题，其中也增加了更新日记对问题进行了汇总。详情请看软件个人中心右上角下拉栏更新日志。
软件得测试和发布后得用户反馈功能修改应该留更多得时间。
首先功能模块得划分由前后端各一位同学进行划分分配，在没有异议得情况下进行在线文档得构建，跟踪组员开发进度。人尽其才方面，有些组员能力较为薄弱，但在其他组员的帮助下，最终也实现了功能，基本实现了人尽其才吧。
有。遇到问题时，组员会主动向组长反馈或者在群中直接提出，我们也会在每日站会中就组员在在线文档中编写的问题困难点询问解决情况，组员间能很好的互相帮助，共同解决。
一般都是开会讨论决定的。
见总结博客。
第三档次吧。
规范阶段，能够按照规定完成任务。
代码复审只采用人工测试人员复审，提高得话可以采用插件简化过程。
可以使用代码重构。在代码复审和测试得过程将发现得冗余得类或者冗余得方法进行抽离/提取，同时，尽可能复用类得功能和方法。其次是对数据库的操作层面上可以对程序的架构提高，项目中经常出现重复查询的情况，可以通过视图的方式或者连接查询的方式减少查询次数。
github的使用应该有跟深一步的了解，同时对于测试工具很多只停留在表面，应该跟进一步去理解掌握。
任务追踪更加明确精细。
有些组员出现回复慢的情况，有些组员能力上有不足的点，这些在组员任务分配的时候应该有更进一步的考量，考虑把简单的任务分配给能力上稍微不足的人，同时调动组员积极性，不要让组员回复慢、效率低的情况影响到小组氛围。
标签：选择 谷歌浏览器 自己 出现 硬件 控制 信息 决定 后端
原文地址：https://www.cnblogs.com/RATE-MAX/p/13096724.html
