一、项目亮点
典型应用场景1-个人开发尝试
应用场景案例实现链接：QuickStart:跟我一起来部署第一个函数吧
守好嘉今年18岁了，高考结束后如愿进入北航信息类，以计算机学院为目标的TA最近在自学Python后端，希望能够先人一步，获得实战经验。
但是在了解到传统后端都需要服务器支撑后，守同学陷入了麻烦，TA并不清楚自己的数据库是否真的会投入使用，以及为此是否值得去购买24h不停运转的服务器，并且在了解到部署时的复杂工作和可能面临的配置问题后，守同学更希望能跳过这些复杂的准备工作，而是直接编写代码并验证。
幸运的是，守同学了解到了本平台。经过简单的注册登录，守同学直接进入了代码编写阶段，在终端输入学到的指令后，项目所需要的依赖也完成了自动注入，完美跳过了服务器的准备与配置工作，并且按使用计费，完全不用担心服务器闲置造成的资源浪费。
在快速写完一个简单的函数后，守同学又想到了一个问题，该怎么由前端发送请求触发呢？TA在函数触发器配置界面找到了答案，将触发形式设置成网络API请求触发，TA获得了一个由服务器自动分配的用于测试的API，可由前端轻松调用，快速的验证了自己的学习成果。
典型应用场景2-邮件整理
应用场景案例实现链接：使用SimDep部署定时邮件聚合推送服务
支支是刚刚考研到北航马院的研一新生，目前大四下尚在努力准备毕设，同样在组里的几位新生是来自其他省份的跨考学生，鉴于大家时间难以错开安排，导师要求在目前这个工作并不是很急的情况下用邮件联系，这下支支不得不每天关注邮箱，但是邮箱每天总会收到各种其他邮件，平时不整理邮箱的TA犯了难。
支支是典型的文科生，并不擅长编程，只会简单的python，但是TA了解到了本平台后，有了一个有趣的想法。支支从网上找到了如何使用python读取解析邮件内容并将题目收件人保存到指定文件的方法，在把其copy到本平台新创建的函数后，选择触发形式为每日定时触发，完成了一个定期自动任务的创建，这样每天的邮件都可以被自动整理了，每天晚上只需要看当日的总结即可了解到是否有有用的邮件。
典型应用场景3-NLP应用
应用场景案例实现链接：部署一个前后端分离的简单NLP应用
最近ChatGPT的大火提起了TD同学对NLP的浓厚兴趣，于是TD同学选择找一位研究NLP方向的导师做项目，导师很高兴能有人坚持学习NLP，于是分配他到一个简单的任务组——提取论文的摘要。TD在研究了几个深度学习模型后，修改并训练了自己的第一个NLP模型。
TD找到了本平台并将自己的模型布置在了一个独立的函数服务中，将函数设置为http请求触发，每次直接将本地的论文POST上传至平台，自动触发模型解析流程。最重要的是，需要使用该处理结果的另一个组可以随时调用接口，TD真正感受到部署服务并被人使用的快乐。
然而TD的导师并不满意，认为应当比较多个模型，而这些现有的模型居然连基本依赖包的版本都互不相同！TD考虑到本平台各函数服务的环境之间独立封装，互不干扰，因此干脆直接将需要比较的多个模型分别部署在不同的http函数服务中，供随时调用。
尽管完成了导师布置的任务，但TD认为自己的http服务尚有提升空间。TA在研究过程中发现有的模型提取英文论文摘要准确率更高，而有的模型提取中文论文准确率更高。不想调参重新训练的TD，决定再写一个http函数，作为任何论文的统一输入接口，先判断论文语言，传给指定模型，即已部署接口的互相调用，优化了自己的服务。
| 功能/平台 | SimDep | 华为云 | 腾讯云 | 阿里云 |
|---|---|---|---|---|
| 上手难度 | 简单 | 复杂 | 较复杂 | 较复杂 |
| 计费规则 | 简单 | 复杂 | 复杂 | 很复杂 |
| 框架知识掌握需求 | 无 | 高 | 高 | 高 |
| 需要的前置准备工作 | 无 | 很多 | 较多 | 很多 |
| 依赖配置复杂度 | 简单 | 复杂 | 简单 | 简单 |
竞品出于什么样的原因达成这些目标
当一个系统具有高自由度的强大功能的时候，它就不可能是简单的。
我们的竞品主要是国内大型的云计算服务提供商，他们的业务主要面向企业、政府及组织。
他们需要各种各样的功能来支持单体服务向函数平台的无损迁移，需要复杂完备的鉴权体系来保障高价值数据的安全，需要暴露代码的部署细节来支持工程师的优化客制，需要精打细算的计费逻辑来面对企业的成本考量和政府的招标竞争。
例如华为云对函数的鉴权Token需要先行调用其提供的Token获取接口来获取，并且需要配置IAM权限管理。
同时其对函数的依赖管理需要购买配置OBS服务或通过手动打包zip文件上传来实现
而腾讯云的代码完全对用户进行了暴露，面对纷繁复杂的框架代码、依赖代码让人有些束手无策
而阿里云的代码则需要使用第三方git库管理，在使用前需要配置完成git仓库
这些功能都是自由度的体现，能更好地满足产品的需求，但问题在于，开发的心智成本过高，对于个人开发者或者是学习过程中的新手来说，非常不友好
| 推广平台 | 曝光度 | 实际用户收益 |
|---|---|---|
| 小红书 | 152阅读量14赞+收藏 | 0无法引流 |
| 微博 | 3阅读，带链接被限流了 | 0 |
| 抖音 | 358播放量 5赞+0收藏 | 0 无法引流 |
| CSDN博客 | 34阅读 | 无法统计 |
| 微信推广 | 发布推广信息后，文档阅读量增加约130 | 13人加入微信群2人表达使用期望，但无行动 |
最终的用户统计结果
- 项目介绍文档阅读人数/阅读次数：144人/208次
- 实际注册用户数：12人
- 实际函数创建数：12个
- 已函数总访问次数：@鲁文澔
【待展示】
二、团队亮点
| 成员 | 角色 | 个人博客地址 |
|---|---|---|
| @鲁文澔 | Dev+Ops+PM | https://blog.csdn.net/LGJ1617026914?type=blog |
| @张峻源 | DevOps+Test | https://blog.csdn.net/weixin_45757456?type=blog |
| @咸永飞 | Dev | https://blog.csdn.net/qq_52042480?type=blog |
| @孙靖懿 | Dev | https://blog.csdn.net/weixin_46653352?type=blog |
| @杜品豪 | Dev | https://blog.csdn.net/aaicy64/ |
| @徐楚鸥 | Dev+Test | https://blog.csdn.net/bonny0510 |
| @刘骁 | Dev | https://blog.csdn.net/weixin_46473364?type=blog |
项目有完善的文档吗，是否有约定代码规范？
Python仓库约定的代码风格为black，并使用mypy、black、flake8等工具执行代码检查和格式化，约定每个非私有函数必须提供注释（未完全执行）。
项目文档部分使用sphinx构建，目前仅包括主要模块的部分API：
项目是否有出现代码混乱，没有注释，没有详细文档的问题？明年的同学继续开发这个项目，会不会出现以上抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？
存在部分函数没有注释的问题。针对部分函数没有注释的问题，我们认为不会出现开发或理解上的困难，因为该部分代码行为单一、内容简洁且可读性佳。对于新同学指导的问题，我们在代码仓库的README.md中提供完善的环境配置，开发工具链使用的指导，也在构建的文档中设有该部分。并在utility/文件夹中提供部署时的依赖安装脚本，极大的简化了用户环境配置的流程与时间。
项目是否有单元测试，测试用例数目，代码覆盖率等。
我们使用pytest进行单元测试，并使用coverage生成单元测试报告。我们的测试用例数目为
| 模块 | 条数 |
|---|---|
| log | 9 |
| user | 29 |
| monitor | 1 |
| 总计 | 39 |
代码覆盖率最终为90.31%，其中alpha版本尚未完善的log和monitor模块是覆盖率偏低的部分。
项目是否采用了CI/CD，并说明理由（可选）。
项目集成了三类CI：
- 代码风格检查类：使用flake8, mypy, black等工具进行代码风格检查。自动化的检查有助于开发者形成良好的代码风格，并及时修改。
- 代码质量检查类：使用codeql工具静态扫描代码中可能出现的bug。使用codeql这类代码质量检查工具，可提前发现潜在的代码漏洞等问题，有助于开发者写出高质量的代码。
- 单元测试集成：运行Pytest，Coverage，并使用codecov工具自动生成并提交报告。运行pytest、coverge自动化单元测试流程降低了开发者的负担，同时使用codecov工具自动报告单元测试结果，让每一个提交PR的人都永远不会忘记—写单元测试！！！！！！！
CD部分暂时未纳入考量范围，beta版本可考虑。
除了CI/CD之外，由于github Action比较耗时。我们也曾考虑过使用git pre-commit hook工具在本地提交时进行如代码风格检查的工作，但由于依赖仓库位于github，而git的代理配置不是特别友好，因此我们放弃了该方案。全面转向github Action。
学到的经验和教训：整个团队在Alpha阶段学到了什么，对软件工程有什么样的经验教训，Beta阶段有什么大体计划？
- 不可以对仓库的代码质量过于放松。在敏捷开发后期，因为进度问题，我们放弃了之前养成的写注释的好习惯。这加大了不同同学对于同一份代码的协商代价，也进一步拖慢了我们的开发速度。
- 不同模块需要不同的负责人把控，且负责人之间需要经常沟通。我们开发伊时时，前端和后端是两组人员分拨开发，沟通的桥梁仅限于API文档，所提出的问题也仅围绕API文档展开。这样的模式在前后端联调时出现了大问题，由于前期具体细节的沟通不足，导致前后端对对方的功能预期以及各自的运行流程出现偏差，造成牛头不对马嘴的尴尬境地，增加了联调同学的负担。
Beta阶段我们希望进一步提升工程的质量，并做到以下要求：
- 严格遵守“怎么起名都不对”团队口头约定的《代码质量开发与规范协议》，不允许任何同学以任何借口绕过该协议进行开发，保证良好的代码规范和代码质量，降低后期部署与维护的成本。
- 加强建设不同模块间的沟通，建立以模块—负责人一一对应的责任制度，负责人做到对模块内部方向有见解，对模块外部的实际情况有把握，实现软件开发工程的协调。
团队使用飞书来进行协作，通过飞书群组、云文档、飞书会议等工具来实现分工与协作交流
- 飞书群组聊天
- 协作文档列表以及评论与提及信息
通过飞书的评论功能进行沟通
通过文档的提及功能指派任务owner
- 飞书妙记会议记录
-
代码管理
-
本项目使用微服务架构实现，各模块单独作为一个服务来运行，所以也有其独立的仓库，我们主要采用Gitlab和Github两个平台来托管我们的代码。如此我们的人力就可以拆分为各不同的开发小组，针对单一模块同时进行开发。
-
- 计算资源管理模块
- 用户管理模块
- 代码与镜像管理模块
- 前端
- 触发器模块
-
燃尽图
其中4.21号的进度倒退是由于发现触发器并没有之前设想的那样简单，现有产品还是有一些无法满足的需求，需要我们自行编写，导致了工作量的增加，不过好在在1人·日的工作量内完成了触发器功能。
| 成员 | 角色 | 量化工作 | 贡献分 |
|---|---|---|---|
| @鲁文澔 | Dev+Ops+PM | 容器管理、镜像管理、触发器三个模块，提交Go代码16000行；Mysql/Redis/RabbitMQ部署，Docker与Kubernetes部署与配置；功能规格书、技术规格书、7次会议博客、发布说明等博客 | 53 |
| @张峻源 | DevOps+Test | Python开发框架、相应配置工具搭建与整理，仓库维护，CI/CD，分支合入管理，总计13个PR，3k+行代码。测试样例设计与实施包括：前端测试、场景测试、性能测试、压力测试等测试计划。近百余个测试样例，汇总BUG并撰写测试报告。日志功能容器内组件编写 | 52 |
| @咸永飞 | Dev | 用户管理模块设计，邮件发送功能用户管理模块代码Review前端；后期Bug修复与项目完善Nginx规则配置，前端部署用户管理模块部署 | 51 |
| @孙靖懿 | Dev | 用户注册、登录、修改密码等用户功能的后端实现，提交代码1700行最佳实践中个人博客、邮箱摘要整理、NLP应用等案例设计实现，提交300行代码功能规格书中典型应用场景设计 | 50 |
| @杜品豪 | Dev | 前端框架搭建，引入react-router按需加载以及local-forage本地存储等，提交jsx等代码约2400行。功能页面编写，调研引入Monaco-Editor(提出了2个被否决的选题) | 49 |
| @徐楚鸥 | Dev+Test | 前端用户认证部分编写、主页设计编写部分测试文档 | 48 |
| @刘骁 | Dev | 日志查询部分代码及相应单元测试编写资源监控查询部分代码和相应单元测试编写 | 47 |
三、总结与反思
在开发上，Alpha版本的功能计划大致完成（85%），由于后期前端与联调的延期风险，日志模块的集成与测试推迟到Beta版本进行。
在Alpha阶段中，开发部分主要遇到的问题有以下几个
- 误认为微服务架构的并行开发是银弹，没有对模块之间的依赖关系的解决进行设计，导致开发过程中的并行性不足。
- 将前后端分离后仅依靠API文档进行对决，没有更细致的功能和体验上的聚合，导致了认知的偏差
- 模块内的分工不够明确，出现了一定程度上的重复劳动
同时不可否认的是，我们采取的模式虽然由于缺乏实践经验未达到预期的效果，但仍然在开发过程中起到了正向的作用：并行开发的模块让开发小组能够更专注地开发其对应模块的功能，针对业务场景进行设计。而小组内的合作也让具有开发经验的同学与开发经验并不那么足的同学能够结对开发。
在本次开发的过程中，在管理存在的问题就是，PM的工作并没有很好的完成，对于前端进度的跟进不足导致了后续联调时较仓促，后续版本应该确定全职的PM，对项目进度进行管理以及相关小组间协调沟通。
对于toC的业务主打一个流量为王的战略，所以我们尝试了一些常用的流量平台进行宣传推广，例如小红书、微博、抖音等平台。曝光率数据比较满足需求，但是由于这些平台对于外链的要求十分严格，阻碍了流量引入我们的平台，导致转化率并不高。
发现这一问题后，我们采用了微信群聊、朋友圈的形式进行了推广，为我们引来了一些用户，但是由于时间较晚，用户量并不可观。
在Beta版本部分，应该转换思路，提供一些为校内程序设计课程的功能，提前与老师沟通推广，提高有效用户的数量。
在用户体验上，相对于我们的竞品来说，我们算是不错的，主打一个简单好上手。
但是对于例如触发器配置、函数信息修改、代码版本更新、代码创建等部分的用户体验没有那么直观与自然。
对用户体验的优化应该作为Beta版本中的一个工作进行。
我们对于Beta版本的规划主要从以下四个部分着手
- 用户体验部分
- 选定UX设计师，优化用户体验，修改上述部分的操作逻辑，让用户使用起来更自然。
- 优化主页逻辑，在主页更直观明了地展示我们的优势与实践
- 尽快落实域名审核，域名对于宣发的价值很大
- 新增功能部分
- 完善Alpha版本未完成的日志和监控功能
- 增加Nodejs与C语言的支持
- 提供一个持久化存储的功能，暂定KV或文件
- 人员分配部分
- 重构人力安排，其实并不需要那么多Dev，将人力分散到UI/UX、PM上
- 将人力分配到文档上去
- 宣发准备部分
- Alpha版本对公众平台的宣发尝试存在一定的失败
- 在Beta版本在域名落地后可以尝试进行一些SEO优化
- 尝试与校内课程合作，争取校内用户支持
