程序员为什么不能一次把功能写好，是因为他不想吗

引言

交流一下为什么他做的功能这么多Bug

大家好，最近看到一个有趣的问题：

程序员为什么要不能一次性写好，需要一直改Bug？

在我看来，程序员也是人，并非机器。

拿这个问题去质问程序员，答案无非那么几个。

1.需求的理解

有时候，在项目一开始，需求可能并没有被完全理解清楚。

随着项目的推进，更多的细节可能浮现，需要对代码进行调整以适应新的或更清晰的需求。

首先需求的传递，通常有以下几种：

• 
  
• 口头传递：程序员可能无意间听到策划的一句话，就认定为需求就是这样。
  
• 需求会议：这是笔者认为比较正式的，相关人员一起，进行需求的分析和探讨。
  
• 临时加的：前面提需求的时候遗漏的，后面补的。
  
• 非工作日加的：在非工作日休息时，收到经理或者老板的电话需求。
  

这里面都涉及人与人之间的交流和理解。它是极其容易受到人的状态和情绪影响的。

可能因为程序员在理解需求时较真策划无意或者有意的一句话。

也可能因为程序员在会议过程中打瞌睡或者不以为然。

甚至在程序员情绪不满的状态下接到了需求。

2.功能的复杂性

许多功能都涉及复杂的业务逻辑、数据处理和用户交互。

在理解整个功能如何运作的过程中，程序员可能会对功能的梳理不够清晰，导致一开始的实现可能考虑得不够完善。

相信大家都清楚，无论是大功能还是小功能，都会有Bug。

但是在相对复杂的功能下，Bug会更加容易出现甚至更多。

笔者认为这和人生的选择有点相似，越是关键的选择，越难选择。

3.新的内容

在项目迭代过程中，可能需要引入新的功能，他可能与项目框架或者方向完全不同。

这必然会导致程序的稳定性受到影响。

越是底层的内容，在修改时引发的内容变化就越容易，影响的面更广。

这里面可能新的内容与旧项目完全不搭，强行要引入这样的内容，在设计层面就不对。

也可能是因为程序员考虑不当，没有更加全面的考虑到策划或者经理的变化。

4.时间的压力

项目通常有时间限制，导致程序员可能不得不在有限的时间内完成任务。

这可能导致在一开始时忽略一些潜在的问题，需要在后期修复。

迫于时间的压力，程序员往往会不断地跳过遇到的问题，往更容易完成的方向去执行。

那么这些卡点会被放到功能的最后处理，这和我们以前考试是相类似的。

老师教导我们，在考试遇到困难的问题时，先跳过，等到试卷做完一遍之后回来再看难题。

但往往问题也会出现在这些跳过的内容，要么难题还是难题，做不出来。要么就是给到这些难题的时间已经不多了。

5.功能的耦合

在团队协作的环境中，不同部分的代码可能同时被多个程序员修改，可能导致冲突和Bug。

此外，不同模块之间的复杂交互可能在测试之前难以被完全预测。

这种问题通常表现为，A程序员修改的项目的A功能，但是出乎意料的的是B程序员的B功能出了问题。

这里面就涉及框架和项目的耦合情况，越是耦合严重的代码（通常被称为"屎山"），你的修改越是不能一干二净，出乎意料地影响了其他功能。

6.硬件和环境变化

程序可能在不同的硬件和环境中运行，这可能导致一些未考虑到的问题。

为了适应不同的环境，可能需要进行一些修复和调整。

大家知道用户的使用环境可能千奇百怪。

首先设备环境就分为好几种，原生的Android，iOS，网页的H5，还有PC和小程序。

其次不同的网络环境，2g，3g，4g，5g和wifi。

程序员在开发时以最好的网络，最好的机器，去到用户的千元机，万元机和老人机的时候表现都不尽相同。

怎么解决

一把需求给你，你就那么多问题，都是不能解决的吗？

笔者认为事实并不如此，人是会进步的，通过不断的总结和优化，能逐步减少Bug的产生，但是不能杜绝。

• 
  
• 需求理解：程序员与策划/经理的关系要融洽，工作时沟通和交流不要存在个人情绪和意见。认真对待每次需求会议。
  
• 功能的复杂性：程序员与策划/经理要一同考虑功能的复杂性，策划与经理不能一味地提需求而不考虑复杂性，程序员不能一味地实现功能不考虑功能的变化。
  
• 新的内容：程序员要仔细评估新内容对旧项目的冲击，策划/经理要认真考虑，这个功能是不是真的合适项目。
  
• 时间的压力：更合理地评估功能的完成时间，拒绝不合理的降本增效。
  
• 功能的耦合：不断提升代码能力，学习更加优秀的写法，应对不同需求的变化。
  
• 硬件和环境变化：加强不同环境的测试，这里面要考虑的是不同环境测试的便捷性，不断优化测试环境，不要让测试困难导致了Bug的产生。
  

结语

不管是程序员还是策划还是经理，沟通是减少问题的关键，而不是质问。

在哪里可以看到如此清晰的思路，快跟上我的节奏！关注我，和我一起了解游戏行业最新动态，学习游戏开发技巧。