如何判断一个程序员是真的“菜”，还是他在写“防御性代码”？

数据猿

发布于 2024-02-23 11:24:11

1750

文章被收录于专栏：数据猿数据猿

大数据产业创新服务媒体

——聚焦数据 · 改变商业

近期，互联网、软件领域普遍在进行较大规模裁员，在这种情况下，业界流传着一种说法，有些程序员在写“防御性代码”，来增加自己的谈判筹码。

那么，什么是防御性代码，怎么区分防御性代码，会带来哪些问题？这篇文章来分析一下这些问题。

防御性代码可以分为被动型和主动型

防御性代码，在传统意义上，指的是程序员编写的那些旨在处理程序中，可能出现的各种异常情况的代码。这种代码的目的，是使程序能够在遇到意外输入或环境变化时，仍然能够稳定运行，从而提高软件的鲁棒性和可靠性。例如，对用户输入进行验证、处理外部系统返回的错误数据等。这种防御性编程是一种良好的编程实践，被广泛推崇。

然而，近年来，特别是在技术行业裁员频繁的背景下，防御性代码的概念被扩展并赋予了新的含义。一些程序员开始编写代码，不仅仅是为了处理异常情况，而是为了在其被潜在裁员的情况下，增加自己的不可替代性，或者在离职后留下隐患，使得公司需要重新聘请他们来解决问题，这种做法引发了业界的广泛关注和争议。

具体来看，防御性代码可以大致分为两类：被动型和主动防御性代码。

被动型防御性代码，包括那些增加代码复杂性和维护难度的做法，目的是使得除了原作者外，几乎没有人能够轻易理解和修改这些代码。典型的被动型防御代码包括：

复杂代码：故意编写难以理解的代码，增加了其他开发人员的学习成本。

文档缺失：故意不提供或提供不完整的文档，使得代码的功能和设计理念难以被他人把握。

个人依赖代码：编写高度个性化的代码，使其维护和理解高度依赖于原作者。

性能降低代码：故意使用低效的算法或设计，使得性能优化变得困难，仅原作者能够“优化”。

日志混淆：故意使错误日志难以理解，增加问题诊断的难度。

主动防御性代码，则是那些被设计来在特定条件下激活，直接导致系统故障或数据损坏的代码。这类代码的存在通常带有明显的恶意，包括：

时间炸弹：预设时间触发的代码，可能会在特定时间导致系统崩溃或功能失效。

逻辑炸弹：当系统满足特定的逻辑条件时触发，如特定用户操作或数据达到某个状态。

隐藏后门：允许原作者在未经授权的情况下远程访问系统。

数据污染：故意编写的代码逐步破坏数据质量，可能长时间不被发现。

被动型防御性代码的问题在于，它们往往藏匿在看似正常的开发实践之下，难以被直接识别为恶意行为，而主动防御性代码则因其潜在的破坏性，而更容易被界定为恶意代码。

在技术日益成为企业核心竞争力的今天，理解和区分这两类防御性代码的区别，对于维护企业的软件质量和工作环境至关重要。

怎么识别出防御性代码？

在探讨防御性代码的世界里，我们面临着一个棘手的问题：如何区分一个程序员是因为技术能力不足，而写出了难以理解或维护的代码，还是故意为之，以增加自己的不可替代性？这个问题的答案并不简单，因为它触及到了编码技能、意图和项目管理等多个层面。

我们先来看看被动型防御性代码，这类代码的特点通常是过分复杂、缺乏文档、高度个性化，以及过度依赖特定编码风格或技术。在面对这样的代码时，区分它是出于故意设计还是技术不足的结果变得颇为困难。识别这种区别，通常需要深入了解程序员的工作历史、代码编写习惯，以及他们与团队的互动方式。

一名程序员如果历史上持续提交难以理解或维护的代码，且没有相应的改进努力或团队合作的证据，这可能暗示着他们故意采用这种做法，以增加自己的不可替代性。相反，如果这名程序员在其他方面表现出积极的学习态度、愿意接受反馈并改进代码质量，那么代码的复杂性或质量问题可能更多是能力和经验的限制所致。

此外，他们与团队成员的互动方式也能提供重要线索：如果他们积极寻求帮助、愿意共享知识和技术经验，那么可能就不是有意编写防御性代码。因此，管理者和团队领导需要综合考虑这些因素，以公正和准确地评估情况。

相对而言，主动防御性代码往往有一些更明显的标志，比如，代码中含有特定的触发条件，这些条件很少或根本不会在正常的业务流程中出现。或者，某些代码片段被隐藏或伪装得很隐蔽，显得毫无意义或与项目无关，但实际上含有潜在的破坏性操作。识别这类代码相对容易一些，因为它们通常需要特意设计并隐藏，以避免在常规的代码审查过程中被发现。

