程序员为什么要一直改bug ?不能一次性写好吗?

host 电商运营 592 次浏览 没有评论

选择蓝色药丸,故事结束,你将在床上醒来。

选择红色药丸,我就带你看看这个世界的bug。

有大量没有或者几乎没有bug的程序,比如超市的收银机中使用的程序,比如你购买的计算器中的程序等等。这些程序都有一个共同的特点,就是功能非常明确,用户的使用方式完全可以预测,同时程序总的来说相对简单。

但我们使用的更大型的程序,比如操作系统以及大型游戏程序,它们注定了bug重重,而且许多bug甚至只有在大量用户的使用过程中才有可能暴露出来,还 有一些bug只有当你“恶意”的使用软件的时候才会暴露出来,比如非法获取系统权限。要求一个复杂的大型软件,没有任何bug,那基本上是强人所难,简单 说就是这超出了人类的能力,而我们制造的用来开发这些大型软件的软件本身就不是完美的。但我们当然希望尽可能完美,因此在软件行业专门引入了软件测试工程师。并且,希望尽可能减少bug的数量,完美做不到,但趋近于完美是有可能的。

目前在软件测试领域中对bug出现的原因有如下总结,而除了软件开发行业之外,这些总结也同样有益,因为人类出错的模式具有相似性,所以不仅仅是程序有bug需要不断的修正,我们的社会何尝不是如此。

固有的复杂性

比如,为了方便用户而引入的图形化和操作互动,同时也是bug之源,但为了便利,我们只能忍受,并尽可能降低bug的数量。除此之外,大型软件中涉及到的许多工具,本身就不够完美,但我们还得使用它们,比如网络通信协议,同样不完美,但我们不能等到完美那一天才上网。

交流不够、误解或者没有进行有效交流

目的不明,不知道要实现什么功能不需要实现什么功能的情况下,就开始开发。

程序设计错误

和所有的人一样,软件开发人员也会出错。

开发中途,需求变化

需求改变带来的复杂性可能导致错误,还可能影响工程参与者的积极性。

时间压力

软件开发工具

如何选择合适的软件开发工具,能在保证完成开发的情况下,保持简单,并不是个容易的选择。程序员之间为了使用哪种开发工具更合适,可以爆发世界大战。

世界上第一个计算机bug,一只真bug。

1945 年9月,哈佛大学的 Mark II Aiken Relay Calculator的管理员,找到了影响这台原始计算机运行故障的原因,一只飞蛾。于是他将该事件写到管理日志中,并将该飞蛾也贴在上面,同时将bug 一词正式引入了计算机领域之中。 “First actual case of bug being found.”

10年码农,我来回答这个问题好像比较合适。

编程序写代码就像造一座大楼,如果即便经过严格的设计论证,装配高质量的部件,最后还有系统性地验收,让你去造这么一座大楼,你能保证不管是窗户安没安好,还是地基挖浅了挖深了,还是墙皮脱落,都一个问题没有?

回想早年的小程序,执行某一个具体的任务,明确的输入输出,一般是不会有bug的。

但 现在的软件开发,早就已经不是一个人在战斗了,大部分的工程,开发规模5人左右居多,另外稍大的软件工程动辄几十人,更有甚者几百人的团队规模并行作业。 你试想一下,要保证这么多人的产出都符合设计要求,势必需要合适的开发流程,需要更多的项目管理的技巧和方法。这就对个人以及团队的提出了非常高的要求 了。

软件工程的方法论中,要求软件开发者尽可能多地在软件测试阶段发现bug,而不是交付之后。

但是楼主说的能不能让软件开发出来没有bug,我觉得把下面这几个事情做好,还是有可能的。

1、花尽可能多的时间,和客户沟通软件需求,了解每一项需求的用意。

2、确保软件需求不能随意变动,因为很多情况下一个需求的变化,程序会带来很多问题,有可能连底层结构都需要跟着一起变动。频繁的需求变动,加上开发周期和成本的约束,带来的结果就是软件质量的不可控。

3、确保软件测试质量,完成全覆盖测试,设计系统需要的全部用例并保证全部通过。

总 结下,软件项目在实际开发过程中风险点还是很多的,通过合理的控制,可以降低和减少bug。但是软件本身是为人的需求而生,只要需求在变化,软件是永远都 需要跟着去维护和更新的,所以只要有不可控的因素(需求分析,系统设计,系统详细设计,编码,单元测试,集成测试,系统测试,验收等)任何一个环节任何一 个人产生问题,反映到最后的软件产品上就是一个bug。

发表评论

Go