Part.01 调研，评测

评测：

软件的bug，功能评测，黑箱测试

本次作业选用的完成方式：方式一

（PS：在一开始尝试使用方式二进行开发，作为一个目标是成为专业后端工程师的人，我的第一思路是将这个sdk的开发文档中的REST API整合到springboot里的，然后用一个简单的gui进行测试，无奈这个sdk确实是提供给前端的人员开发使用的，且并没有为java提供接口，我只能想办法自己弄，最后截止2020-04-17晚上，在借鉴了github一个开源项目的前提下，把腾讯即时通讯IM SDK整合到springboot时出了一些问题，卡在那了，报空指针，估计还是计算usersig那里出的问题，考虑到马上截止了，只好悬崖勒马，换用方式一重新开始，目前本人已自闭，心情有点郁闷ing，拖大了，还是按照开发文档按步骤来使用SDK可能可行性要大很多）

Demo测试(本次对web端、Android端、ios端与小程序端均进行了同类型测试)

下载并使用demo，对使用的不同demo，每种demo至少提供两张使用过程中的截图

• web端：设备 个人PC（系统：Windows 10 专业版）

登录界面测试
测试结果：界面显示正常、创建用户功能正常

字符串类型输入测试：文字型信息一般文字、表情
测试结果：输入、接收正常、信息显示正常

文件流类型输入测试：图片
测试结果：输入、接收正常、图片显示正常、图片可预览

文件流类型输入测试：视频
测试结果：输入、接收正常、视频显示正常、视频可点击在线播放

自定义消息输入测试
测试结果：输入、接收正常、自定义消息不可点击查看详情（那自定义消息的意义何在？)

• Android端：设备 MI9（系统：MIUI 11.0.5稳定版）

登录界面测试
测试结果：界面显示正常、注册登录功能正常

添加好友测试
测试结果：添加好友功能正常，验证信息功能没有显示验证信息

字符串类型输入测试：文字型信息一般文字、表情
测试结果：输入、接收正常、信息显示正常

文件流类型输入测试：图片
测试结果：输入、接收正常、图片显示正常、图片可预览

文件流类型输入测试：视频
测试结果：1、直接录制的视频输入、接收正常、视频显示正常、视频可点击在线播放
2、无法上传本机的视频，报错（云通讯：right)，初步判断是没有获取应用的读取文件权限
3、本机的视频可通过文件上传，但无法下载仅显示存储路径，这样的设计很不友好

自定义消息输入测试
测试结果：输入、接收不正常、安卓这边直接不给自定义了，直接显示欢迎加入云通信IM大家庭，点击后跳转开发文档

• ios端：设备 ipad mini5（系统：13.3.1（17D50））

登录界面测试
测试结果：界面显示正常、注册登录功能正常、让人欣慰的是和安卓那边数据是互通的，估计应该是一个后端提供的接口，但是字体在我的设备显示有问题，是白色的，在账号框与密码框，根本看不清自己输入了什么，很差的人机交互，在后续界面也有此问题

输入测试
测试结果：因和安卓界面UI逻辑基本差不多，输入与接收正常的地方和上部分安卓一样，问题也和上部分安卓一样，字体颜色仍有问题

• 小程序端：内嵌微信不展示设备（微信版本：7.0.13）

登录界面测试
测试结果：界面显示正常、创建用户功能正常

输入测试
测试结果：1、字符串类型输入、接收正常、信息显示正常
2、文件流类型输入测试：图片输入、接收正常、图片显示正常、图片可预览
3、文件流类型输入测试：视频输入、接收正常、视频显示正常、视频可点击在线播放
4、自定义消息输入测试输入、接收正常、输入、接收正常、自定义消息不可点击查看详情（那自定义消息的意义何在？)
PS:小程序端的问题表现与web相同，应该是直接把web作为一个frame嵌入微信的，所以在小程序端视频上传正常且自定义消息的问题表现相同

使用发现的BUG

