防御性编程，真的可以防止被裁吗？

疫情之后，大环境一直很低迷，互联网也未幸免，于是，很多公司相继“开猿节流”，可怜的程序猿惶恐不安...

接着，戏剧性的一幕发生了，国内的互联网大厂相继出现“降本见笑”的名场面，首先暴雷的是阿里云，事故原因：底层服务组件故障...

{:width=400}

随后，滴滴又崩了，不知道那个早晨有多少打工人迟到.....

{:width=400}

于是，很多人开始调侃“干活的人裁得太多了，都是老板造成的”。做技术的都清楚，服务器的稳定性不可能达到100%这种理想状态，因此，调侃固然有戏虐，但不乏真实性，很多技术岗位平时看起来并不起眼，关键时刻就能体现出他们的价值，而这个“关键时刻”的代价有时候会比较大。

最后，防御性编程一语双关的梗就润物细无声地传遍了各大技术论坛和网站...

防御性编程本意是指为了代码和系统的安全，特意在代码中增加了一些提升代码质量的保证，比如：参数校验，安全校验等等。

而特定环境下，防御性编程就出现了另一层含义：报复性编程，为了防止被裁，代码被动了手脚，只有本人才能维护。

防御性编程，绝大部分是客观产生的，比如代码中出现的 bug，但也存在着主观性，常见的一些方式有：

• 代码不加注释
• 命名直接使用a，b，c等等毫无含义的变量，大大增加了代码维护的难度；
• 代码结构被破坏，函数直接随意的相互调用，极大的破坏高内聚低耦合；
• 代码预留后门；

BUT，作为技术人员，小L觉得，做人一定要有自己的职业操守，千万不要违法乱纪，主观性的“防御性编程”，轻则造成线上事故，对公司造成经济损失，重则违法，切莫踩红线。

​