您所在的位置:主页 > 行业资讯 >

新手程序员如何做到代码没有缺陷

时间:2018-01-30 14:57来源:未知 作者:os 点击:

  新手程序员如何做到代码没有缺陷

  程序员往往渴望加入的是一支“30%的时间在写代码,而70%的时间在喝着咖啡讨论着如何将产品做好”的团队。软件工作应该成为一项技术和艺术融合的高智力活动,而项目经理应该是一个高度理解质量、范围和进度客观规律的明白人,“高效工作,快乐生活”才应该是程序员的座右铭。

  可现实情况却是,团队在一边超负荷的做着需求,一边改着没完没了的Bug。过点前夕,项目经理熬着通红通红的眼睛盯着我们整晚整晚的加班,质量专员一遍一遍的催促质量数据还不够,软件工作已经无可挽回的沦落成了体力劳动,别说快乐生活,生活都没了。

  好吧,以上可能都对,项目经理和质量专员是一个不懂客观规律并且毫无同情之心的大魔头,让我们程序员们毫无尊严卑贱的活着。

  只是,有句话憋了很久了:“醒醒吧,所有的这些,都是因为你的代码写的太烂,你制造了太多的Bug!”。你可能会抱怨这分明是需求变更太快,领导计划太紧导致的。嗯,听着挺有道理,但是要知道需求变更本身就是软件的客观规律,而领导要求进度,呵呵,你也可以认为是客观规律。

  这不是一篇证明谁导致程序员加班太多的论证文,也不想给大家灌鸡汤,让大家一夜之间都变成编程高手,但是至少说一些实实在在的经验和方法。总之让大家多看一点就多获得一点实际的价值。

  一、不要一上来就开始写代码

  0?wx_fmt=gif&wxfrom=5&wx_lazy=1

  你可能性子急,也可能早已按耐不住跃跃欲试昨天刚学会的一个编程小技巧,我想要告诉你的是,不急,收起你那磨刀霍霍的表情,在你拿到需求准备写出你第一行代码之前还有更重要的事情要做。我想怎么强调这件事情的重要性都不为过,在我以前写的自己非常满意的代码经历中,我都采用了这个方法,它能消灭原来可能会被测试提的90%的Bug单,甚至做到零缺陷,当然做到这点可能需要一个过程。

  拿到需求之后你首先要问下自己对需求是不是已经充分理解了,得到肯定的回答之后,我们就可以开始了:

  1)先在你忙碌的工作中,找出你能完全掌控的一个小时时间段,这一个小时完全属于你自己,保证这一个小时不会有任何打扰,或者任何能影响到你执行不下去这个方法的打扰。要记住这一个小时非常重要,比你后面要执行的所有活动的时间都重要,它绝对值得。

  2)在第一张白纸的上方写下“该需求特性的正常流程和影响范围”,然后在白纸下方逐条开始写下该需求特性正常流程包含的内容,大概会使用到哪些库函数,会提供出哪些接口,是否会影响版本升级,是否影响资源文件,是否影响原有的接口等等。

  3)在第二张白纸上方写下“该需求特性所有的异常场景和本人以往经常会犯的一些错误点”,然后在白纸下方一条一条的开始往下写。

  4)不断重复第2)、3)步。

  你可能会觉得这不就跟写的需求澄清材料差不多吗,我要告诉你的是这是两回事,它不是一项质量专员要求你做的质量过程活动,这是你自己和自己之间的一次深层次对话,这不需要告诉任何人,不需要向其他领域输出任何交付物,这是对自己要写出优秀代码的一次自我驱动。

  一开始你可能会觉得很难,写几条就写不出来了,或者闪过“这玩意儿是不是真的有用”的念头,不用着急,起身去窗户边呼吸一口新鲜空气或者去打杯水喝,总之不要中断,除非办公室着火了不要去干让这件事继续不下去的事情。当你慢慢往下写到第20或者第30条答案的时候,你可能突然会有一种“这么隐晦的一个异常点都被我发现了,简直太牛了!”的情感涌出,这个时候你会暗暗惊呼有点难以抑制自己的兴奋,这说明你快要接近成功完成了,后面每写出来的一条都会让自己感动。记住,中间不要放弃,你坚持下去的决定会将这一个小时变成你整个需求实现当中最重要的一个小时。

  二、先忘掉后面还有该死的质量活动

  所有编码之外的质量活动,都是基于公司对于你写代码水平的不信任产生的。也就是说公司花了大量的钱招来质量专员、网元测试、解决方案测试这些人都是因为你没把代码写好造成的浪费。

  常见一些开发人员,刚来的时候对质量专员安排的质量活动颇有微词,“我以前公司做项目根本不需要做这些东西还不是一样能把项目做完”,“这些质量活动,简直就是对编码时间的侵占”。说这些都没问题,但是你一边说着这些一边写完代码后Bug就乌泱乌泱上来,是不是有点不要脸?质量专员设计的这些活动,就是为了不让你的烂代码一泻千里的冲到客户面前设计的一个个检查站,当你对于“写出好代码”什么事都没做,只想着取消这些质量活动的话,就只能理解为耍流氓了。

  那么,做好质量活动就能“写出好代码”吗?答案是不能。质量活动只是质量专员的监管手段,它既不是目标甚至也不是方法,你写代码的目标不是要满足质量活动标准,而是要追求零缺陷,也不会因为你Wbit测试做的好就能写出好代码。你要做的一个是“不要一上来就开始写代码”,另外一个就是掌握尽量多的重构方法,重构思维方式,掌握重构并不一定是要对原来代码的重构,而是下笔之前就知道好代码该怎么写。

  我让大家忘记质量活动,不是让大家不听质量专员的话,而是大家在写代码的时候要心中存有敬畏,代码写完之后所有的活动都是你造成的浪费,你要为消除这些浪费而竭尽全力。

  三、你要记住,你写的代码是给人看的

  好的代码是让人看来赏心悦目的,任何能力不够或者炫技成分的增加人的阅读障碍的行为都需要被改进,你能不能三两句话就能说清楚你自己写出来的代码的脉络,当然这同样涉及到你要掌握尽量多的重构方法和重构思维方式。

  另外还有一个自我评判的标准,就是你扪心自问一下,“你写了这么多代码,你曾经为之动心过吗?”你是否写完之后会忍不住的反复阅读自己写完的代码,并连连暗暗惊叹代码之美?

  作为一名程序员,希望在你某天离开公司后回想起的若干个开心时刻中,有一个会是因为你面对自己刚刚出炉了一份让自己心动的代码的那份感动,而不要成为上面提到的那个“离开后,公司才知道他有多么重要”的家伙。

  四、现在开始,刻意练习

  你是否发现自己长期维持着“刚刚好能完成story”的代码水平,写了好几年代码仍然会被测试人员追着屁股提单?种种疑惑是因为代码能力的提高跟你写了多少年代码没有直接关系,你需要做的是刻意练习。

  比如把我前面提到的方法反复练习,或者把你自己琢磨出来的方法分解成一项项的环节,刻意的去练习,从测试那里得到反馈,然后不断加以改进,慢慢你就会从一个整天被测试人员追着跑的人,变成发现自己很容易就能达到质量过程标准的人,再慢慢就会发现你写出来的代码测试人员越来越难发现问题,最后只要你状态好点就能经常性的写出零缺陷的代码。

  其实有些道理我们貌似都知道,但是我觉得离真正懂得还差了两步,第一就是你需要亲身去经历、践行这些道理和方法,第二就是你要能够转述并让其他人也能够明白。所以最好的学习方式就是亲身经历,然后写下来分享给大家,这样才能让你真正懂得那些你原来认为懂得了其实未必懂得的道理。

 

  成为一名合格软件工程师的7点建议

  在过去5年多的时间里,我在科技初创公司中任职过不同岗位,也在学术界短暂工作过。在这些不同角色中我学到了一个观点。我慢慢意识到一些原以为无关紧要的事情的重要性。这篇文章是根据我的个人经验,针对刚入行的年轻工程师的一些建议。

  第一印象很重要

  一份新工作要有一个好的开端。不要迟到, 不要当混球, 别一上来就说我们需要抛弃公司正在用的框架。

  抵制住那些试图证明自己的诱惑, 会有更好的, 更谦逊的方式。请继续读下去。

  知道如何做出好的估算

  业务和技术之间沟通的一半都是确认需求和工作量估算。

  工作量估算归结为两点: 你认为什么时候能完成,以及你对那个日期有多自信。

  这是一个你需要从经验中磨练的技能,但我有两个秘诀:

  工作量越大,估算就越难。我总是把一个大的任务分成更小的部分,每一个有1-3天的工作量。

  如果你说要花一个星期,他们会问: “好的,你能在3天内完成吗?”要时刻准备为你的估算辩护。

  负责任

  负责一个服务。负责一个领域。理解服务背后的业务原因。

  发现问题并开始改进,一点一点地改进。别幻想在最后时刻扭转乾坤。

  你可能需要一段时间才能感觉到自己完全掌握它。我想这有点像收养一只流浪狗,刚开始对它有点感觉,但随着时间的推移,你会越来越了解它。

  如果你的服务出现故障或发现一个严重的bug - 停止手上的工作,无论是多有趣或无聊,马上修复它。这是基本的职业道德。这不容易,成熟后才能理解。你需要慢慢适应。

  有些事情会发生并可能影响到你的服务,你需要时刻关注它们。

  例如,你的服务在等待另一个人在开发的的功能。要么客气地催促他,要么自己去做。努力设法推进工作。

  在有趣和重要之间取得良好的平衡

  有趣的工作是那些在智力上具有挑战性的工作。例如算法优化、数据结构设计或人工智能。这肯定会提高技术水平。它可能会也可能不会改善你的服务。

  重要的工作是那些公司给我们工资要我们做的事。例如与业务伙伴的系统集成或者调整营销模板, 使它们在各类设备上都很好地显示。

  有时候,最重要的工作不是最有趣的。

  我们是工程师,我们活着是为了解决难题。然而,我们必须在做有趣的事情和重要的事情之间取得平衡。

  在深度和广度之间取得良好的平衡

  年轻的工程师希望对软件工程有一个全方位360°的视角。

  不要陷入你是个前端开发(或后端,或运维)的陷阱。至少要在一定程度上了解所有这些领域。

  别误会,你会想要专注于某一行。不过,我的观点是确保在一定程度上掌握其他方面的知识。因为从长远来看,这将帮助你成为一个更好的工程师。

  请记住,没有前端工程师或后端工程师这样的东西。只有工程师。工程师的工作是解决问题,所以要做到这一点。

  你的老板想要你做什么?

  细节会因工作和公司而异,但不管你在哪里,有些事情都是一样的:

  没有人喜欢一个爱发牢骚的人。不要因为他们让你“更新15个不同模板的措辞”就抱怨,或吐槽任何其他种类的粗活。抱怨越多,你会发现你的同事比你在事业上发展地更快。你不想每一次都做这些工作,但是除了抱怨之外,还有更好的方法来得到更好的工作。

  完成任务。“完工了,就等着合并到主分支(master)了”,这意味着工作还没有完成。合并到主分支并部署到预生产/生产环境。你的老板会很感激你,如果你说“完成”就代表确实完成了。

  了解与你领域相关的关键数据。它会给人一个深刻的印象,你确实了解你的领域。是的,这也适用于软件工程。不用说,捏造数据是你能做的最糟糕的事情。如果你不知道就直说,然后说“给我10分钟查一下”。

  你的老板不希望你做什么?

  当一个重大问题出现时,不要隐藏。直接告诉你的老板, 有些事情不正常,你正在处理。告诉业务在解决此问题之前,你不能进行任何其他的工作。

  对任务不要过度承诺。如果你认为业务给你的工作可以在3天内完成,承诺他们6天,而不是2天。因为总会有其他的事情出现,它们会花掉你5天时间。但是你答应了他们要6天,这意味着你仍然“超过预期”,因此你很“擅长估算”。

  最后的建议

  不要_删除_生产环境数据库。