前言

极客大赛是我司举办的一个内部的挑战比赛，大致的内容就是拟定一道比赛题目，然后根据最后的完成度进行得分排名。比赛的时间为一天，大抵就是上班到下班这么长的时间。

今年的题目是完成一个票据识别的 app。核心的模块是票据的扫描、识别和后端的存储、统计功能。衍生的加分项就很多了，测试覆盖率、界面设计等等，差不多就是软件的综合完成度、用户体验这些。

时间的利用
比赛只有 12 个小时，但是在一些无所谓的事情上面浪费了很多的时间。
首先就是 leader 的推选。从传统的角度来看，不礼让一下确实会显得太傲慢，进而给别人以不好的印象，但是在有限时间的比赛中这是相当不智的，这直接导致了团队在接近 1/6 的时间里处于无领导无组织的状态，大家各干各的，效率很低。
任务安排
最终后端以双核驱动，我负责后端的整体规划设计以及任务安排。
首先，在选人上就出现了问题。开发伊始，让一人负责 api 设计。当时选人的角度是谁还闲着就让谁干，而不是谁更专业就让谁干。这导致的后果就是，api 文档不够全面、小漏洞频出。同时，在最后做演示的时候，无法根据那种一拍脑门想出来的 error_code 来判断具体是哪一块除了问题。（这里最后使用了经验判断，然后错了）
其次是项目进度的管理上。在 api 文档开发完成之后，后端、前端就可以开始开发了，但是这里忽视了重要的一点，就是测试。文档成形之后，理论上已经可以让测试来准备边界样例了，但是思维定势，认为在软件工程进程中，测试必须等到全端开发结束才能进行。很要命。这直接导致了负责测试的人员一直闲置到比赛结束。
最后是任务分派。在不熟悉每个人具体的擅长的情况下（仅仅是问过了前后端这些浅层的东西），就直接进行任务的分派，现在想来过于冒失了。
异常处理
1. 登录异常
  这次是使用的公司的登录接口，但是出现了一个很要命的问题，token 的预期生命周期与实际严重不符。比如设置生命周期为一天，而实际使用时可能一分钟就失效了。这个时候我们的解决方案是，使用公司内部的账号来实现永久性 token。
  这里忽略了很重要的一点，这是一个面向大众的 app，并不是每一个测试样例（实际可能是极少、甚至是没有）都是有永久性 token 的，这种解决方案无疑是饮鸩止渴。这在最后的测试时，大家意识到这个问题的时候，已经病入膏肓、为时晚矣。
  在面临这种问题，首先要做的应该是查阅接口文档，找出出现这种异常的原因，以及对应的解决方案。如果自己找不到，应该及时询问接口的提供方，不要浪费太多的时间。
2. 部署异常
  这与时间分配也有一定的联系。项目最后，我需要将后端部署到服务器上。由于时间紧迫，以开发环境部署到服务器上之后就直接开始对接测试了，后来也是直接以开发环境部署到服务器上的。
  这是非常致命的，因为在面临高并发的请求时，很容易造成服务崩溃，并且无法再起。之所以这么草率地以开发环境部署，是因为前端一直在调用接口测试，事态不容许停下服务进行生产环境的调整。
  但是这并非没有解决方案，我有不止一台的服务器，完全可以在另外一台上做好对应的调整，然后直接应用到比赛服务器上。
  这算是一个教训吧。
技术层面
这次主要使用的技术是 flask，主要的问题有两个。
1. 性能优化/代码质量
  这两者本来关系不大，但是在本次的开发中耦合度很高。
  处于时间的考虑，所有的交互都是使用 POST，所有的存在复用的代码都是直接复制粘贴，没有使用蓝图来做规划，简化了框架的结构(这可能不算是缺点，但是这种尝试太冒险了)。
  总的来说，写了一个仅仅是能够跑起来的，自己都看不下去的代码。
2. 单元测试
  “程序员写代码不需要测试，只要能运行就行了。”这本是一句调侃的话，但是我却下意识地忽视了测试的重要性。这次的单元测试没能跑通，很大原因可以归咎于平时的疏懒。

这次比赛给我的启发同样巨大。这算是第一次，与一群各有一技之长的伙伴们开发(以往是 python*n，这次的队伍中，实到 8 个人，有 JavaScript、python、node、C++、运维、nginx 等各方面的开发者)一个独立完整的项目。前后端分离、多语言服务中请求的流转、运维要点等等这些以往一知半解的东西，在这次的比赛中都有了实际的应用案例。这也与就是进入企业进行开发的魅力所在吧。仅仅 12 个小时，虽然不足以实现技术上的突飞猛进，但是让我发现了职业生涯中更多的前进的方向，也不失为一笔宝贵的财富。