1. 程序员为什么要一直改bug 不能一次性写好吗
程序写代码就像造一座大楼,如果即便经过严格的设计论证,装配高质量的部件,最后还有系统性地验收,让你去造这么一座大楼,你能保证不管是窗户安没安好,还是地基挖浅了挖深了,还是墙皮脱落,都一个问题没有?
回想早年的小程序,执行某一个具体的任务,明确的输入输出,一般是不会有bug的。
但现在的软件开发,早就已经不是一个人在战斗了,大部分的工程,开发规模5人左右居多,另外稍大的软件工程动辄几十人,更有甚者几百人的团队规模并行作业。你试想一下,要保证这么多人的产出都符合设计要求,势必需要合适的开发流程,需要更多的项目管理的技巧和方法。这就对个人以及团队的提出了非常高的要求了。
软件工程的方法论中,要求软件开发者尽可能多地在软件测试阶段发现bug,而不是交付之后。
但是楼主说的能不能让软件开发出来没有bug,我觉得把下面这几个事情做好,还是有可能的。
1、花尽可能多的时间,和客户沟通软件需求,了解每一项需求的用意。
2、确保软件需求不能随意变动,因为很多情况下一个需求的变化,程序会带来很多问题,有可能连底层结构都需要跟着一起变动。频繁的需求变动,加上开发周期和成本的约束,带来的结果就是软件质量的不可控。
3、确保软件测试质量,完成全覆盖测试,设计系统需要的全部用例并保证全部通过。
总结下,软件项目在实际开发过程中风险点还是很多的,通过合理的控制,可以降低和减少bug。但是软件本身是为人的需求而生,只要需求在变化,软件是永远都需要跟着去维护和更新的,所以只要有不可控的因素(需求分析,系统设计,系统详细设计,编码,单元测试,集成测试,系统测试,验收等)任何一个环节任何一个人产生问题,反映到最后的软件产品上就是一个bug。
另外Bug分很多类,一类是对用户来说不能正常使用,能被用户感知到的错误。一类是用户能正常使用,但是有各种异常的错误。一类是使用没有任何问题,但是不符合产品预期的问题。其他应该还有很多,这里我们一一讨论。
对用户来说不能正常使用,能被用户感知到的错误。
其中一种情况是程序员和测试人员的问题,所有功能在上线前,工程师和QA人员应该测试,回归完功能。能被用户感知到使用流程有问题的话,一定是相关人员能力或者线上意识某一方面欠缺,也是最不能容忍的。
另外一种情况是黑天鹅事件,什么网线被挖断,机房被炸,服务器爆炸什么的。。。。。。 ,这个说实话,出了在软件架构上做冗余,目前没有什么特别好的办法。
2. 用户能正常使用,但是在用户看不到的地方有各种异常的。
一个功能模块几乎不可能是独立的,它必然牵扯到其他模块。对于你所依赖的模块,你没办法保证这些模块是100%可用的。这个时候可能虽然有错误,但是只要不影响主要流程,我们依然可以正常使用。但这个时候对于外部依赖的异常处理,很考验工程师的能力。
举个例子,有可能你看到的点赞数比你实际收到的点赞数少。这个是由于点赞统计在什么时候失败了一次,某些用户可能认为这个是bug,但是其他可能不会在意(当你有10001赞的时候,你在意少了1个么?)
3. 使用没有任何问题,但是不符合产品预期
这个更多的是研发和产品经理对于需求理解的不一致。因为文字是有二义性的,况且人和人对相同文本的理解本来就可能出现偏差,这就导致了需求理解的不一致,最终导致了线上产品不符合预期。对于内部人员来说,这个也算BUG。
说了那么多,最主要的核心在于实现功能的是人。人不像机器,不可能不犯错;同样的,不可能存在没有bug的程序,像大家使用的windows,穷尽无数优秀的工程师,给予用户优秀的桌面体验的同时,也有你可能完全看不到的数千个bug。想要完全避免几乎是不可能的。所有也不存在一次性就写好的情况,鬼知道产品经理什么时候改需求呢~
2. 评“程序员怎么样才能保证自己的程序没有BUG”
复核代码的目的有:
* 检查代码是否规范,如命名规范,注释
* 保证一段代码至少有两人共同熟悉,可以由任一人来更改。
* 审察未文档化的细节设计,即由代码直接表达的设计,由代码人口述设计并对照代码
我认为程序员永远都不会有100%的自信。
即使程序已经发布,被用户接受很长时间,只有好评没有抱怨,依旧不能确认有没有错误。
只能假定错误是永恒的,它们一直在那里,只是不到条件爆发。
一个程序员能做的就是,排除所有肤浅的错误,加大隐藏错误出现的几率并找到它们,
采用一些容错性代码减小可能的错误,减少程序发布后爆发的机率。
测试的目的是为了发现错误,
没有100%覆盖的测试。就是说,总是有一些状态是测试不到的。
代码人员认为不可避免地存在错误,需要测试,测试人员认为测试覆盖度不可能100%,还是要代码小心。
这是一个头痛的问题,结果是没有完美的程序。
单元测试是白箱测试,可以根据代码实现将注意力放到最关键的部位。
但仍然不是100%覆盖的。
单元测试一般针对的是边界数据,不要求覆盖度,而更要求有效性。
其目的更主要的是保证代码更改不会破坏原有的正确性,是提供保障而不是查找故障。
保证没有错误的唯一方法是不写代码,减少错误的最好方法是少写代码。
简单的设计和实现是减少错误的最佳方法。简单的代码错误必定少。
画蛇添足式的功能则是最大的错误发源地。
3. 你见过最厉害的程序员是怎么样的
以前曾经做过十余年的编程,见识过不少程序员,其中有两位是比较厉害的。
第一位,J同学,非科班出身,粮食专业毕业的,之后在一个食品厂工作,因为比较清闲,于是他突发奇想,想考某个211的计算机研究生,就去买了书来看,但是要实践啊,他又没有计算机,就有空总去公司的电脑室蹭机器用,电脑室的人,就让他帮忙开发一个工资管理系统,不知道是不是想为难他,结果他研究生是没考上了,但是经过一个月的摸索之后,居然把工资系统给做出来了。让电脑室那些科班毕业的人脸上挂不住啊!
之后他就斗胆去了一个国内知名的企业应聘程序员,居然还给应聘上了,慢慢做到了华南区的技术总监,再后来他几个同事出来创业,高新挖走他。
他这个人就是传说中的怪侠,非常低调,朴素,不按时上班,不按时下班,工作效率非常高,爱抽烟,请教他什么问题,他一时想不出来的话,就去外面抽根烟,烟抽完了,回来就会有答案,反正非常神奇。
第二位,B同学,科班出身,211大学计算机研究生,当时是他的导师跟我们单位有来往,推荐过来的,我面试的他,惜话如金,听说他C语言非常厉害,但是当时我们做项目需要PB,他说他不会,我就说,那给你一个星期的时候,你回去学习一下,再来面试。一个星期后,再过来,给他一个小模块,很快就做出来,非常棒,之后,项目的技术难题,大部分都是他解决的。平时,他也不怎么跟我们来往,但是有事就做,也不打 游戏 ,按时上班,按时下班,非常讨厌加班。
遇到技术问题,下班后打电话给他,他不接的。有一次,我们第二天系统要上线,大家都在忙着测试,加班,他到点就走了,领导追到电梯门口,问他,XX哥,你走了,他说了一个字,是,就进电梯了。后来也是被高薪挖走,听说到现在40岁也还没结婚。
我们公司有一位非常厉害的程序员,基本上一个人当做一个排兵力使用。也就是说一个人写代码的效率基本上抵得上10+人的能力,一年随随便便写个几十万高质量的代码。这种人对编程语言的理解已经到了登峰造极的地步,且能够灵活自如地使用。
在自己编码能力强的同时,对架构的理解能力也是超强,一个大的系统能够很快地进行模块拆分,快速的定义不同模块间的交互接口,可以快速的安排任务下去。
另外代码的质量基本上没地说,导致跟着他的测试人员几乎发现不了Bug,这哥们在写代码的同时基本上顺手就把单元测试写好了,代码质量高的简直出奇。
当然了,至于学习什么新的开源框架或者新的技术架构,基本上就是2-3天的功夫,就可以全面掌握。
目前为止,公司一直当做宝一样供着。
我见过最厉害的程序员,是在2001年入职的一间香港电路板公司的电脑部经理,他也是最值得我尊重的程序员,那他最厉害的地方在哪里呢?
编程语言只懂Foxpro DOS版本,但所有的ERP流程,英文、管理方法说得滴水不漏,有一次和财务的同事聊天,才知道他的月薪达8万多。
很多程序员最怕大老板提问题,但在他的眼里,大老板提问题就是一个商机,多多少少都要老板加工资加设备。 高情商的表现就是无论下属或老板通通管理得服服帖帖,包括我自己,甚至老板还没有说话就己经知道老板的心思了。
老板分配的编程任务应期三天完成,绝对不过4天。软件开发效率的提高,自然要依赖下属心甘情愿的加班付出才行,做到这一点,真的是难能可贵。
最厉害也是我最佩的一点就是,40多岁了头发还没有一点白的迹象,每天高效率的工作,下班后就抛开工作的烦恼,尽情桑拿按摩享受。
我认为最厉害的程序员不是编程技术,而是如何利用编程技术,不知道你认不认同?
应该是读研时的学长,精通java和Python,毕业后进去微软研究院工作。
当时和他在一个项目组,他独立完成了教学平台语言分析模块,NLP 模块。我们团队任何问题都能很快给出解决方法,前端后端都擅长。
当时我刚接触linux,他就已经把Linux作为工作学习唯一的选择。经常用terminal 操作,敲起代码太帅了
诚邀,本人在杭州华为研究所工作,之前在一家创业公司工作过,公司里一个工作10年的大神,撑着整个创业公司,老板总能拿到某些项目源代码,不同语言的,c c++ .net java总之很多,给他,一礼拜就可以全懂了,所有语言基本都是1礼拜搞定(玩代码的都知道精通一门语言后学其他的特别容易,不外乎面向对象的,面向过程的,然后就是各种API )上手做项目,之前很多不懂的问题问他都可以从本质上分析得很明白,主要是基本上看几眼就可以知道哪里错了。或者大概方向,我后来去华为,都是他建议的,现在还在那公司的他听说是技术总监了,应该不怎么敲代码了。
核心的代码总是有那一两个程序员来实现的。比方说现在微信的一开始的核心代码。
比方说Linux的核心代码, 都是由林纳斯·托瓦兹编写的, 并且为了能够让开源社区的人一起进行开发, 又编写了Git版本控制。当你不满意某个软件或者系统的时候, 能够自己实现并制作出更好的也许就是厉害的程序员吧。一直到现在很多的系统分支都是来源于Linux的内核。
最后如何成为最厉害的程序员, 还是要学习基础核心的知识, 操作系统, 数据结构, 算法, 编译原理, 计算机网络, 在这个基础上学习编程都是为了更好地实现自己的心中所想。为什么这样写, 这样写会产生什么效果。 为什么Golang最近这么热, 为什么鸿蒙会被看好, 它又和其他的有什么区别, 就可以自我判断, 而不是见风就是雨。
最后希望自己也成为那个最厉害的程序员。
很久以前,我用win98的时候有次我系统崩溃了,因为我是电脑白痴,我朋友给我介绍了一个高手来帮我修电脑。
他看了一下电脑,问我有没有98的盘,我说没有。
他想了一下,叫我把固定电话拿给他,我想修电脑要电话干什么,但人家是高手,我也不好说什么,就把电话拔下来给他了。
他把电话线空着的一头接在电脑的一个插孔内,然后进入dos,就开始在电话上不停的按着键,他按键的速度异常快,但是只按0,1两个键,我搞不懂这有什么用,但也不敢问,看了半个多小时,他还是不停的按这两个键,我徐徐的有些困,我问他这东西要搞多久,他说要几个小时,我给他倒了杯茶,就一个人去隔壁睡觉了。
醒来的时候,一看已经过了4个多小时,我起身到隔壁,看见他正在98里面调试,过了一会儿,他说,你试试,我坐上椅子用了一下,真的好了,我当时也不懂电脑,谢过人家就走了。 后来我慢慢对电脑有了了解,终于了解,原来当时那位高手是用机器语言编了一个98系统,我后来问我朋友那位高手的下落,我朋友说前几年去了美国之后,杳无音讯....
五年前有幸在一家软件公司做产品经理。小的软件公司。坐标西安。招人还挺不好招的。虽然给的薪水还不错。但是真心不好招人。这种小软件公司没有名气。真正牛逼的人都不来。
百试几百人,包括做产品和前端的也算在里面。光程序员这块。有百分之六十的投简历的都是从某培训机构出来的。所以的项目经历。和待过的公司都是一模一样,有明显的人为的痕迹。
但是后来实在没有人手。招了一两个,差。差。差。真是差到极点
后来又经人推荐,招了一个,说是做安卓开发的。结果连个软件的心跳包都调不好。软件的升级这块都搞不定。最后还是我这个外行,逼着他。一点一点卡,才把软件升级这块稍微搞上路了。
说出来真是让大家笑话,华为的外包中软国际。有个孩子实在忍受不了里面的虐待,在里面工作了一年半。然后跳到我们公司。这个孩子,才是稍微让人可以用一下。就是起码。你给他的工作。他能完成。其他的人都是在摸鱼。因为这个公司的老板以前也不是做手机软件这块。没有资源,不认识人。
他是做电脑PC软件,到后面做BS系统多一点。其实这种没有技术含量,找的别人的框架。去修改。
普通人见不到最牛逼的程序员,最牛逼的程序员,一定是在最牛逼的软件或者互联网公司的深宫后院里面。还没出世的。就像当初的张小龙,史玉柱,裘伯君一样。
你现在能看的牛逼的,感觉牛逼的。都是因为你不懂这个。你才觉得牛逼。包括前几年比较活跃的黑客们,制造一些病毒。这都不是牛逼。包括熊猫烧香的李俊,普通人觉得他可牛逼了。但是真正的他出来后,去金山 360这种公司,提鞋别人都不要。
因为搞破坏不是牛逼。也不是自己水平有多牛逼。
我来讲一个我见过最厉害的程序员。
这个程序员是我第一份工作碰到的大牛,我的第一份工作在中兴通讯成都研究所,当时是做操作系统研发的。
我们当时经常会做一些培训和技术分享,那时候我才入职3个月,我发现公司里有个人每次技术分享时候,就很多人去听,并且会议室爆满,连站的地方都没有,然后我有次也去听了一下, 第一每次目睹大牛的风采,因此操作系统是最底层的研发工作,会涉及到内核这块知识,而linux内核知识特别抽象,看书根本很难看懂,但是这个大牛能把很难的东西讲的很容易理解,并且在会上面对大家的提问总是能对答如流,实在是厉害。
而后我通过公司里的老员工才了解到,这位大牛是自学成才的,他的文化程度才初中,破格录取到中兴通讯,当时是操作系统部门的技术专家,他都能自己编写操作系统,对各硬件都非常了解,也出了很多书。可见兴趣是最好的老师,让他能够在程序员中发光。
必须是ACM大神,楼天成,楼教主。不了解他的可以网络之。是个天才一般的存在。
几年前清华大学找同学玩,他那时是清华软件学院的学生,突然说要带我去见他的偶像,还说是最后的机会了,我们跑去计算机学院,当时博士正在答辩,通过在场的同学找到了他,他很腼腆的千呼万唤始出来。他们两在那里交流了半个多小时,最后互留了EMail,我跟他聊了些我专业的内容,他还蛮好说话。 后面还通过这位同学认识另一位ACM届大神,上海交大的戴文渊。我对编程略有了解,主要还是崇拜天才。
4. 如何向 程序员 描述 bug 笑话
1.程序员写出自认为没有Bug的代码。
2.软件测试,发现了20个Bug。
3.程序员修改了10个Bug,并告诉测试组另外10个不是Bug。
4.测试组发现其中5个改动根本无法工作,同时又发现了15个新Bug。
5.重复3次步骤3和步骤4。
6.鉴于市场方面的压力,为了配合当初制定的过分乐观的发布时间表,产品终于上市了。
7.用户发现了137个新Bug。
8.已经领了项目奖金的程序员不知跑到哪里去了。
9.新组建的项目组修正了差不多全部137个Bug,但又发现了456个新Bug。
10.最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。
11.公司被竞争对手恶意收购。收购时,软件的最终版本包含783个Bug。
12.新CEO走马上任。公司雇了一名新程序员重写该软件。
13.程序员写出自认为没有Bug的代码。
5. 程序员写程序时,有哪些减少bug的好方法
深有体会,肺腑之言:
晚上10点之后千万不要写代码,每次我这个时候写代码总会左眼睁着右眼闭上,右眼睁着左眼闭上,我表示10点之后写代码那是开玩笑。虽然有时后不是很困,然后自我感觉很良好,但是,但是,第二天自测,或者QA测试的时候那就呵呵。。。写代码5分钟,查bug俩小时。
写代码前可以自言自语,或者写在纸上。把要做的东西说一遍,理清楚了再写。
写代码千万不能着急。领导催,pm催,那也是急不来的。必须按照平时的速度,一步一步的来,心浮气躁,心神不宁的状态不能写代码。
写注释,写注释,写注释。重要的事情说三遍。代码就像天书(这点相信看过别人代码的人深有体会),而自己的代码呢,当时觉得清新易懂,过个两三天就不那么回事了。写上注释有利于后续开发的时候容易减少bug和定位bug
bug有很多种,语法上的,逻辑上的等等。对于语法错误,很好解决。使用集成的开发环境,一般都会有语法检查,高亮提示等功能避免产生。然后