如何編寫不可維護的php代碼？

程序员文章站 2024-01-02 22:23:40

...

回复内容：

继承无节制
复杂的类
接口设计得太窄或太宽
函数/方法参数超过三个
大量IF嵌套
使用$$foo
笼统的命名
不清楚的缩写
使用三维以上的数组
自己造*
复杂逻辑没有单元测试
文件组织没层次
代码格式不一致无规约
太深的依赖树
复制黏贴
hack的库没文档
过度优化
懒惰不重构
不要看代码整洁之道

以前看到的，在这分享（翻译来自老码农冒死揭开行业黑幕：如何编写无法维护的代码，作者伯乐在线 - 老码农，已征得作者同意）
============================================================

如何编写无法维护的代码让自己稳拿铁饭碗

– Roedy Green

简介

永远不要（把自己遇到的问题）归因于（他人的）恶意，这恰恰说明了（你自己的）无能。 — 拿破仑

为了造福大众，在Java编程领域创造就业机会，兄弟我在此传授大师们的秘籍。这些大师写的代码极其难以维护，后继者就是想对它做最简单的修改都需要花上数年时间。而且，如果你能对照秘籍潜心修炼，你甚至可以给自己弄个铁饭碗，因为除了你之外，没人能维护你写的代码。再而且，如果你能练就秘籍中的全部招式，那么连你自己都无法维护你的代码了！

你不想练功过度走火入魔吧。那就不要让你的代码一眼看去就完全无法维护，只要它实质上是那样就行了。否则，你的代码就有被重写或重构的风险！

总体原则

Quidquid latine dictum sit, altum sonatur.
(随便用拉丁文写点啥都会显得高大上。)

想挫败维护代码的程序员，你必须先明白他的思维方式。他接手了你的庞大程序，没有时间把它全部读一遍，更别说理解它了。他无非是想快速找到修改代码的位置、改代码、编译，然后就能交差，并希望他的修改不会出现意外的副作用。

他查看你的代码不过是管中窥豹，一次只能看到一小段而已。你要确保他永远看不到全貌。要尽量让他难以找到他想找的代码。但更重要的是，要让他不能有把握忽略任何东西。

程序员都被编程惯例*了，还为此自鸣得意。每一次你处心积虑地违背编程惯例，都会迫使他必须用放大镜去仔细阅读你的每一行代码。

你可能会觉得每个语言特性都可以用来让代码难以维护，其实不然。你必须精心地误用它们才行。

命名

“当我使用一个单词的时候” Humpty Dumpty 曾经用一种轻蔑的口气说, “它就是我想表达的意思，不多也不少。“
– Lewis Carroll — 《爱丽丝魔镜之旅》，第6章

编写无法维护代码的技巧的重中之重是变量和方法命名的艺术。如何命名是和编译器无关的。这就让你有巨大的*度去利用它们迷惑维护代码的程序员。

妙用宝宝起名大全

买本宝宝起名大全，你就永远不缺变量名了。比如 Fred 就是个好名字，而且键盘输入它也省事。如果你就想找一些容易输入的变量名，可以试试 adsf 或者 aoeu之类。

单字母变量名

如果你给变量起名为a,b,c，用简单的文本编辑器就没法搜索它们的引用。而且，没人能猜到它们的含义。

创造性的拼写错误

如果你必须使用描述性的变量和函数名，那就把它们都拼错。还可以把某些函数和变量名拼错，再把其他的拼对(例如 SetPintleOpening 和 SetPintalClosing) ，我们就能有效地将grep或IDE搜索技术玩弄于股掌之上。这招超级管用。还可以混淆不同语言（比如colour — 英国英语，和 color — 美国英语)。

抽象

在命名函数和变量的时候，充分利用抽象单词，例如 it, everything, data, handle, stuff, do, routine, perform 和数字，像这样命名的好例子有 routineX48, PerformDataFunction, DoIt, HandleStuff还有 do_args_method。

首字母大写的缩写

用首字母大写缩写（比如GNU 代表 GNU’s Not Unix) 使代码简洁难懂。真正的汉子(无论男女)从来不说明这种缩写的含义，他们生下来就懂。

辞典大轮换

为了打破沉闷的编程气氛，你可以用一本辞典来查找尽量多的同义词。例如 display, show, present。在注释里含糊其辞地暗示这些命名之间有细微的差别，其实根本没有。不过，如果有两个命名相似的函数真的有重大差别，那倒是一定要确保它们用相同的单词来命名(例如，对于 “写入文件”, “在纸上书写” 和 “屏幕显示” 都用 print 来命名)。在任何情况下都不要屈服于编写明确的项目词汇表这种无理要求。你可以辩解说，这种要求是一种不专业的行为，它违反了结构化设计的信息隐藏原则。