为了更好的理解防御性代码，让我们来看一个具体的例子。

想象一下，你是一家软件公司的项目经理，在进行代码审查时，你遇到了一段异常复杂的代码。这段代码是由一名资深程序员编写的，处理一个本应相对简单的任务——比如，用户登录验证。但是，这段代码使用了过分复杂的逻辑，涉及多层条件判断和对多个外部服务的调用，而且几乎没有任何注释来解释这些逻辑是如何工作的。

进一步的调查显示，这段代码中含有一些“隐藏的逻辑”，在特定条件下才会触发。例如，如果用户的登录尝试恰好在午夜12点发生，这段代码会引入一个额外的延迟，导致登录过程异常缓慢。这种情况在正常的测试中很难被发现，因为它需要特定的时间条件才会触发。

此外，代码中还包含了一些看似无关紧要的函数调用，这些调用对于完成登录验证来说并不是必需的。在深入分析这些函数后，你发现它们实际上是设置了一系列的“后门”，允许这名程序员在没有正确凭证的情况下，通过一些特殊的方法绕过正常的登录流程。

在这个例子中，这名程序员故意编写了复杂和难以理解的代码，不仅使得他成为了维护这部分代码的唯一人选（因为只有他能够理解这些复杂的逻辑），而且还暗中留下了潜在的风险，这些风险在他离职后可能导致严重的安全问题。这是一个典型的“防御性代码”例子，其中包含了被动型防御性代码（复杂的逻辑和缺乏文档）和主动防御性代码（特定条件下的异常行为和隐藏的后门）的元素。

写防御性代码是有法律风险的

在探讨程序员编写防御性代码的背景下，法律风险和责任成为了一个重要的议题。这些风险和责任在被动型和主动防御性代码之间存在显著差异，主要体现在故意行为与能力不足之间的界限，以及可能违反的职业道德和合同条款上。

对于被动型防御性代码，法律风险主要涉及到程序员的职业道德和合同义务。如果程序员的行为被解释为有意为之，以增加自身的不可替代性，这可能构成对雇主的欺诈行为，违反了职业道德和合同中的诚信义务。然而，由于直接证据往往难以获得，这种情况下的法律责任往往处于灰色地带，难以明确界定。

相比之下，主动防御性代码的法律风险则更加明显和严重。编写旨在未来某个时间点故意损害公司系统或数据的代码，如时间炸弹、逻辑炸弹或隐藏后门，这些行为可以被明确视为违法行为。这不仅违反了职业道德，更可能触犯刑法，如破坏计算机系统、非法访问计算机信息系统等罪名。此外，如果这种行为导致了实际的损失，程序员还可能面临赔偿责任。例如，数据破坏可能违反数据保护法规，而未授权访问则侵犯了计算机安全法律。

从实际操作角度看，主动防御性代码因其具有明确的恶意意图和潜在的破坏性，比被动型防御性代码更容易被识别并追究法律责任。企业和组织在面对这类问题时，通常会通过内部调查、技术审计和法律途径来应对，并寻求补救措施。因此，程序员在考虑编写任何形式的防御性代码之前，必须深思熟虑其可能带来的职业和法律后果。

企业和程序员的相互信任，是解决防御性代码问题的核心

在当前的职场环境中，程序员采取防御性代码作为自我保护手段的做法，虽出于对职业安全的考虑，但这种策略可能并非最佳选择。这种做法本质上是一把双刃剑，短期内或许能为个人带来某种程度的“保护”，但长远来看，其副作用和潜在的负面影响远超过可能的好处。

这种行为损害了程序员作为专业人士的核心价值和职业道德，进而影响个人的职业信誉。在技术行业，一个人的职业生涯极大地依赖于他们的专业声誉和同事、雇主之间建立的信任。一旦失去了这种信任，恢复将极其困难，可能导致个人在行业内的机会大大减少。

从法律角度来看，故意编写可能导致损害的代码，不仅存在道德问题，还可能涉及违法行为，从而使个人面临法律诉讼或其他法律后果，包括被解雇、诉讼甚至刑事责任，尤其是那些故意植入破坏性功能的情况。

防御性代码，尤其是那种被设计来隐藏缺陷、故意降低代码可维护性或植入潜在的破坏性功能的代码，对企业、个人以及整个社会都有深远的影响。

在企业层面，防御性代码可能导致系统的不稳定，增加维护成本，甚至在未检测到的情况下引发重大故障或数据泄露，对企业的运营和声誉造成严重影响。这种代码的存在反映出团队内部的不信任和沟通不畅，可能导致团队分裂，影响员工的士气和生产力。

因而，实施严格的代码审查过程是关键，它可以帮助识别和纠正潜在的问题代码。此外，安全与合规性审计也是确保代码安全性和符合行业标准的有效手段。