1、找出至少两个比较严重的功能性bug（说明：操作不够人性化、没考虑到用户的xx需求等并不算严重的功能性bug）
2、请使用专业的语言描述（每个bug 不少于 40字），并配图说明
3、你觉得为什么这个产品组的人没有发现这些bug??
PS:在上一部分在对各个端进行测试时，发现了一些小的bug，已在上部分测试结果指出，在此处就不一一列举，在本部分主要列举严重的bug

• 软件Demo使用过程中的bug（黑箱测试发现的）

• BUG1:ios端的ui字体与整体UI显示问题

• 问题描述:

ios端的ui字体与整体UI显示问题，在登录界面用户名、密码无法显示，疑似是字体颜色的问题，然后在显示详细资料、我的个人消息、开发调试等界面均有按钮的左侧描述字样无法显示的问题（因长按按钮会发现实际是有一个按钮名字的，显示为灰色，如我的个人消息界面中第一个按钮左侧显示为好友申请，但正常状态不显示）

• 开发人员没发现这个问题原因:

我猜测有两个可能 1、开发人员没有正确的对按钮等UI的背景颜色和字体的颜色进行设置，故导致字体和背景均为白色，导致显示不正常（但考虑到鹅厂这样的大厂的程序员不会犯这样的低级错误，故本人不是很倾向于这个猜测）；2、该app测试发布的ios版本与当前版本（本人使用的是最新的13）相比应该较老，然后ios系统在更新过程中可能对操作系统的字体颜色库进行了版本更新，可能修改了对应字体颜色调用时的方法或变量名，然后该app在调用字体颜色的时候找不到对应的映射，调用失败，异常处理将字体的颜色调用了默认的白色故导致了现在出现的问题（本人比较倾向于这个猜测，但是手上没有其他版本的ios，且不可能顺着ios的版本由新到旧逐一测试，该app在发行时，发行的人员手上应该有对应的ios版本，这个开发人员好找问题，该猜测暂时无法证实）

• BUG2:黑名单操作时的消息显示问题（测试时使用本人Android（登入用户theTuring_221701412）和ios设备（登入用户test_221701412）进行测试，Android设备将ios设备的用户拉入黑名单，ios设备发送消息）

• 问题描述:对这个问题按照操作流程进行描述

• Step1：用户theTuring_221701412将用户test_221701412拉入黑名单

• Step2：用户test_221701412向用户theTuring_221701412发送消息：我现在已被拉入黑名单

• Step3：用户theTuring_221701412将用户test_221701412移除黑名单

• Step4：用户test_221701412向用户theTuring_221701412发送消息：我现在被移除了黑名单

• Result：用户theTuring_221701412界面：仅收到消息：我现在被移除了黑名单（状态：已读）；用户test_221701412界面：显示消息：；1、我现在已被拉入黑名单（状态：已读）2、我现在被移除了黑名单（状态：已读）

• 问题所在:

用户theTuring_221701412并没有收到消息：我现在已被拉入黑名单，但用户test_221701412那边反馈却是已读（这样的bug在某些场景很致命，本人目前想到的最明显的场景就是恋人之间吵架（A与B），A拉黑B，拉黑后B说了很多道歉的话理论上应该可以挽回A，A在第二天从黑名单又拉回B，B界面显示A已收到长篇大论的道歉（已读），A那边却并没有收到，两人渐行渐远（PS：个人建议：1、重要事当面讲，工作上的也好，爱情友情上的也罢，聊天工具的bug难说会导致信息不对称与遗漏，就算做不到打个电话！！2、强扭的瓜不太甜，不要当舔狗！！！））

• 开发人员没发现这个问题原因:

在研究了腾讯即时通讯IM的开发文档后，由REST API 接口列表里面研究了添加黑名单、删除黑名单、导入单聊消息的API的文档中请求包与应答包的JSON数据包后得出了以下猜测（使用上述用户举例）：用户theTuring_221701412调用添加黑名单接口将用户test_221701412拉入黑名单；然后用户test_221701412发送了消息：我现在已被拉入黑名单此时该消息被存到了处理队列中；用户theTuring_221701412调用删除黑名单接口将用户test_221701412移除黑名单，根据文档删除黑名单接口，请求包仅发送解除的用户的json数组，用户test_221701412向用户theTuring_221701412发送消息：我现在被移除了黑名单，用户theTuring_221701412调用导入单聊消息接口就接收到了第二条消息，应答包就返回了一个ok给用户test_221701412；用户test_221701412接收到ok，则逻辑将最新以及以前的消息全部标记为已读（问题就是出现在这里的！！因为按照常规的逻辑你读了最新消息那之前所有没读的都应该读了，但此场景因为黑名单的操作实际上第一条消息还在用户test_221701412的请求队列中没有发出去，但也被标记成了已读），我认为这个bug只需要给消息增加一个标记，且在导入单聊消息接口的应答包除了ok的属性再增加一个标记的是哪条信息即可解决。

