怎样才能把代码写成让接手的人维护不动？

接手

代码

维护

动

49 条回复 • 2019-06-13 00:04:24 +08:00

1

Jirajine

2019-06-11 10:49:50 +08:00 via Android

50

来了来了，这篇文章我推荐每个 coder 都要认真阅读（逃
coderlmn.github.io/frontEndCourse/unmaintainable.html

2

wly19960911

2019-06-11 10:52:20 +08:00

推荐一招，局部变量别写成局部，直接改成类的属性，随便调用，加上一个 function 上百行，我感觉这样就可以劝退一堆人了，别问为什么，我就是这样被劝退过。

3

babedoll

2019-06-11 10:54:25 +08:00

可以学我们部门一个老哥，函数名全英语翻译+拼音+数字乱凑。
在函数里插入点莫名其妙又用不着的语句。
完全违背面向对象原则，方法绝不复用。

这样的代码可以 100%成 shit 山。

4

withoutconscious

2019-06-11 10:55:50 +08:00

@Jirajine 厉害了，我要好好拜读！

5

rrZ2C

2019-06-11 11:11:29 +08:00

@Jirajine #1 神文神文，有术有道真正的集大成者也！

----
与他人共事之道

老板才是真行家
如果你的老板认为他 20 年的 FORTRAN 编程经验对于现代软件开发具有很高的指导价值，你务必严格采纳他的所有建议。投桃报李，你的老板也会信任你。这会对你的职业发展有利。你还会从他那里学到很多搞乱程序代码的新方法。

沉默是金
永远不要对下一个危机保持警觉。如果你预见到某个问题可能会在一个固定时间爆发，摧毁西半球的全部生命，不要公开讨论它。不要告诉朋友、同事或其他你认识的有本事的人。在任何情况下都不要发表任何可能暗示到这种新的威胁的内容。只发送一篇正常优先级的、语焉不详的备忘录给管理层，保护自己免遭秋后算账。如果可能的话，把这篇稀里糊涂的信息作为另外一个更紧急的业务问题的附件。这样就可以心安理得地休息了，你知道将来你被强制提前退休之后一段时间，他们又会求着你回来，并给你对数级增长的时薪！

每月一书俱乐部
加入一个计算机每月一书俱乐部。选择那些看上去忙着写书不可能有时间真的去写代码的作者。去书店里找一些有很多图表但是没有代码例子的书。浏览一下这些书，从中学会一些迂腐拗口的术语，用它们就能唬住那些自以为是的维护代码的程序员。你的代码肯定会给他留下深刻印象。如果人们连你写的术语都理解不了，他们一定会认为你非常聪明，你的算法非常深奥。不要在你的算法说明里作任何朴素的类比。

6

ghos

2019-06-11 11:46:52 +08:00

7

我之前看过一个混淆器把变量名都变成 l i 和 1 的组合你试试保证连自己都维护不了还可以加上叹号就像这样 l!i1il1li1ll!il1ili!

7

Jirajine

2019-06-11 11:49:33 +08:00 via Android

@withoutconscious
@rrZ2C
真的推荐认真阅读，正着看能拿铁饭碗，反过来看也是一篇讲代码规范极好的文章。

译者注：
>作者黑的是那种以代码行数考核绩效的小作坊，加上写过 20 年 FORTRAN 代码的老古董领导，还有 JAVA 语言之类的。可能很多人没看出来这篇文章是反讽，意思是让读者避免这些问题，好好写代码。作者的写作风格非常幽默，这在程序员中是很难得的。已经有太多文章一本正经地告诫大家要如何写好代码，可能加起来都没有这篇反讽文章的影响力大。正着说反着说其实都是一个意思，就看读者从哪个方向去用它了。

8

wjfz

2019-06-11 11:56:53 +08:00

我司代码几乎就是文中所说。

9

abmin521

2019-06-11 11:58:01 +08:00 via Android

我劝你善良

10

jxf2008

2019-06-11 12:01:07 +08:00

具体什么语言
c++的话把类的成员变量移出类定义，分散到各个文件，变成全局变量

11

anubu

2019-06-11 12:20:20 +08:00

14

你就正常发挥就行。

12

amwyyyy

2019-06-11 12:21:02 +08:00

1

保持正常水平就行了

13

yutou527

2019-06-11 12:32:07 +08:00

正常发挥+1

14

mwVYYA6

2019-06-11 12:43:03 +08:00 via Android

有一个可以简单又能实现的方法，就是不管干啥都抽成函数然后用最简洁而意思不明确的词起名字，并且散落在各个弱关联的文件里，这样就没人能维护了（某次改同事的代码头都要炸了 doge

15

Yiki

2019-06-11 14:53:41 +08:00

……天哪多大仇

16

liaowy

2019-06-11 15:01:51 +08:00

jsfuck http://www.jsfuck.com/

17

littleylv

2019-06-11 15:07:55 +08:00

是多大仇？
我可以说楼主职业素养不行么？

18

tilv37

2019-06-11 15:09:32 +08:00

把注释都删了，方法名改成非自然语意就好，比如“ getPost ”改为“ dasdasxads ”

19

passerbytiny

2019-06-11 15:10:53 +08:00

那么，“所有代码有人能接手维护”作为交接标准的情况下，你准备怎么走。

20

JamesR

2019-06-11 15:13:48 +08:00

没必要，业务逻辑一复杂，注释一删，自然就没几个人能维护了。

21

cyssxt

2019-06-11 15:16:40 +08:00 via iPhone

注意素质

22

ac2sherry

2019-06-11 15:17:10 +08:00

曾就职的公司里经常会出现人名、拼音、拼错了的单词、拼错了的拼音、拼错了的人名（前后鼻音）命名的变量和函数。上古代码看着真是想死。

23

HuHui

2019-06-11 15:21:21 +08:00 via Android

混淆编译再反编译就 ok 了

24

strcmp

2019-06-11 15:24:38 +08:00

把版本控制捣毁就行了

25

mnzlichunyu

2019-06-11 15:50:04 +08:00

就正常写

26

Greendays

2019-06-11 15:58:08 +08:00

感觉不需要特意处理，因为一般情况下，楼主的编码水平不会有多高，接手的人也不会有多高（狗头

27

whp1473

2019-06-11 16:18:21 +08:00

一、混淆器
1.方法、变量混淆，名字全会变成 a1、a2、a3，fun1 这样，所有方法名称和变量名都不会在遵循代码即是注释的良好习惯
2.逻辑混淆，会增加不影响功能的额外逻辑
3.结构混淆，可以把多个方法聚合成一个
4.自动去除注释
二、动态字节码技术
关键的逻辑你可以转成文本文件(JVM 语言)，在服务启动时往 JVM 中再加载，一堆类似汇编语言的脚本恶心死人。
三、git 相关
1.记得清除 git log 日志，这样找不到原来的注释
2.git 绝对不打 tag，一堆 branch 绝不删，名字都是时间戳
四、灵活运行 maven
有些包可以手动引用一下就绝对不要用 maven，如果自己再把相关类库拆分成几个类库，打包到私服，那更改难度就翻倍玩上涨了，需要维护好几个项目
五、绝对不要留文档，尤其是数据库设计、业务流程设计、项目结构架构设计文档、部署文档。
六、不留单元测试，这样对方要重构的成本大大增加，同时更难理解业务
七、单元测试不可重复执行，比如单元测试有清库的 SQL，但是不回滚，没法重复执行就意味着炸弹在里面

好了，你已经是一名成熟的跑路开发了~
(以上都是玩笑)
这些不要去做或者反过来做，你就是一名有职业素养的优秀开发了(狗头)