1.忍耐度不足,胸怀太小。对于延迟到最后一晚还在讨论如何正式配置,在反复讨论和变更需求,想到一出是一出的行为几乎忍无可忍。但忽略了别人也有别人的工作习惯和有自己的事情要忙,有自己的工作任务要完成,只考虑了自己的感受和需求,没有考虑到别人的苦衷。
2.自以为是。自认为需求要详细又全面,基本可以确定系统设计时的数据存储结构体,剩下的只是在表现上优化,却忘记了一个系统在设计和实现时本就会发生翻天覆地的变化,需求随时都会变,设计的数据存储结构随时会变,策划并不是神。
3.开发经验不足。或者说不自信,意识不到提前就将代码传上SVN,唯恐会影响到旧系统。没有按照自己的节奏进行。
4.沟通不足。和DB沟通不足,一直受到要先自己实现功能再找别人对接的智障理论(不知道什么时候脑海中有了这一条)影响,导致自己闭门造车已经写好了60%代码的时候,才通知DBA写过程,结果DB对需求一脸懵逼,光和他讲需求就花费3-4天,再等他写好工程,再调试,且DBA那里缺乏必要的验证工具,导致有些很低级的过程错误也要程序开启私服,开启客户端登入测试时发现,并再通知DBA修正。这些错误可能和程序中的Lua一样因为不是强类型语言,且很多错误在运行时才能检测到,或许还有DBA的个人因素,导致出错率高的离谱,有的一个工程要反复改几次。程序成了DBA的免费验错工具。DBA后来要改存储方式,很多字节的数据,只要修改一点点,就要全部写入DB,虽然并不知这样有什么优势,但出错率确实低了许多。如果开始就沟通好的话,直接用这种方式来实现,应该能节省下一周多一点的时间。
5.没有自主意见。完全按照策划的节奏进行,导致策划给的需求越来越多,到最后突然截止开发时间,又给出二十多张界面的资源,在将界面的资源都替换完后,又告知界面诸多优化,在诸多优化的同时,又告知诸多新的需求,到最后需要其他同事支援还在通宵的情况下才极其勉强的完成,这本身就说明了自己还处在一个码农的阶段,未将软件工程的开发模型应用到实际的开发过程中。
要知道在一个功能实现时,无论策划还是品质还是美术,他们都只是提供一些极其有限的资源,功能实现的主体就是程序,没有程序可以说一切都是0.而一个程序没有自己的开发节奏,本就是自己的问题。
程序应该像是设计模式中的适配器模式,不仅可以适配头脑清楚,需求详细,变更较少,积极推进的策划,也要适配需求模糊,反复变更的策划,这种适配不是让自己适配别人,切切相反,是让别人适配自己,根据自己的开发节奏,让别人按照自己的节奏来适配自己的节奏提供资源,保证功能或项目按照自己的节奏推进和实现,这样如果自己完不成任务自己可以适当的调整工作时间或者借助别人的力量,而不是陷入别人的“最后一晚”的噩梦节奏。
综上:自己还有很多地方需要改进,项目不单单是写代码,不是看基本重构和设计模式就万事大吉了,最终每个影响到项目在截止日期前最终实现的每个因素都应考虑在内。如果自己一开始就一个功能一个功能的让策划品质验收,在验收之时就按期想法优化完毕,且让其在验收后不得随意修改。我想最后也不至于在每天都在优化的基础上,在最后一天仍然有这么多东西要当天当晚实现,最终通宵加班。通宵加班并无不可,但如完全可通过行之有效的手段避免为何还要自残呢?自勉自励!!!慎之慎之!!!