如何编写无法维护的代码让自己稳拿铁饭碗
– Roedy Green
简介永远不要（把自己遇到的问题）归因于（他人的）恶意，这恰恰说明了（你自己的）无能。 — 拿破仑
为了造福大众，在Java编程领域创造就业机会，兄弟我在此传授大师们的秘籍。这些大师写的代码极其难以维护，后继者就是想对它做最简单的修改都需要花上数年时间。而且，如果你能对照秘籍潜心修炼，你甚至可以给自己弄个铁饭碗，因为除了你之外，没人能维护你写的代码。再而且，如果你能练就秘籍中的全部招式，那么连你自己都无法维护你的代码了！
你不想练功过度走火入魔吧。那就不要让你的代码一眼看去就完全无法维护，只要它实质上是那样就行了。否则，你的代码就有被重写或重构的风险！
总体原则Quidquid latine dictum sit, altum sonatur.
(随便用拉丁文写点啥都会显得高大上。)
想挫败维护代码的程序员，你必须先明白他的思维方式。他接手了你的庞大程序，没有时间把它全部读一遍，更别说理解它了。他无非是想快速找到修改代码的位置、改代码、编译，然后就能交差，并希望他的修改不会出现意外的副作用。
他查看你的代码不过是管中窥豹，一次只能看到一小段而已。你要确保他永远看不到全貌。要尽量让他难以找到他想找的代码。但更重要的是，要让他不能有把握忽略任何东西。
程序员都被编程惯例洗脑了，还为此自鸣得意。每一次你处心积虑地违背编程惯例，都会迫使他必须用放大镜去仔细阅读你的每一行代码。
你可能会觉得每个语言特性都可以用来让代码难以维护，其实不然。你必须精心地误用它们才行。
命名“当我使用一个单词的时候” Humpty Dumpty 曾经用一种轻蔑的口气说, “它就是我想表达的意思，不多也不少。“
– Lewis Carroll — 《爱丽丝魔镜之旅》， 第6章
编写无法维护代码的技巧的重中之重是变量和方法命名的艺术。如何命名是和编译器无关的。这就让你有巨大的自由度去利用它们迷惑维护代码的程序员。
妙用 宝宝起名大全
单字母变量名
创造性的拼写错误
抽象
首字母大写的缩写
辞典大轮换
首字母大写
重用命名
使用非英语字母
<code class="language-text">typedef struct { int i; } ínt;
</code><code class="language-text"> Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
</code>
对了，这不是php，而是前端js，不过大家都是玩代码的，不可维护的道理是一样的。再补充一下，当时的我做了4年开发（php2年多3年的样子，前端是1年多不到2年），那时已转专职前端开发，负责的是某垂直电商的前端架构；那家伙是超过10年的老码农，绝大多是时候PHP+前端混合开发（老资格的程序员大多是这种情况，我做php那会儿也这样），招进来是前端岗位。
