防御性编程，似乎是个新名词。
大体意思是：自己写的代码，只有自己能看懂、能维护，别人很难，甚至无法接手。
进行防御性编程的目的是：留一手、自我保护、防止自己被裁员。
防御性编程的起因是程序员的互联网职场环境：35岁风水岭、容易被裁员。
程序员为了给自己留条后路，开始琢磨起了所谓的“防御性编程”,一旦被裁员，自己的代码别人很难看懂、无法轻易维护、自己的写的功能别人不敢动、不敢升级，甚至一改就出BUG。自动触发“代码无法触碰”被动技能。
如此，一荣俱荣、一损俱损，将自己的利益与公司利益捆绑在了一起。自己如果被裁，公司也将受到“报复”，甚至某些情况下公司可能得重新请自己处理问题。
具体而言，就是程序员在工作中写一些“别人看不懂，只有自己能懂”的代码。
甚至直接将自己的代码混淆加密。
举个简单的例子，比如一行JavaScript代码：
var city = "shanghai";
在防御的思路下，代码可能呈现为这样：
var _0x5ec318="iahgnahs".split("").reverse().join("");
这是用JShaman将JavaScript代码进行了混淆加密。
如果加密的更复杂一些，可能成为这样：
var _0xf00d7c="iahgnahs"['\x73\x70\x6c\x69\x74']("")['\x72\x65\x76\x65\x72\x73\x65']()['\x6a\x6f\x69\x6e']("");
甚至成为这样：
var _0x75152c=["122.97.104.103.110.97.104.96."];function _0x4b7a8a(_4,_5){_5=9;var _,_2,_3="";_2=_4.split(".");for(_=0;_<_2.length-1;_++){_3+=String.fromCharCode(_2[_]^_5);}return _3;}var _0x1e7e=_0x4b7a8a(_0x75152c[0]);
注：在这段代码中，变量_0x1e7e的值正是字符串"shanghai"。
相比于原始代码，这样的无可读性的代码，基本无法维护、更新。
进行“防御性编程”对吗？
应不应该进行“防御性编程”？
正知正见而言，不应该如此。
编程以实现功能、解决问题为目标。程序源码本该简洁、清晰、直观、易懂、便于维护。
此种“防御性编程”，与编程本源追求背道而驰。原则上讲：属实不该。
如果人人如此，如果这种防御性编程方式被广泛采用，对整个技术生态的都会带来不良影响：影响源码本身、影响技术进步、影响团队合作、影响项目、影响产品、影响团队合作、影响员工和公司信任感...
但回归现实，在这个现实的社会中，似乎是不得已而为。
如果可以，如果程序员生存环境良好、如果不是危机感重重、如果可以编程编到老。想必不会有几个程序员愿意这样编程、不会把心思和精心放在这种方面。