首字母大写

随机地把单词中间某个音节的首字母大写。例如 ComputeReSult()。

重用命名

在语言规则允许的地方，尽量把类、构造器、方法、成员变量、参数和局部变量都命名成一样。更高级的技巧是在{}块中重用局部变量。这样做的目的是迫使维护代码的程序员认真检查每个实例的作用域。特别是在Java代码中，可以把普通方法伪装成构造器。

使用非英语字母

在命名中偷偷使用不易察觉的非英语字母，例如

typedef struct { int i; } ínt;

熟读下面的条款，然后反过来做

    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!

你就正常写。这个话题，我敢肯定不少开发者有思考过！但毕竟不是什么光明正大的事情，自己做就是了，在项目高调使用就傻逼了。或许楼主不是这样的，只是想拿出来消遣一下大家，找个话题来让大家发挥罢了。

既然是消遣，我就谁便聊聊。
（明确一下，以下当我用到“码农”来描述时，它是一个贬义词。）

----------------
我认可人性是自私，因此，有码农会这么做。而我的意思则是，别把自己太当回事，这世界不会离开了谁就不转了！

“因为没人能搞定你的代码，那意味着你的工作是不可替代的，谁也取代不了你。你找了个铁饭碗。”这是一个伪命题，码农自己的意淫。

ok，我假设存在不可维护的代码。

请问这样的代码还是得由你来维护吧？也就是说，还是有人来维护的，只是别人维护起来不太合适或不太方便而已。既然这样，按我们这一行的规矩，领导是不在乎你用什么方法和技术的，只会给一个截止时间让你来完成，对吧？

在这种情况下，这样的代码会只会让你陷入毫无节制的无谓的加班。除非这个项目不重要，但又需要有人来维护，那么确实可以获得某种相对稳固的饭碗。但不重要的项目，谁会花高价请一个码农来维护呢？不会太高的，企业不会是*！

然而，人又是需要往高处走的，毕竟这个社会很现实，谁也不会跟钱有仇。很难维护的代码最后只能让你越陷越深，最后要么自己滚蛋，要么继续拿着差不多的薪水，如果这就是你想要的铁饭碗，那么我就无话可说了。

请问这种事情你会干吗？

很多码农自己总是认为自己最聪明，能写出一些相对难维护的代码就以为自己在智商上高别人一筹，别那么天真好吗？™的好多码农就是这样，以为能写个程序就装逼，总以为别人是傻逼。

好吧，假设普通码农智商只有120，而你是130甚至140以上，请问这种差别在做人做事上会有本质的差别吗？

其实啊，正常人的智商都差不了太多的，对于别人不可以维护，意味着你维护起来也不太容易。同理，你维护起来容易的，别人就不会太难，只要开发经验差不多，熟悉只是多一点点时间而已，因而不存在绝对维护不了的代码，只是不太愿意去维护罢了，别自我意淫——“我的代码不可维护”可以吗？

的确，我不否认存在很难维护的代码，但是如果一个人要是以这样的心态去书写代码，他的修为一定是有限的，因为代码能力和程序造诣需要大量的项目去实践。

或许，一两个项目没有人发现你是这样的心态，但我相信能够大多人或项目一定存在能识别这种鬼魅伎俩的人存在，而且一定不少。因此，重要的核心的项目会让这样的人去负责吗？或者，只让你一个人去负责吗？

这是不太可能的。如果不能有太多的机会独立去实现那些重要的核心的项目，请问你的代码修为又怎么提高呢？如果你是天才，天生就牛逼，请问这样的你又何必写不可维护的代码呢？

所以，正真牛逼的程序开发者是不屑于去书那些“写不可维护”的代码的！因为这对他自己没有任何好处！

-----下面讲一个我碰到码农的故事-----
时间在2014年10月份，我负责一个电商项目招了一个1977年出生的老码农，本来不太想要他的，因为传统项目出来的，但我觉得他的项目经验还可以，而且进度有点儿紧，所以就要了他。

当然，一开始的时候我安排给他的事都能顺利完成，但是却总是有些做法让人不能接受，比如使用aaa,bbb,ccc,zzz这样的变量名。当然，这也是我们没有做好规范，而且自己身上还一大堆业务要亲自去写，发现这样的问题后就他为什么要这样做？