涉及的接口列表

删除黑名单接口的请求包

导入单聊消息接口的请求包

实际操作出现bug截图

采访：

假如你需要用这个腾讯即时通信SDK开发属于你的自己产品，那么开发之前你除了需要了解该SDK的基本使用之外，更重要的就是为你将开发的产品进行市场调研
第8章 用户调研，12 章 软件的用户体验

我想要利用 IM SDK 开发的产品

构思你根据该SDK想要开发的产品，包括产品主要功能、产品面向的用户、NABCD分析等

• 产品名：千寻

• 产品类型：

根据用户注册的兴趣标签，做一个即时匹配的聊天软件，让你在茫茫人海中遇见那个与你意气相投的ta，产品名取自诗句：众里寻他千百度，那人却在灯火阑珊处。

• 产品功能：

  • 提供一个即时聊天的交友平台；
  • 根据算法匹配，根据用户在注册时一个必填的几个信息：爱好、个人标签、喜欢的圈子、性别，进行一个限定范围的随机匹配；
  • 建立即时通讯连接，用户可以发送普通信息、图片、视频等，也可以选择进行视频聊天；
  • 对聊天的记录进行一个持久化的记录，可以对你中意的那个ta（前提是在线）选择再次发起聊天；
  • 对于有违规操作的用户进行管理，初犯禁言，惯犯封ip；

• 面向用户：

在社会上缺乏友情，缺乏社交的人，有社交恐惧症的人，可以先尝试在这个平台迈向社交的第一步；在小众圈子有特别爱好，在日常生活圈子无法遇到意气相投的人的人，可以通过这个平台找到朋友一起合作；喜爱社交，热爱广交朋友的人，可以通过这个平台认识更多的人。

• 用户场景举例：

  • ①自闭缺少朋友的陈同学，在日常的社交中一遇到人很多的大型聚会只想逃跑，有一定的社交恐惧症，在现实有一肚子的话却无人也不敢与人诉说，但是有所不同的是他在网络上又是另外一个样子，很爱表达自己的想法，有一天他突然发现了一个叫做千寻的即时社交app，登上以后随机匹配到了一个人，一步步的从开始的语音交流，到后面的与那人再一次发起聊天，这样愈加接近于现实社交，渐渐的让他在现实中敢于表现自己，最后与现实和网络中的朋友们都其乐融融的相处起来了。
  • ②喜爱传统武术的黄同学，热爱传统武术，但是自己却是一所知名大学的软件工程的学生，周边的同学大多爱好都是游戏和打代码，自己空有一声好武艺，却没有人可以交流，有一天他的朋友陈同学在逛论坛的时候看到了千寻给他进行了安利，果然试了几次匹配以后，见到了咏春的大佬-叶某，一问二人在一所城市，没过几天，就线下见面，在武馆切磋了起来，场面极其快活，那叫一个刀光剑影！
  • ③喜爱广交朋友的刘同学，从小到大就凭借着自己不错的社交能力交了很多朋友，但是随着年龄增长，身边的人都开始忙起来了自己的事情了，有人考研、有人准备面试、有人在忙着练武，感觉自己有很多心里话想与人诉说，但是好像朋友都在忙，也渐渐疏远了不少，在好友陈某的安利下下载了千寻，填完了自己的个人信息，爱好旅游，于是在一次匹配中遇到了同样热爱旅行的牙某，随着聊天的不断深入，二人也不断的在聊天记录中发起了再次聊天，最后二人约在了某知名旅游景点见面，一起去爬山，此时的二人都心生爱慕，确定了男女朋友关系，一问二人居然在一所学校（因为在匹配前其实有填了学校），从此，校园里又多了对甜甜蜜蜜的情侣。

