半点优化网 http://www.bdxc.net/
当前位置首页 > 网站技术问题> 正文

为什么感觉用Ubuntu写代码麻烦呢?

2022-06-04 12:26:26 暂无评论 202 网站技术问题 程序员   写出   对此

用好的ide就会不一样了

这个与自己菜不菜没关,只是两个系统不一样而已,windows是什么都给你弄好了,你只管用就好,linux是需要自己去理解该怎么做,至于怎么做是你自己的自由。

为什么程序员写出的程序都有bug?对此你怎么看?

谢邀~

程序出现BUG,几乎是不可避免的,我在程序员这个行业也摸爬滚打十多年了,还没有见过写代码保证不会出现BUG的大神,那么程序员编程出现BUG的原因是什么呢?咱们一起分析分析:

内因出现问题,首先还是要找找自身的原因,在整个软件开发流程的每一步,都可能会出现BUG。

需求理解有问题:软件开发的本质就是把需求变成代码,如果需求理解有问题,这就意味着第一步就迈错了。

设计有疏漏:代码开发之前,需要想清楚流程是怎么样的,哪里需要判断,哪里有分支,如果在设计过程中,一些业务点没有考虑掉,那肯定会造成很大的缺陷。

编码不合理:首先在开发本次需求的时候,难免有不合理的地方,而更为恐怖的是,开发一个新功能,老功能不好用了;改了一个BUG,又出来三个BUG。

自测不充分:很多程序员敲完代码之后,简单测试一下代码,就扔给测试人员了,而并没有做好自测,特别是单元测试、集成测试用例,也很少有人编写。

外因自我检讨做完了,也得发发牢骚,找找外部的原因。

开发时间紧:最常见的一个问题,“这个下周必须上”,“周五必须提测”,这种话也听得不少了,在这么短的时间内开发完成,必然会造成设计、开发上的问题。

需求不确定:这是造成产品经理和程序员“打架”的主要原因,有的时候需求不明确,需求人员都没有想清楚;有的时候是需求变化快,能有多快呢?按照需求A开发,开发到一半的时候,需求已经变了...

只测试表面:有些公司的测试人员,在测试过程中只测试页面,而不会关注接口、日志、数据库中的内容。

人员流动率高:一个产品经理/开发/测试人员刚对这个系统熟悉,就离职了,只能再招一个“新手”,在他成长起来之前,需求/开发/测试方面的工作一定是不充分的。

如何改善其实知道造成BUG的原因,也就很容易知道如何降低BUG率了。

需求把控:产品、开发、测试多方要充分沟通,保证对需求的理解是一致的;

设计和开发过程考虑充分,把控代码质量,做好代码Review;

充分做好测试,包括开发人员和测试人员,利用自动化测试工具,避免“开发新功能影响老功能”的问题。

给开发、测试留出合理的时间;

稳定团队,降低人员流动率。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。

从事编程也有些年头了,也算是在编程领域见过世面的,就没见过没有bug的程序,程序的功能越多越容易出bug,所以外行人特别不理解程序员整天忙活些什么东西,东西写完直接提交不就可以了嘛,为什么整天加班,天天盯着电脑还有这么多事情没搞定。

这是外界对于程序员工作不理解一个典型的表现,程序员在开发功能模块的时候,设计框架的时候还是要尽量减少bug的出现,同时还要能够避免一些不可能事情的发生,所以越是顶级的高手,越是不轻易下手搞代码,几乎要把所有的事情都想通了,觉得差不多了,就开始大量代码写作过程中了,其实真正写代码的时间只占总时间百分30都不到,大部分时间是在设计和调试bug的过程中。

即使再厉害的程序员也不能把所有的技术细节都想的面面俱到,而且在现实中留给程序员的开发时间少的可怜,所以有些程序出问题其实不一定是程序员本身造成的,现在很多互联网公司已经形成的惯例,一周至少发布一次版本,甚至一周两次版本的发布,很多时候快到下班点的时候,产品经理过来说有个新需求要加,今晚就要发布版本,通常这种情况比较多,好在互联网公司大部分属于应用级的开发,多少还能经得起折腾,如果是每天伤筋动骨的折腾产品早晚出问题。

有很多搞笑的程序员玩个佛祖保佑的注释其实这东西起不到什么作用,就是程序员玩的一个小游戏而已,不修改bug就不是程序员了,程序员和bug是鱼和水的关系,谁都离不开谁,所以工作中脱离开了bug,基本上意味着脱离程序员岗位了,作为开发多年的程序员尝试分析下为什么程序员离不开bug,或者讲如何减少bug的出现?

1.良好的代码习惯,在写代码的时候就把一些可能存在的问题屏蔽掉,减少警告代码的出现,积少成多很容易出问题。

2.写代码的时候尽量保证自己意识的清醒的,注意力高度集中的情况下出问题的概念会大大降低,尽量熬夜加班写代码的时间,有时候一个很小的细节就能导致程序运行出问题。

3.在有时间的情况下可以写写单元测试,保证单个模块功能的稳定性,很多程序员觉得很麻烦,一旦出了问题再去补救这个时间成本将更大。

4.注释尽量写的清晰,有些人当初写的代码,到后来再去看的时候根本看不出当初的设计思路,证明当时在写代码的时候并没有完全理解通透,如果加上几句关键的注释很可能看一眼就能知道为什么要这么去做了。

5.充分理解功能需求,吃透需求就能减少冤枉路,很多人为了赶时间还没彻底明白咋回事就着急写代码了,这种最容易出错,要明白提出这个需求具体场景是什么,在设计模块的时候就能做到有的放矢。

相对来讲优秀的程序员出的bug会少一些,新手程序员更加容易出问题,作为一个程序员要懂得在解决bug过程中让自己成长。

希望能帮帮到你。

猜你喜欢