《软件工程》微信抢票应用 迭代二 个人总结

Posted 2020-08-17

　　通过为期两周的微信抢票应用迭代二，我对一个django工程的各个方面都在后端小学期的基础上有了进一步加深的理解，同时感到一个成功工程的诞生是多么的不易。

　　整个工程可大致分为几块内容：功能开发，各种测试、部署上线和文档展示，每个方面都值得一说。

　　功能开发方面，完全是参照文档中给出的前后端接口要求和微信网页中“帮助”页面中提到的所有功能，不过一开始对整个工程没有概念，接手框架时对这个庞然大物不知所措。也曾试过想认真阅读代码，可读了一阵之后发现没有任何目的的阅读完全没有效率，尽管大多数代码行的含义一目了然，可还是根本不知道它们组合起来想要干什么。以至于刚一上手连代码在哪里写都不知道。后来向室友各种请教一番之后，终于知道了入门所在，开始以自己的理解编写各种接口，现在想来，完全是照猫画虎，只知道就应该这样写，却不知道写出的接口在哪里用、写的不对会有什么后果。等到实现的接口在手动测试时出现了各种各样问题之后，才逐渐明白哪里调用了这个接口，为什么这个接口需要这些输入，以及这些输入如何给定。实现所有基本功能后，我们又新加入一项celery异步队列提醒用户抢票功能，这同样还是“询问同学＋文档＋Google＋小测试”生成新功能的模式。

　　说到各种测试，我主要负责性能测试部分。当时使用了3种配置：本地debug模式，本地release模式和服务器release模式，前两个用于“测试”性能测试是否起到了应有的作用，最后的是实测。刚开始在本地debug模式下的测试让我十分寒心，连100并发的错误率都勉强没有超过10%，更不要说500并发了。后来不知从哪里听说在发布状态下进行性能测试效果会好，于是又赶紧搞部署，好在对没有图形界面的服务器端操作还算顺利，性能测试后效果有了很大提升。再后来想用celery异步队列优化抢票行为，结果发现在好不容易不破坏数据库锁的情况下加入异步队列后，效果反不如从前，在这里耽误了时间也只能算是个教训了。

　　部署碰到最大的难题就是静态文件找不到，究其原因还是settings.py中的STATIC_URL设置成了“／”而不是“／static”，导致在nginx.conf中通常使用的"location /static {}"失效，这个bug也是找了好久才找到，本来想改STATIC_URL，但是发现所有的前端模板中都将该路径写死了（而不是使用推荐的{{STATIC_URL}}写法），更改极为不易，因此只得把nginx.conf中的"location /static {}"改为"location /{}"，但是这样一来又和本应该包含"uwsgi_pass"和“include”的区块有了冲突，因为该区块也是"location /{}"，又加一番修改才算是彻底解决这个问题。

　　展示部分，感到短短4分钟内想要把自己完成情况、功能亮点、测试结果、各种踩坑经验教训等统统展示出来，真的有些顾此失彼。纵观各个组的展示连同我们的展示一起，似乎也只有极少数的组能同时将上述内容全部提及但又不敷衍。展示是一门学问，也是一门艺术，尚需好好总结学习。

　　我感到这次工程的涉及面极宽极广，从前端网页、手机端微信交互，到后端逻辑处理、数据库访问、加锁，再到服务器部署优化，将一个宏观的网络应用架构投射到一个微观的小项目中，切实体验了一把真正的开发。尽管时间紧张，有些地方不尽如人意但也无法改正，但总的来说收获颇丰，就是此次微信抢票应用开发的最大意义所在。