采访潜在用户

从你的身边寻找你要开发的产品的潜在用户，记载你对这位用户的采访。使用下面的采访提要：

• 介绍采访对象的背景和需求

采访的对象是我的好友刘同学，刘同学有着和上述用户场景3相似背景，爱广交朋友，一方面享受于与人聊天的快乐，一方面也想多交朋友为自己以后的创业增加人脉基础。刘同学渴望能有一个软件工具能帮助自己找到意气相投的伙伴，一起分享快乐，一起排忧解难，在未来一起在社会上闯出一片天地。

• 采访对象使用Demo图片

• 采访过程（语音形式）介绍了我想用SDK制作的产品

• 用户使用腾讯即时通信Demo体验

用户使用这个demo的过程, 用户的问题初步解决了，可以完成日常生活的最基本的聊天；软件在数据量/界面/功能/准确度上，总体还是可以的，但是界面更加设计的不是很好看，可以更简洁一点，功能上web端对于分类模块设计的让人一头雾水，准确度的话大致可以；用户体验方面，有些交互不是很友好，如界面的聊天界面显示感觉与习惯性的左发送者右接收者相反，不是很习惯。

• 用户对SDK的意见

SDK 的开发文档做得不是很友好，存在很多困扰开发者的地方。对于实现小功能的场景，这个 SDK 足够应付。如果要提供针对性服务，需要后端的支持，但是该SDK并没有提供java的后端接入。

• 用户对我开发的产品的意见

这个想法不错，具有较高的可行性，是一种新型的社交软件，应该挺有意思的，但是也有很多细节需要考虑和完善。对于并发的问题的考虑与匹配算法的设计还需要多加考虑。

• 结论

  • 非常不推荐
  • 不推荐
  • 一般
  • 推荐 √
  • 非常推荐

Part.02 分析

参考 8.6 节 对工作的估计， 和14.1 节 软件工程的质量
使用腾讯即时通信的所有功能，联系第二部分的分析，估计这个SDK做到这个程度大约需要多少时间？（团队人数大约6人左右，计算机大学毕业生）。 分析这个软件目前的优劣（和类似软件相比，如网易云信），并推理出团队在软件工程方面可以提高的一个重要部分（具体建议）

时间规划

使用腾讯即时通信的所有功能，联系第二部分的分析，估计这个SDK做到这个程度大约需要多少时间？（团队人数大约6人左右，计算机大学毕业生）

规划前的准备

其实现在的大多即时通讯SDK，本质应该都是基于TCP的Socket套接字编写的一个多线程的系统，我在对腾讯即时IM SDK进行分析之前，大概花了一个下午使用java的Socket套接字完成了一个Sever – Client端可以实现仅发送文本的即时聊天程序，以此程序的完成工作量来推测腾讯即时IM SDK的开发时间，我的程序运行截图如下：


下图是我从github中获取的一个大概的IM系统的系统架构，也为我分析的基础参考：

开发这个SDK需要解决的问题

• 1、一个开源的公用SDK对于高并发的请求的处理问题
• 2、在给每一位申请了SDK用户分配了密钥以后，对于每位用户调用接口后的数据存储的持久化及安全性问题
• 3、对于提供接口不恰当调用，对提供服务器造成的负载问题
• 4、接口完善后的测试阶段，如何做到合理测试问题，保证能满足基本功能使用
• 5、接口完成后的开发文档攥写问题，如何能让第三方的开发者能快速上手
• 6、接口完成后的Demo（服务于多个平台）编写及Demo编写后的基础测试

我的结论

前提条件：
团队人数大约6人左右，计算机大学毕业生，且每人编程水平都较高前提，按照国家规定的每天 8 小时一星期工作 5 天工作制，按照有一人有相关经验，能做系统的整体设计，六人人员能力得满足如右（系统总体构架且有参与过即时通讯系统大型项目经验：1人；java后端且熟悉服务器端的代理以及Socket套接字与多线程编程的人员：2人；熟悉Android：1人；熟悉web前端：1人；ios：1人；熟悉c++编程：1人；熟悉单元测试、接口测试、并有很好的文档攥写能力：1-2人），在6人之中能满足之前我列举的能力中2-3项的前提下
我认为这个SDK可能可以在1year（约260个工作日）左右被初步的开发出来，我认为大致的时间安排如下：

