大家肯定都听说过防御性编程。
防御性编程( Defensive programming )是防御式设计的一种具体体现,它是为了保证,对程序的不可预见的使用,不会造成程序功能上的损坏。它可以被看作是为了减少或消除墨菲定律效力的想法。防御式编程主要用于可能被滥用,恶作剧或无意地造成灾难性影响的程序上。——百度百科
在防御性编程中,我们时刻认为输入不合法,需要添加各种判断。比如:
if(input == null){
return;
}
那你听说过防御性开发吗?
防御性开发( Defensive developing )是有经验的开发者探索出的一种开发方式,它为了保证对开发过程中反反复复的需求变动,不会造成开发工期上的影响。它可以被看做是为了减少或消除因反复变更需求带来的巨大工作量。 ——我编的
在防御性开发中,当需求去掉一个功能时,我们往往选择注释相关代码而不是直接删除。当逻辑条件变更时,我们往往保留判断语句而不是重构代码。从而导致一些奇奇怪怪的代码,尤其是接手没有注释的代码时,比如:
boolean flag = true;
//2017.08.11 需求变更,去掉 XXXX 限制,产品说后期可能加回来
//flag = checkSomething();
if(flag){
doSomething();
}
It's just a joke。各位脑洞大开的程序猿一起来吐槽看过的这种奇奇怪怪的代码、交流、玩这个梗吧 当我看到莫名其妙的代码提问时,别人总会煞有介事的指点一番“嗯,这是防御性开发,高手啊!”
1
codermagefox 2017-08-11 15:47:15 +08:00
那个....这不就是 FP 解决的问题吗...
|
2
flyingghost 2017-08-11 16:09:56 +08:00 4
```
showWaitingUI(); sleep(10000); // 产品经理交待,为二期优化做铺垫 doSomething(); showDoneUI(); ``` |
3
whileFalse 2017-08-11 16:15:39 +08:00 17
分享一个注释写法:
//* //删除第一个斜杠可以切换开关 flag = 1 /*/ flag = 2 //*/ |
4
watsy0007 2017-08-11 16:21:43 +08:00
git 是用来干嘛的. = . =
|
5
baiyi 2017-08-11 16:22:46 +08:00
|
6
mooncakejs 2017-08-11 16:30:16 +08:00
@watsy0007 在 git 情况下, 这种写法反而更好,看日志或者合并的时候就知道只改了一行,而不是多行。
boolean flag = true; //2017.08.11 需求变更,去掉 XXXX 限制,产品说后期可能加回来 //flag = checkSomething(); if(flag){ doSomething(); } |
7
smithtel 2017-08-11 16:37:02 +08:00 via iPhone
远古时代可没 svn git 这嘲讽有什么意思呢
|
8
7654 2017-08-11 16:45:12 +08:00
我感觉这是在立 flag,PM 插上的不可动摇的 flag
|
9
zjsxwc 2017-08-11 16:55:27 +08:00
看情况吧,
架构设计合理的项目,对用户数据的校验在源头就做了,没必要在每个方法里刻意进行。 转手 N 多个人,且不好维护的烂项目,没办法,只能和楼主这样到处 if 判断,重构或者重写才是最好的选择。 |
10
frankkai 2017-08-11 16:59:25 +08:00
const KingOfNorth=/*I know everything*/"Jon Snow";
console.log("You konw nothing"+KingOfNorth); 楼主你点的防御性开发 233 |
11
nicevar 2017-08-11 17:21:04 +08:00
这种情况没有必要嘲讽,不同的环境差别很大,比如客户端开发中,各个版本操作系统自己的屁股没擦干净,需要你去给它擦屁股,很长一段时间你不能从根源上解决这个问题,在这段时间里只能保留一些没太大用的过程代码,这时候用 flag 来处理没什么不对,特别是开发期间,难道每次删掉然后下次又从 git 中恢复?如果你要是磨洋工我真没什么意见。
|
12
misaka20038numbe 2017-08-11 19:03:52 +08:00
肯定还有攻击性开发的,对吧。
|
13
annielong 2017-08-11 19:14:47 +08:00
必要的时候,整个函数全部复制一份后,注释掉重写,
|
14
lamCJ 2017-08-11 19:28:18 +08:00 via iPhone
这样折腾的不还是读代码改代码的码农吗
我认为优雅点的方式是:策略模式+配置 每种需求对应一种策略 需求又变了或者出现“还是要第一个版本”就改下配置 不至于留下这种难读又失优雅的代码“祸害”接盘侠… |
15
yonka 2017-08-11 19:32:07 +08:00
//2017.08.11 需求变更,去掉 XXXX 限制,产品说后期不会回来,当我不相信
|
16
NonClockworkChen 2017-08-11 20:19:50 +08:00
我们做外包已经达到朝做夕改的牛皮地步,我是得来研究一波防御性开发了。
|
17
TestSmirk 2017-08-12 09:05:37 +08:00 via Android
请问这是物理防御,嗨皮魔法防御呢。会不会有 attack programing
|
18
ssxn58 2017-08-12 16:45:34 +08:00
#if XXXXX_SUPPORT
... #else ... #endif |
19
ssxn58 2017-08-12 16:49:28 +08:00
新需求我都是这么写的,所有的新需求都有可能会用不到,我是做 SDK 的,要考虑到不同的客户会有不同的需求,有的客户要这个功能,有的客户不要,所以通过条件编译为每一个新功能做控制。功能成熟之后,还要加上通过参数动态控制。
|