传统意义的 “防御性编程” 是说采取一些预防措施来确保代码的稳健性和可靠性，
最近两年，网上讨论 “防御性编程” 的声音多了很多，
但是这里大家讨论的 “防御性编程” 可不是传统意义上的概念，
简单地说，就是写一些 “别人看不懂，只有自己能看懂，甚至自己也看不懂，只有机器能懂” 的代码。
大家的想法大概是这样的：如果哪天自己被裁了，公司也难以快速搞懂这些代码，相当于留了个 “后手”。
说到怎么实现这个 “防御性编程” ，很多互联网大厂员工也开始纷纷 “整活”，提出了各种防御性编程的 “奇思妙想”，比如：
- 就算是最简单的业务逻辑，也要往复杂里写，最好别人都看不懂
- 能多用几个设计模式就多用几个设计模式，不能用也要创造条件用，把代码结构搞得越难以理解越难以维护越好
- 一个方法能搞定的，坚决不写第二个，把所有的业务逻辑都写到一个方法，最好写个几百行，让谁都不敢改
- 条件语句也要多用几层，一层嵌套一层，把它做成迷宫最好，让老鼠进来也要晕头转向
- 变量和方法命名时最好使用无意义的字母组合，代码的可读性越差越好，也不要写注释，有本事你们自己读懂
……
如果真的按这些 “奇思妙想” 写代码，不光别人看不懂，恐怕过个三两月，估计作者自己也看不懂了，真的就只有计算机才能看懂了！
但是，这样真的好吗？
虽然有很多人拍手称好，我倒是觉得这样对于程序员来说，是弊大于利的，理由如下：
首先，这样做违背职业道德，损害了程序员自身的职业声誉。程序 员的立身之本不是技术，而是信誉，软件开发的圈子说小不小，说大其实也没那么大，如果你的声誉不好，未来的发展肯定走不远，没必要为了一口饭而丢掉自己的信誉。
其次，故意编写难以理解的代码，不利于个人技能的成长。代码的魅力在于重构，在重构的过程中，你一遍遍地优化代码，你就有动力去学习更多更好的技术，慢慢地，掌握的技术就会融汇贯通，最终代码变得优雅，性能变得高效，你也成为一个人人称颂的技术大牛。反而，如果你总是将心思放在如何把代码写得更 “烂”，你就没有动力去学习，这样你就不会有成长，也许你会说，你会私下学习新技术，但如果新技术不真正应用在真实项目里，永远都不会变成你自己的技术！
再次，故意编写难以理解的代码，反而可能会让你更快地丢掉 “饭碗”，因为质量差的代码肯定会导致团队效率降低，出错的机率也更大，这样会更打击团队的士气，这样的产品客户也不愿意用，这样的情况不是更容易让老板坚定裁员的决心吗？
最后，做过企业的老杨更清楚，当一个企业效益不好的时候，为了自保，往往都是整个部门整条业务线裁掉，你把自己 “包装” 得再难以替代都是无济于事的，所以，把心思花在如果把代码写 “烂” 上，真的是一件性价比很低的活，不如把这个时间用来好好提高自己的能力！
总而言之，程序员搞防御性编程固然可以理解，现在确实有一些企业做得很不好，比如变相裁员、无征兆裁员、想方设法不给赔偿等等，伤害了程序员的心，但这样子做，短期来看，是程序员和企业的互相伤害；长期来看，对程序员自身的伤害更大！因此，我觉得程序员最好在上班的时间还是一门心思地提高自己，写出可靠的代码，这样既对得起自己的职业良知，也提高了自己，何乐而不为，只要自身水平高，真的被裁员了也不怕，拿一笔赔偿到别的企业上班，不是更香吗？哈哈…… 你觉得有道理吗？欢迎留言讨论！
我是老杨，一个执着于编程乐趣、至今奋斗在一线的 10年+ 资深研发老鸟，是软件项目管理师，也是快乐的程序猿，持续分享全栈实用编程技巧、项目管理经验和职场成长心得。欢迎关注老杨的公众号，相互交流，共同进步！