• 需求提取分析：15个工作日左右
• 系统设计：15个工作日左右
• 分布式数据库设计：20个工作日左右
• SDK接口开发实现：60个工作日左右
• 服务器代理配置及负载测试：20个工作日左右
• 测试修改bug及攥写文档：80个工作日左右
• demo编写及测试：40个工作日左右

同类产品对比优劣

分析这个软件目前的优劣（和类似软件相比，如网易云信）
在通过搜索引擎获取信息后得到以下的竞品分析图：

再通过比较核心服务价格，得出腾讯即时通讯IM SDK有以下优劣势：

• 优势
  • 群组聊天支持量最大：鹅厂家大业大，腾讯云服务器规模是在国内数一数二的，自然对于稍大一点大开销是不在意的
  • 平台支持较为丰富
  • 群组核心功能较为丰富
  • 核心服务价格有免费版本：适合个人进行开发测试，也可付费升级服务较为亲民
• 劣势
  • 对于实时视频音频的功能不支持拓展，限制了某些模块的开发调用
  • 文件传输有限制，28mb偏小，不清楚在付费后有没有升级一说
  • 服务端消息记录存储时间较短
  • 教学白板模块不支持，限制了在教学领域的使用
  • 服务维护较差仅可提工单，但没有论坛，缺少像其他竞品的服务维护体系

团队软件工程方面建议

推理出团队在软件工程方面可以提高的一个重要部分（具体建议）

对于团队在软件工程提高方面，我现在的最大的感受还是一个团队的整体合作的部分，如何去达到一个更好的团队的合作效率，一般来说，在一个团队里面成员能力是参差不齐的，擅长的领域也是不同的，诚然，就常规的任何一件事的团队合作来说来讲，各司其职，发挥所长，扬长避短这样可能是最好的安排。但说回团队软件工程方面，我认为情况又有一些的不同，首先，我认为在一个团队软件工程的情景下，一个leader是必要的，这个领导者可以是一个人、也可以是几个人、一群人，毕竟软工的项目是需要一个整体的架构的，一个好的整体设计能为后续的开发减少很多在跨模块的交互之间减少很多不必要的磨合，leader们就需要做到这个，这背后也是经验的体现。然后谈到个人，术业有专攻，渐渐的在团队内的软工角色会划分为前端、后端等再被按负责模块细分，但是这不代表就只需要会自己常负责的模块，每个个人知识的全面性的提升对与团队整体的合作会有很大帮助。

Part.03 建议和规划

参考《构建之法》第8章 功能的定位和优先级；第9章 项目经理

假如你需要用这个腾讯即时通信SDK开发属于你的自己产品：

• 如果你是项目经理，如何提高从而在竞争中胜出？

  • 1、在项目启动阶段，做好充分的市场调研，从统计数据中提取出最切合用户实际的需求
  • 2、做好成本分析，尽量对项目成本预算做到最佳的管控，在预算内让成本发挥最大效益
  • 3、使用合理的团队管理模式，做好团队分工，提高团队的效率
  • 4、运用项目管理知识体系（PMBOK），合理运用10大管理与自己的专业素养科学管理项目

• 目前市场上有什么样的产品了？

  • 1、soul：即时匹配通讯社交软件，基于心灵的智能社交APP。功能是寻找最适合自己的灵魂伴侣。 微信微博上发不出的话，默默记录在案，而恰巧有陌生人在意。
  • 2、陌陌：MOMO是陌陌（NASDAQ：MOMO）于2011年8月推出的一款基于地理位置的开放式移动视频社交应用，是中国的开放式社交平台。在MOMO，可以通过视频、文字、语音、图片来展示自己，基于地理位置发现附近的人，建立真实、有效、健康的社交关系。陌陌的愿景是希望人们通过移动互联网，发现身边的美好与新奇，让人们连接原本该连接的人。
  • 3、探探：探探是一个基于大数据智能推荐、全新互动模式的社交App。探探根据用户的个人资料、位置、兴趣爱好等信息，计算并推送身边与你匹配的人，帮助用户结识互有好感的新朋友。

