讲动人的故事，写懂人的代码
程序员其实也想一次性把代码写好，不想一直改bug。
因为改bug属于计划外的工作，会让原来排满的工作计划完不成，领导又不允许延期，所以导致加班。
谁愿意加班呢。但下面的11个深层因素，让他们不得不一直改bug，也就是一直在加班。
这就是程序员的加班命！
1 业务的复杂性
软件开发往往是为了解决实际业务问题，而现实世界的业务需求通常复杂多变。
即使最初的设计考虑周全，随着业务的发展和市场的变化，原有代码可能无法满足新的需求，导致需要不断修改和调整。
比如，原来用户退出微信群，会在群里显示“XX已退出群聊”信息。
但后来产品经理觉得可以不显示这条信息，那么之前显示信息，就是bug了。
有人说，把这个当作新需求排入计划，不就不加班了？
理应如此。但有些急功近利的领导，会在要”摇摇领先“的愿景趋势下，把这个新需求，当作紧急bug，硬生生插入当前发布的变更列表。
但又不把其中相等工作量的某个其他变更拿掉做替换。
结果你懂的。加班搞呗。
2 架构设计的耦合性
在软件架构设计时，过度耦合会导致一个模块的改动影响到其他模块，从而增加了修改代码的复杂性和风险。
理想的架构设计应该是模块之间低耦合、高内聚，但在实际开发过程中很难做到完美。
程序员经常踩的坑，就是几个业务都合用一个数据库，导致牵一发而动全身。
比如改动了业务A的数据库字段且测试通过，结果上线发现业务B挂了。
为啥不测试业务B？
3 上线急迫与测试不足
在追求快速上线的压力下，可能会牺牲充分测试的时间，导致软件上线时存在未发现的bug。
此外，即使进行了测试，在时间压力下也难以覆盖所有使用场景。
比如测试人员经常抱怨开发3个月的项目上线前却只给他们1天时间测试。
这只是打比方，大概就是这么个意思。
4 测试场景不完备
由于现实世界的多样性和复杂性，很难设计出完全覆盖所有场景的测试用例。
这就意味着总有一些边缘情况可能在实际使用中被触发，导致bug的出现。
5 基础设施和配置的复杂性
软件需要在特定的基础设施上运行，这些基础设施自身的复杂性及其配置可能会引入额外的问题。
6 开发人员变动
团队成员的变动可能导致知识传递不完整，新成员对项目的理解可能需要时间，这也可能导致错误的产生。
7 协作问题
产品经理、开发人员与测试人员之间如果沟通不畅，可能会导致测试不充分或者对问题的理解存在偏差。
8 开发流程问题
如果需求分析、开发、测试、上线流程不够规范，或协作不良，就很容易造成漏洞或低效。
比如需求沟通不充分、测试资源不足、上线流程草率等，都会埋下 bug 祸根。
9 质量与进度的平衡
在项目管理中，质量、成本和时间是三个关键的变量。
往往在时间压力下，领导可能会牺牲软件质量以满足进度要求。
10 编程语言的限制
不同的编程语言有其优势和局限，比如C++虽然功能强大，但在内存安全和并发编程方面有一定的短板，这可能导致在使用这些语言开发软件时更容易遇到某些类型的问题。
11 最后一个原因，往往是人的因素
无论多么优秀的团队,总会因为时间压力、技术盲区、或其他人为疏忽而引入 bug。
毕竟人无完人，bug在所难免。
有朋友说，还有一个原因，就是“防御性编程”。
防御性编程就是程序员为了防止自己被炒鱿鱼，故意把代码写得只能自己理解，别人很难看懂。这样不就离不开他了吗？
但做过大型企业应用软件系统的人都知道，代码已经是“诗山”了，还有必要做防御性编程吗？
想想这些代码，寿命大多有10年以上，开发人员大多是外包。
这意味着代码已经不知道换了多少人的手。
每个人都只管自己负责的那块能跑通就行。
至于bug嘛，留给下一个接锅侠。
诗山代码就是这么来的。
如果你赞同我的观点，欢迎点赞和转发。
如果你不赞同，欢迎留言，说说你的看法呗。
