最近，大家可能都聽說了，不少互聯網大廠都在裁員。

這讓一眾程序員們感到了壓力山大。咱們的碼農朋友們，為了給自己留條后路，開始琢磨起了所謂的“防御性編程”。

簡單來說，就是寫一些“別人看不懂，只有自己能看懂”的代碼。

他們的想法大概是這樣的：如果哪天自己被裁了，公司也難以快速搞懂這些代碼，相當于留了個“后手”。

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

說到怎么實現這個“防御性編程”，一位來自阿里的員工，輕輕松松提了一堆絕招：

• 簡單事情復雜化：能拖動的就不寫代碼，搞得越復雜越好。
• 層層套娃：設計模式大行其道，一層套一層，看著就頭大。
• 精簡到極致：一個函數能搞定的，堅決不開第二個。
• if-else大賽：多層嵌套，把簡單邏輯搞得像迷宮一樣。
• 隨機命名法：別的不說，命名得像解密游戲，abcd隨便來。

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

其他程序員怎么看？

網上的程序員們，在評論區可是炸開了鍋，五花八門，有人覺得這是迫不得已的自救，畢竟誰不想給自己留條后路呢？

但也有人覺得根本沒有必要專門防御性編程，大多數人正常寫就是防御性編程了。

而代碼維護時間長了自然變屎山，誰來了都得鉆研許久再踩幾次坑才能摸出點門道。

還有的大佬就淡定多了，說“除非你是個天才，你的智商才不可替代，這樣公司留著你本來就很應該。不然你怎么防御都沒有用，替代只是時間問題。”。

碼農的自救，合理還是自毀？

說到底，這種“防御性編程”真的有效嗎？

程序員采用“防御性編程”的做法，在表面上看似乎是一種自我保護的策略。

特別是在現在糟糕的職場背景下，這種做法理論上可以為程序員個人帶來短期的安全感。他們通過編寫難以理解的代碼，或是刻意制造程序之間的復雜聯動，使得自己在項目中變得不可或缺。從個人角度看，這似乎是一種巧妙的自保手段。

然而，從長期和職業道德的角度來看，這種做法可能充滿了風險和問題。

首先，它破壞了代碼的可讀性和可維護性，這是編程領域的基本原則之一。良好的代碼應當是清晰、可讀、易于維護的。通過創造復雜和難以維護的代碼，程序員不僅對項目的未來負有潛在的破壞性，同時也可能損害自己的職業聲譽。

在團隊和項目管理的層面，防御性編程可能導致嚴重的后果。這種編碼方式使得代碼的交接和維護變得異常困難，甚至可能導致重要信息的丟失。

更嚴重的是，如果這種編程方式被廣泛采用，它可能威脅到整個技術生態的健康發展。

總之這種做法在短期內可能確實能給自己留個后路，但長遠來看可能是個雙輸的結果。

最后，碼農為了保住飯碗，采用“防御性編程”應對裁員，你怎么看？