我是 Ben McMorran，一个在伍斯特理工学院学习计算机科学的大三学生。 在过去的 XNUMX 周里，我在教学 (TNL) 团队担任软件工程实习生。 这是我在 edX 实习的第二个暑假。 虽然我在这里工作期间完成了许多任务，但我想强调两个主要项目。
团队的 API 和前端开发
我参与的第一个项目是 LMS 的 Teams 功能，该功能仍在开发中。 此功能将使学生更容易在小组中相互联系和交谈，并增加 edX 课程的病毒式传播。 此功能的开发包括使用前端工作 骨干 和 API 实现与 Django 休息框架 (DRF)。 虽然去年夏天我通过改进课程发布工作流程熟悉了 Backbone，但 API 工作对我来说是新的。
在整个开发过程中，人们非常关注创建解耦、可重用的组件。 这方面的一个例子是我们为团队和主题列表设计分页控件的方式。 我们开发了几个 通用的、可重用的分页控件 兼容DRF返回的页面信息：
如上图所示，这些控件在未来的开发中将很容易与其他 edX API 端点集成。
此 可扩展字段 我创建以支持 Team API 是可重用代码的另一个示例。 作为初始请求的一部分，客户可以指定他们想要更多信息的字段。 例如，对团队信息的请求可以指定应扩展用户字段。 然后，响应将包含有关团队中每个用户的详细信息，而不是仅提供用户名。 这减少了客户端必须发出的请求数量，或者在不需要字段时减少响应的大小。 通过将字段指定为可扩展字段，可轻松与任何 DRF API 集成 可扩展字段 并为折叠和展开状态提供序列化程序。 随着 edX 平台的发展，对可重用组件的关注只会变得更加重要。
讨论论坛 性能改进
我还花了几个星期来改进我们论坛的性能。 我们使用 New Relic 来监控运行 edx.org 的服务器。 今年夏天早些时候，监控捕获了一条痕迹，显示在一个特定的课程中发表评论需要 40 多秒，促使进一步调查。
我将有问题的课程加载到我的本地开发环境中并尝试发表评论。 分析显示，服务器大部分时间都在发出分析事件，其中包括讨论的主题（如果适用）。 讨论组件的主题提供了一种过滤和分组讨论线程的方法。 例如，内联讨论组件中的所有线程都具有相同的主题。
在讨论应用程序中，评论是根据评论服务使用的讨论 ID 创建的。 但是，特定评论的讨论主题作为课程的一部分存储在讨论模块中。 讨论模块知道它们关联的讨论 id，但是如果您只知道讨论 id，就没有有效的方法来获取讨论的主题。 有问题的课程有近 1000 个讨论模块。 创建加载的分析事件 每一个 发现讨论话题！
我的第一个想法是在讨论 ID 上添加一个索引。 这被证明是有问题的，因为 edX 平台中的课程有几种持久性机制（旧 mongo、拆分 mongo 和 XML 课程）。 使用新索引将需要进行重大更改。 相反，我创建了一个 将讨论 ID 映射到相关模块. 此映射在课程发布时缓存在 MySQL 数据库中。 由于课程数据很少更改但经常被访问，因此通过遍历整个课程来构建映射的相对较高的成本是可以接受的，因为它不会经常发生。
实施修复后，我需要通过负载测试对其进行验证。 这个过程对我来说是全新的。 虽然它本身并不具有挑战性，但我花了一段时间才跟上进度。 我运行了现有的论坛 刺槐 在应用我的修复之前和之后针对有问题的课程进行测试。
在修复之前，在半小时的负载测试中创建评论大约需要 20 秒。 请注意，在加载课程中的每个讨论模块时，分解表中的大量 MongoDB 查询 1320。
修复后，在半小时的负载测试中创建评论大约需要四秒钟。 注意 MongoDB 查询的数量现在只有 6.75。
响应时间快了大约五倍，并且 MongoDB 查询的数量在修复后大大减少。 它现在位于 edx-platform master 分支中，应该很快就会部署到 edx.org。
总结
我作为 edX 实习生的经历非常棒。 融入 TNL 团队，感觉就像我是一名全职员工。 我能够拿到真正的门票，并看到我的工作对平台的影响。 开发一个开源项目真是太棒了。 我要感谢安迪·阿姆斯特朗、克里斯蒂娜·罗伯茨、整个 TNL 团队和 edX 让这个夏天变得如此美好！
