交流一下为什么他做的功能这么多Bug
大家好,最近看到一个有趣的问题:
程序员为什么要不能一次性写好,需要一直改Bug?
在我看来,程序员也是人,并非机器。
拿这个问题去质问程序员,答案无非那么几个。
有时候,在项目一开始,需求可能并没有被完全理解清楚。
随着项目的推进,更多的细节可能浮现,需要对代码进行调整以适应新的或更清晰的需求。
首先需求的传递,通常有以下几种:
口头传递:程序员可能无意间听到策划的一句话,就认定为需求就是这样。
需求会议:这是笔者认为比较正式的,相关人员一起,进行需求的分析和探讨。
临时加的:前面提需求的时候遗漏的,后面补的。
非工作日加的:在非工作日休息时,收到经理或者老板的电话需求。
这里面都涉及人与人之间的交流和理解。它是极其容易受到人的状态和情绪影响的。
可能因为程序员在理解需求时较真策划无意或者有意的一句话。
也可能因为程序员在会议过程中打瞌睡或者不以为然。
甚至在程序员情绪不满的状态下接到了需求。
许多功能都涉及复杂的业务逻辑、数据处理和用户交互。
在理解整个功能如何运作的过程中,程序员可能会对功能的梳理不够清晰,导致一开始的实现可能考虑得不够完善。
相信大家都清楚,无论是大功能还是小功能,都会有Bug。
但是在相对复杂的功能下,Bug会更加容易出现甚至更多。
笔者认为这和人生的选择有点相似,越是关键的选择,越难选择。
在项目迭代过程中,可能需要引入新的功能,他可能与项目框架或者方向完全不同。
这必然会导致程序的稳定性受到影响。
越是底层的内容,在修改时引发的内容变化就越容易,影响的面更广。
这里面可能新的内容与旧项目完全不搭,强行要引入这样的内容,在设计层面就不对。
也可能是因为程序员考虑不当,没有更加全面的考虑到策划或者经理的变化。
项目通常有时间限制,导致程序员可能不得不在有限的时间内完成任务。
这可能导致在一开始时忽略一些潜在的问题,需要在后期修复。
迫于时间的压力,程序员往往会不断地跳过遇到的问题,往更容易完成的方向去执行。
那么这些卡点会被放到功能的最后处理,这和我们以前考试是相类似的。
老师教导我们,在考试遇到困难的问题时,先跳过,等到试卷做完一遍之后回来再看难题。
但往往问题也会出现在这些跳过的内容,要么难题还是难题,做不出来。要么就是给到这些难题的时间已经不多了。
在团队协作的环境中,不同部分的代码可能同时被多个程序员修改,可能导致冲突和Bug。
此外,不同模块之间的复杂交互可能在测试之前难以被完全预测。
这种问题通常表现为,A程序员修改的项目的A功能,但是出乎意料的的是B程序员的B功能出了问题。
这里面就涉及框架和项目的耦合情况,越是耦合严重的代码(通常被称为"屎山"),你的修改越是不能一干二净,出乎意料地影响了其他功能。
程序可能在不同的硬件和环境中运行,这可能导致一些未考虑到的问题。
为了适应不同的环境,可能需要进行一些修复和调整。
大家知道用户的使用环境可能千奇百怪。
首先设备环境就分为好几种,原生的Android,iOS,网页的H5,还有PC和小程序。
其次不同的网络环境,2g,3g,4g,5g和wifi。
程序员在开发时以最好的网络,最好的机器,去到用户的千元机,万元机和老人机的时候表现都不尽相同。
一把需求给你,你就那么多问题,都是不能解决的吗?
笔者认为事实并不如此,人是会进步的,通过不断的总结和优化,能逐步减少Bug的产生,但是不能杜绝。
需求理解:程序员与策划/经理的关系要融洽,工作时沟通和交流不要存在个人情绪和意见。认真对待每次需求会议。
功能的复杂性:程序员与策划/经理要一同考虑功能的复杂性,策划与经理不能一味地提需求而不考虑复杂性,程序员不能一味地实现功能不考虑功能的变化。
新的内容:程序员要仔细评估新内容对旧项目的冲击,策划/经理要认真考虑,这个功能是不是真的合适项目。
时间的压力:更合理地评估功能的完成时间,拒绝不合理的降本增效。
功能的耦合:不断提升代码能力,学习更加优秀的写法,应对不同需求的变化。
硬件和环境变化:加强不同环境的测试,这里面要考虑的是不同环境测试的便捷性,不断优化测试环境,不要让测试困难导致了Bug的产生。
不管是程序员还是策划还是经理,沟通是减少问题的关键,而不是质问。
在哪里可以看到如此清晰的思路,快跟上我的节奏!关注我,和我一起了解游戏行业最新动态,学习游戏开发技巧。
我是"亿元程序员",一位有着8年游戏行业经验的主程。在游戏开发中,希望能给到您帮助, 也希望通过您能帮助到大家。
AD:笔者线上的小游戏《贪吃蛇掌机经典》《填色之旅》《重力迷宫球》大家可以自行点击搜索体验。
实不相瞒,想要个赞和在看!请把该文章分享给你觉得有需要的其他小伙伴。谢谢!
推荐专栏: