由于上一次通知的上线引来用户的一些不满，所以产品马不停蹄，在一轮又一轮的需求讨论中设计了下一版通知，希望尽快上线，我负责通知的后端实现，当时看到图后，有点小小的崩溃：时间太紧，难度很大，很多地方不属于通知。但是既然定下来了，就只能咬咬牙，拼一拼了。
于是接下来的 9 天，变成了一段难忘的回忆，基本上都是 3 点以后回家，第二天赶上免费的午餐后，继续 coding。最后一天还剩了些 bug，索性就不回家了，就这样勉强完成了新版的通知，但随后又被推翻，当时确实很愤怒，但细细想想确实有不少地方还不够到位，尤其是新通知的架构，作为责任人之一，以下是我的一些感悟和反思。
没有不可能
阿迪同学让这句话在全世界流行，但越是常见的东西，越容易熟视无睹。我们相信没有不可能，因为有太多的案例可以证明这句话，但要身体的每一个细胞都坚信这句话就很难了。只有在自己做了一些让后来的自己都不得不佩服的事情时，才会把这句话刻在心里。这样的事对我来说还太少了。
好的队友很关键
产品同学(ecvip)会把每个设计和交互讲解地很清楚，会陪着我们熬到很晚。前端同学(Dang & 骁哥)总是能高效地完成页面，思路很清晰，我总是觉得自己在拖他们的后腿。后端同学也就是我，估计是这个木桶最短的那块。还有就是 CTO 申申同学并没有过于责备这次的失败，而是要请我们撮一顿，那个感动啊。
需求是会变化的
我这次就是栽倒这上了，为了满足当前的需求而设计了对应的架构，导致后来需求发生变化时很难应对。在设计时就应该考虑到将来的可变性，尽量灵活。
多向别人请教
由于时间比较紧，加上自己理解上的偏差，在设计后端架构时没有与其他同学进行沟通，就直接进行代码实现。写着写着就觉得有点奇怪，但已经这样了，就只能继续按着现在的架构走。等到后来杨昆同学 review 代码时才发现：我靠，怎么成了这样。
升级自己的技能
海贼王里，每一次战斗，大家的技能都会有提升，越是大的战斗，敌人越强劲，技能升级地越高。在现实中，应该是在大的战役前做好充足的技能储备，打完战役后，总结哪些地方还需要继续提升和完善，接下来再有目的地去改进，避免在下次的战役中出现同样的问题。
