最近，大家可能都聽說了，不少互聯(lián)網(wǎng)大廠都在cAI員。
這讓一眾程序員們感到了壓力山大。咱們的碼農(nóng)朋友們，為了給自己留條后路，開始琢磨起了所謂的“防御性編程”。
簡(jiǎn)單來說，就是寫一些“別人看不懂，只有自己能看懂”的代碼。
他們的想法大概是這樣的：如果哪天自己被裁了，公司也難以快速搞懂這些代碼，相當(dāng)于留了個(gè)“后手”。
防御性編程的“奇技淫巧”
說到怎么實(shí)現(xiàn)這個(gè)“防御性編程”，一位來自阿里的員工，輕輕松松提了一堆絕招：
- 簡(jiǎn)單事情復(fù)雜化：能拖動(dòng)的就不寫代碼，搞得越復(fù)雜越好。
- 層層套娃：設(shè)計(jì)模式大行其道，一層套一層，看著就頭大。
- 精簡(jiǎn)到極致：一個(gè)函數(shù)能搞定的，堅(jiān)決不開第二個(gè)。
- if-else大賽：多層嵌套，把簡(jiǎn)單邏輯搞得像迷宮一樣。
- 隨機(jī)命名法：別的不說，命名得像解密游戲，abcd隨便來。
大佬果然是大佬，這方法，不得不服！
我發(fā)現(xiàn)一個(gè)獨(dú)立開發(fā)者網(wǎng)站不錯(cuò): j301.cn
其他程序員怎么看？
網(wǎng)上的程序員們，在評(píng)論區(qū)可是炸開了鍋，五花八門，有人覺得這是迫不得已的自救，畢竟誰不想給自己留條后路呢？
但也有人覺得根本沒有必要專門防御性編程，大多數(shù)人正常寫就是防御性編程了
而代碼維護(hù)時(shí)間長(zhǎng)了自然變屎山，誰來了都得鉆研許久再踩幾次坑才能摸出點(diǎn)門道
還有的大佬就淡定多了，說“除非你是個(gè)天才，你的智商才不可替代，這樣公司留著你本來就很應(yīng)該。不然你怎么防御都沒有用，替代只是時(shí)間問題。”。
碼農(nóng)的自救，合理還是自毀？
說到底，這種“防御性編程”真的有效嗎？
程序員采用“防御性編程”的做法，在表面上看似乎是一種自我保護(hù)的策略。
特別是在現(xiàn)在糟糕的職場(chǎng)背景下，這種做法理論上可以為程序員個(gè)人帶來短期的安全感。他們通過編寫難以理解的代碼，或是刻意制造程序之間的復(fù)雜聯(lián)動(dòng)，使得自己在項(xiàng)目中變得不可或缺。從個(gè)人角度看，這似乎是一種巧妙的自保手段。
然而，從長(zhǎng)期和職業(yè)道德的角度來看，這種做法可能充滿了風(fēng)險(xiǎn)和問題。
首先，它破壞了代碼的可讀性和可維護(hù)性，這是編程領(lǐng)域的基本原則之一。良好的代碼應(yīng)當(dāng)是清晰、可讀、易于維護(hù)的。通過創(chuàng)造復(fù)雜和難以維護(hù)的代碼，程序員不僅對(duì)項(xiàng)目的未來負(fù)有潛在的破壞性，同時(shí)也可能損害自己的職業(yè)聲譽(yù)。
在團(tuán)隊(duì)和項(xiàng)目管理的層面，防御性編程可能導(dǎo)致嚴(yán)重的后果。這種編碼方式使得代碼的交接和維護(hù)變得異常困難，甚至可能導(dǎo)致重要信息的丟失。
更嚴(yán)重的是，如果這種編程方式被廣泛采用，它可能威脅到整個(gè)技術(shù)生態(tài)的健康發(fā)展。
總之這種做法在短期內(nèi)可能確實(shí)能給自己留個(gè)后路，但長(zhǎng)遠(yuǎn)來看可能是個(gè)雙輸?shù)慕Y(jié)果。
最后 碼農(nóng)為了保住飯碗，采用“防御性編程”應(yīng)對(duì)裁員，你怎么看？