• 你要设计什么样的功能？

  • 1、提供一个即时聊天的交友平台；
  • 2、根据算法匹配，根据用户在注册时一个必填的几个信息：爱好、个人标签、喜欢的圈子、性别，进行一个限定范围的随机匹配；
  • 3、建立即时通讯连接，用户可以发送普通信息、图片、视频等，也可以选择进行视频聊天；
  • 4、对聊天的记录进行一个持久化的记录，可以对你中意的那个ta（前提是在线）选择再次发起聊天；
  • 5、对于有违规操作的用户进行管理，初犯禁言，惯犯封ip；

• 为何要做这个功能，而不是其他功能？

  • 这个功能是自己对于现今三种比较有代表性社交心理分析得出的需求而设想出的功能，在社会上缺乏友情，缺乏社交的人，有社交恐惧症的人，可以先尝试在这个平台迈向社交的第一步；在小众圈子有特别爱好，在日常生活圈子无法遇到意气相投的人的人，可以通过这个平台找到朋友一起合作；喜爱社交，热爱广交朋友的人，可以通过这个平台认识更多的人。

• 为什么用户会用你的产品/功能？

  • 我认为社交对于人类这种社会性动物来说是日常生活种非常重要的一环，人不能脱离这个赖以生存的社会，而在社会立足则离不开社交，这个产品设计了一种新型的社交模式，根据对于三种有一定代表性的用户场景进行分析，我认为还是较为契合当今人们的社交心理的，是切合用户需求而设计出的产品。

• 你的创新在哪里？可以用 NABCD 分析。

  • N:用户需求分析

    • 1、缺乏社交的人，需要一个迈向社交的第一步的机会；
    • 2、小众圈子有特别爱好的人，需要一个与志同道合朋友社交的机会；
    • 3、热爱社交的人，需要一个平台去认识更多的朋友；
    • 4、所有人都需要社交，而一种新型的社交模式可以为人们提供一种new style的社交模式。

  • A: 我们的独特招数

    • 在功能方面：我们
      • 1、提供一个即时聊天的交友平台；
      • 2、根据算法匹配，根据用户在注册时一个必填的几个信息：爱好、个人标签、喜欢的圈子、性别，进行一个限定范围的随机匹配；
      • 3、建立即时通讯连接，用户可以发送普通信息、图片、视频等，也可以选择进行视频聊天；
      • 4、对聊天的记录进行一个持久化的记录，可以对你中意的那个ta（前提是在线）选择再次发起聊天；
      • 5、对于有违规操作的用户进行管理，初犯禁言，惯犯封ip；
    • 在需求方面：我们认为
      • 社交对于人类这种社会性动物来说是日常生活种非常重要的一环，人不能脱离这个赖以生存的社会，而在社会立足则离不开社交，这个产品设计了一种新型的社交模式，根据对于三种有一定代表性的用户场景进行分析，我认为还是较为契合当今人们的社交心理的，是切合用户需求而设计出的产品。

  • B: 我们带来的好处

    • 1、更便捷，一种根据你的自我标签随机匹配的社交方式；
    • 2、更专业，通过腾讯即时通讯IM保证了传输的稳定与安全；
    • 3、更切合用户需求，专注于即时社交模块，可根据用户需求做出更多的私人化定制。

  • C: 我们的竞争对手

    • 参考前面SDK分析部分的竞品分析以及建议和规划部分对于产品竞品的分析（Soul、陌陌、探探）。

  • D: 我们如何推广

    • 1、推出产品，上线应用商店
    • 2、通过短信随机发送邀请，邀请用于参与内测，参与有奖
    • 3、通过一些自媒体与现在的新媒体平台通过现在的一些新的推广方式推广，包括但不限于广告，vlog等方式。

