作为一名程序员,我渴望我加入的应该要是一支”30%的时间在写代码,而70%的时间在喝着咖啡讨论着如何将产品做的好”的团队。我觉得软件工作应该成为一项技术和艺术融合的高智力活动,我们的项目经理应该是一个高度理解质量,范围和进度客观规律的明白人,“高效工作,快乐生活”才应该是我们的座右铭。
可现实情况却是,团队在一边超负荷的做着需求,一边改着没完没了的错误。过点前夕,项目经理熬着通红通红的眼睛盯着我们整晚整晚的加班、质量专员一遍一遍的催促质量数据还不够,软件工作已经无可挽回的沦落成了体力劳动,别说快乐生活,生活都没了。
好吧,以上可能都对,项目经理和质量专员是一个不懂客观规律并且毫无同情之心的大魔的头,让我们程序员们毫无尊严卑贱的活着。
只是,有句话憋了很久了:“醒醒吧,所有的这些,都是因为你的代码写的太烂,你制造了太多的虫子!”。你可能会抱怨这分明是需求变更太快,领导计划太紧导致的。嗯,听着挺有道理,但是要知道需求变更本身就是软件的客观规律,而领导要求进度,呵呵,你也可以认为是客观规律。
所以 <强>陕西优就业小编今天就给大家分享一些实实在在的经验和方法。让大家多看一点就多获得一点实际的价值。也可加入我们的 <强> 强,和大家一起学习探讨。更重要的是还有免费学习资料分享。
1,不要一上来就开始写代码
你可能性子急,也可能早已按耐不住跃跃欲试昨天刚学会的一个编程小技巧,我想要告诉你的是,不急,收起你那磨刀霍霍的表情,在你拿到需求准备写出你第一行代码之前还有更重要的事情要做。我想怎么强调这件事情的重要性都不为过,在我以前写的自己非常满意的代码经历中,我都采用了这个方法,它能消灭原来可能会被测试提的90%的缺陷单,甚至做到零缺陷,当然做到这点可能需要一个过程。
拿到需求之后你首先要问下自己对需求是不是已经充分理解了,得到肯定的回答之后,我们就可以开始了:
先在你忙碌的工作中,找出你能完全掌控的一个小时时间段,这一个小时完全属于你自己,保证这一个小时不会有任何打扰,或者任何能影响到你执行不下去这个方法的打扰。要记住这一个小时非常重要,比你后面要执行的所有活动的时间都重要,它绝对值得。
在第一张白纸的上方写下“该需求特性的正常流程和影响范围”,然后在白纸下方逐条开始写下该需求特性正常流程包含的内容,大概会使用到哪些库函数,会提供出哪些接口,是否会影响版本升级,是否影响资源文件,是否影响原有的接口等等。
在第二张白纸上方写下“该需求特性所有的异常场景和本人以往经常会犯的一些错误点”,然后在白纸下方一条一条的开始往下写。
不断重复第2、3步。
你可能会觉得这不就跟写的需求澄清材料差不多吗,我要告诉你的是这是两回的事,它不是一项质量专员要求你做的质量过程活动,这是你自己和自己之间的一次深层次对话,这不需要告诉任何人,不需要向其他领域输出任何交付物,这是对自己要写出优秀代码的一次自我驱动。
一开始你可能会觉得很难,写几条就写不出来了,或者闪过“这玩意儿是不是真的有用”的念头,不用着急,起身去窗户边呼吸一口新鲜空气或者去打杯水喝,总之不要中断,除非办公室着火了不要去干让这件事继续不下去的事情。当你慢慢往下写到第20或者第30条答案的时候,你可能突然会有一种“这么隐晦的一个异常点都被我发现了,简直太牛了!”的情感涌出,这个时候你会暗暗惊呼有点难以抑制自己的兴奋,这说明你快要接近成功完成了,后面每写出来的一条都会让自己感动。记住,中间不要放弃,你坚持下去的决定会将这一个小时变成你整个需求实现当中最重要的一个小时。
2,忘掉后面还有该死的质量活动
所有编码之外的质量活动,都是基于公司对于你写代码水平的不信任产生的。也就是说公司花了大量的钱招来质量专员,网元测试,解决方案测试这些人都是因为你没把代码写好造成的浪费。
常见一些开发人员,刚来的时候对质量专员安排的质量活动颇有微词,“我以前公司做项目根本不需要做这些东西还不是一样能把项目做完”,“这些质量活动,简直就是对编码时间的侵占”。说这些都没问题,但是你一边说着这些一边写完代码后故障就乌泱乌泱上来,是不是有点不要脸?质量专员设计的这些活动,就是为了不让你的烂代码一泻千里的冲到客户面前设计的一个个检查站,当你对于“写出好代码”什么事都没做,只想着取消这些质量活动的话,就只能理解为耍流氓了。