回复就是，时间赶，先实现逻辑再回来改。好吧，这是事实。我认了，进度确实很赶，自己都自身难保，先过了吧。

就这样项目上了线，1个多星期赶一个交互比较复杂的电商侧边栏项目（天猫、VIP、聚美等电商右侧那个黑色工具条）。当我回头看他实现的那部分代码，虽说说不上不可维护，但确实很难改，因为很多没有意义的变量名，一会儿驼峰一会儿蛇线，还有很多没有注释的高度抽象的函数（如果有兴趣，我可以发一份给大家瞅瞅），截个图证明一下，这已是我重新格式化后的代码了：

对了，这不是php，而是前端js，不过大家都是玩代码的，不可维护的道理是一样的。再补充一下，当时的我做了4年开发（php2年多3年的样子，前端是1年多不到2年），那时已转专职前端开发，负责的是某垂直电商的前端架构；那家伙是超过10年的老码农，绝大多是时候PHP+前端混合开发（老资格的程序员大多是这种情况，我做php那会儿也这样），招进来是前端岗位。

我把他招进来是看到他多年的开发经验，就没再细看他做的代码，或者说觉得没必要没要看原来的代码，就这样进来了。而且，价格很便宜，转正9K，试用期7.5K。别误会，这是他自己开的价格，我立马找HR确认了这个价格，让他赶紧把人弄过来，10年以上的程序开发经验只要白菜价，这等好事哪里找啊？

但是，和他合作了一个项目之后，我后悔了。当时他试用期还没过，我是想把他开掉了，但是找不到人来负责，我自己有一大堆杂事，只好又忍了。其实，从这点上看，我™的也不是什么好鸟，反正工资又不是我开，那些个烂代码又不想自己去弄，项目上线后公司又给我升职又加薪的，懒得烦这个问题，就这样让他混过了试用期。

但是，这个项目到了2015年后，投资人打算撤资，于是团队面临解散。我们核心的技术团队和市场团队找到了新的投资商，重启了一个品牌和域名继续干。我依然负责前端架构和新项目的发版流程设计，但这个10年的码农是唯一一个被剔除出局的，后来就没再直接联系。有同事说，他后来加入了一个新公司，薪水翻翻，但不到1个月就被开掉了，不知道什么原因。

好吧，这就是书写无可维护代码的码农的故事。绝对真人真事。

说实话，后来我自己重新实现了一遍他的业务，其实没什么难度。经过这个事情之后，我现在负责的项目，如果有发现这样的人，不管他多牛逼，我一定不会忍。就今年国庆前吧，我们的项目就有一个15K的前端，能力不错，就因为又类似的代码迹象，就在项目攻关双节大促前夕，我依然把人开掉了，杀鸡给猴看。

当然，我不知道为什么有人做了10年的开发都可以忍受7-8K的薪水，而我™一个2年多的前端少于30K是绝对不干的，就因为从来没有想过书写别人难以维护的代码，而是希望当我请假的时候，项目中能力最弱的那个人也能修改我出产的代码。

就这样，你可以说我吹牛，不爽就喷我。又不会少收RMB，股份期权又没少掉，喷吧。

------------------
好了，你可以继续研究不可维护的代码，我也就随便说说，你别当真。然后过了一段时间，自己也看不懂了如果我是老板，碰到这样的员工，我宁愿下血本换人重构，也要把你开除了那你应该用 perl（不要为变量和函数随便地取名！！！
正确的姿势应该是：
1.认真地为它们取好名字
2.互换一下它们的名字

这样的破坏力绝对大！比乱取名还厉害！
哈哈哈！想想都醉了！！！哈哈哈不可维护的代码写起来并不难，但是：如果老板让你在现有的功能想加一个功能的时候，请问你怎么来维护自己的代码？

另外，你这样做，当老板把你送上法庭的时候，你可能发现，你欠下的债，是你一辈子都还不清的。

===============2015年10月13日更新==================
对不起，我对我之前不负责任的言论道歉。

如果想写出不可维护的PHP代码的话，请参考Discuz！
这是我今生见过的最著名的，开源，且几乎不可维护的PHP项目了。

声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系admin@php.cn核实处理。

专题推荐

独孤九贱-php全栈开发教程
全栈 170W+

主讲：Peter-Zhu 轻松幽默、简短易学，非常适合PHP学习入门
玉女心经-web前端开发教程
入门 80W+

主讲：灭绝师太由浅入深、明快简洁，非常适合前端学习入门
天龙八部-实战开发教程
实战 120W+

主讲：西门大官人思路清晰、严谨规范，适合有一定web编程基础学习