• 如果你来领导这个团队，会有什么不一样？

  • 1、我会加强与队员的交流，做好这个系统的整体构架与设计
  • 2、做好分工与沟通的设计，增加团队效率
  • 3、定期进行汇报会议，定期对整体项目计划进行讨论与修正
  • 4、做好必要的文档攥写工作，保证后续开发不会偏移初衷
  • 5、在发行前做好测试工作，减少发行后的程序错率
  • 6、做好后续的版本更新迭代，不断的减少bug，更加的贴近用户需求

• 如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？

  • 如果我的团队有5个人, 4个月的时间，我作为项目经理，角色我配置为：测试1人、美工设计1人、后端逻辑部分编写人员1人、数据库设计及服务器管理人员1人、前端界面设计人员1人。

• 描述你的团队在周期为16周，每周都要做什么，才能保证在第16周如期发布软件。

  • 第 1 周：需求分析（团队会议，所有成员参与）
  • 第 2 周：原型设计（美工设计，开发人员参与建议）
  • 第 3 周：工具评测（团队参与进行）
  • 第 4、5 周：系统设计（由项目经理主导，开发人员参与）
  • 第 6 周：数据库设计（数据库设计及服务器管理人员负责，后端逻辑部分编写人员参与建议）
  • 第 7 周：设计阶段结束，用一周时间重新回顾之前的各部分重新思考，修改回顾不合理部分（团队参与进行）
  • 第 8 周：项目整体架构（项目经理主导进行）
  • 第 9、10、11、12 周：编码开发阶段（项目经理+开发人员+测试人员可以开始对完成模块进行单元测试)
  • 第 13 周：前后台交互，服务器部署（项目经理+开发人员）
  • 第 14、15 周：测试阶段（测试人员大规模测试、开发人员修改bug）
  • 第 16 周：发行阶段，交付项目，做好后续迭代的准备

• 项目发布后，有没有考虑过项目该怎么部署才能满足需求？依据下图（某校教务处系统的部署）作为参考，分析16周后你所完成的项目上线需要哪些配套设备(服务器、带宽、数据库需求数量与配置)

• 该项目初步分析应该并发较高，考虑选用腾讯云顶配的云服务器，后续具体升降还得考虑具体的项目架构

• 应用服务器集群：专业配置 四核8GB 2.4GHz *2 公网带宽 200Mbps

• 关系型数据库：MYSQL数量：3（读写分离2，备份1）

• 缓冲数据库：Redis（主1、备1）

• 安全性：ARP(保证通讯数据安全)、DDOS(分布式拒绝服务攻击)

Part.04 Q&A部分

本部分对本次答辩老师以及助教的提问进行回答

• 汪老师

• Q1:视频在线播放流畅吗？

  • A1:视频在线播放流畅，不过测试使用的视频为10s左右的短视频，对再大一点的视频是否解析会出现卡顿等情况，还需进一步测试。

• Q2:在浏览器端和手机端有差别吗？

  • A2:就目前的测试结果来看,浏览器端与小程序端基本展现的界面逻辑与问题完全相同，考虑应该小程序端直接内嵌web端的，浏览器端和手机端有一定差别，主要体现在视频的上传方面（调用本地视频报错）、自定义消息方面（web端可定义，手机直接跳转开发文档）等方面。

• Q3:黑名单那个问题是否是有意不发送移入黑名单信息呢？

  • A3:黑名单有意不发送移入黑名单信息我认为这样的设计是合理的，但是不应该在另一方标记为已读，这样的处理会造成双方的消息不对称，我认为是一个bug应该修改。

• 傅老师

• TIPS:微信和QQ的黑名单一般是静默的。

• 林助教

• Q1:它是如何防止DDOS攻击呢，如果发起大量TCP半连接，并且伪装ip，那封禁ip是解决不了的。

  • A1:：对于DDOS攻击，可以通过CDN节点中转加速服务隐藏服务器真实IP，关闭不必要的服务或端口，增加服务器的带宽增加承压能力，增加网站请求IP过滤，然后本身腾讯的云服务器就有安全服务可以考虑购买，如果发起大量TCP半连接，并且伪装ip这个暂时没有想到怎么解决，以为之前考虑的封ip是针对一般的违规用户，其也不具备网络攻击的能力。