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