最近，大家可能都听说了，不少互联网大厂都在裁员。

这让一众程序员们感到了压力山大。咱们的码农朋友们，为了给自己留条后路，开始琢磨起了所谓的“防御性编程”。

简单来说，就是写一些“别人看不懂，只有自己能看懂”的代码。

他们的想法大概是这样的：如果哪天自己被裁了，公司也难以快速搞懂这些代码，相当于留了个“后手”。

防御性编程的“奇技淫巧”

说到怎么实现这个“防御性编程”，一位来自阿里的员工，轻轻松松提了一堆绝招：

• 简单事情复杂化：能拖动的就不写代码，搞得越复杂越好。
• 层层套娃：设计模式大行其道，一层套一层，看着就头大。
• 精简到极致：一个函数能搞定的，坚决不开第二个。
• if-else大赛：多层嵌套，把简单逻辑搞得像迷宫一样。
• 随机命名法：别的不说，命名得像解密游戏，abcd随便来。

大佬果然是大佬，这方法，不得不服！

其他程序员怎么看？

网上的程序员们，在评论区可是炸开了锅，五花八门，有人觉得这是迫不得已的自救，毕竟谁不想给自己留条后路呢？

但也有人觉得根本没有必要专门防御性编程，大多数人正常写就是防御性编程了。

而代码维护时间长了自然变屎山，谁来了都得钻研许久再踩几次坑才能摸出点门道。

还有的大佬就淡定多了，说“除非你是个天才，你的智商才不可替代，这样公司留着你本来就很应该。不然你怎么防御都没有用，替代只是时间问题。”。

码农的自救，合理还是自毁？

说到底，这种“防御性编程”真的有效吗？

程序员采用“防御性编程”的做法，在表面上看似乎是一种自我保护的策略。

特别是在现在糟糕的职场背景下，这种做法理论上可以为程序员个人带来短期的安全感。他们通过编写难以理解的代码，或是刻意制造程序之间的复杂联动，使得自己在项目中变得不可或缺。从个人角度看，这似乎是一种巧妙的自保手段。

然而，从长期和职业道德的角度来看，这种做法可能充满了风险和问题。

首先，它破坏了代码的可读性和可维护性，这是编程领域的基本原则之一。良好的代码应当是清晰、可读、易于维护的。通过创造复杂和难以维护的代码，程序员不仅对项目的未来负有潜在的破坏性，同时也可能损害自己的职业声誉。

在团队和项目管理的层面，防御性编程可能导致严重的后果。这种编码方式使得代码的交接和维护变得异常困难，甚至可能导致重要信息的丢失。

更严重的是，如果这种编程方式被广泛采用，它可能威胁到整个技术生态的健康发展。

总之这种做法在短期内可能确实能给自己留个后路，但长远来看可能是个双输的结果。

最后，码农为了保住饭碗，采用“防御性编程”应对裁员，你怎么看？