In this tutorial I want to illustrate how to write unmaintainable code.
在本教程中，我想说明如何编写不可维护的代码。
By writing unmaintainable code you can make sure you will never get fired because you’ll be the only one capable of understanding what the code does, and most importantly why.
通过编写代码难于维护，你可以确保你将永远不会被解雇 ，因为你是能够唯一的理解代码做什么 ，最重要的原因 。
Please note: this post is ironic
请注意：此文章具有讽刺意味
- Assign weird, fantasy and casual names to your variables, functions and objects. There should be no correlation between the name and what the item does or how it behaves. 为变量，函数和对象分配怪异，幻想和随意的名称。 名称与项目功能或行为方式之间不应存在任何关联。
- Prefer abbreviations and acronyms over descriptive names. One-letter variables are great. 相对于描述性名称，首选缩写和首字母缩写。 一个字母的变量很棒。
Favor reuse of variables in the code. Always use
iin your loops.支持在代码中重用变量。 始终在循环中使用
i。- Use your own language for names. After all, there’s no need to all use English. 使用您自己的语言命名。 毕竟，没有必要全部使用英语。
- Same applies to comments. Feel free to write them in whatever language you speak, who cares if the next developer is from another country? 注释同样适用。 随意用您说的任何语言编写它们，谁在乎下一位开发人员是否来自另一个国家？
- As for comments, I was joking. Do not write any comments. 至于评论，我在开玩笑。 不要写任何评论。
- If you really want to write comments, do not bother to update them when you change the code that they describe. 如果您确实想编写注释，则在更改它们描述的代码时，不必费心更新它们。
- Prefer global variables over getting too clever with scoping 优先考虑全局变量而不是对范围定义过于精明
- Never test your code. You are good, your code is good too. 永远不要测试您的代码。 您很好，您的代码也很好。
- Prefer overcomplicating than being too simplistic. No one was ever fired for creating a complex and ego-fulfilling architecture that required a 3-months long useless rewrite of code that was perfectly working. 与其说过于简单，不如说过于复杂。 没有人因为创建一个复杂的，自我实现的架构而被解雇，该架构需要3个月的无用重写才能完美运行。
- Optimize whatever you can in clever ways. Computers are slow, we should avoid overheating them and help fight climate change. Rewrite your code in assembly is often a good idea. 巧妙地优化您的一切。 计算机运行缓慢，我们应避免计算机过热并帮助应对气候变化。 在汇编中重写代码通常是一个好主意。
- Relatively unknown languages and frameworks are always better than popular and battle tested solutions. Prefer them over the solution everyone else uses. 相对未知的语言和框架总是比流行和经过战斗验证的解决方案更好。 他们比其他所有人使用的解决方案更可取。
- Better yet, create your own framework. 更好的是，创建自己的框架。
- Never use 3rd party libraries 永远不要使用第三方库
- Overuse 3rd party libraries 过度使用第三方库
- Use every design pattern you read about, and try to fit it into your design even if it’s not, really 使用您所阅读的每种设计模式，并尽力将其融入您的设计中
- Use tools built by large corporations because they know it better and your 1-person startup will surely benefit from the thousands of man hours that went into building them. Bonus points if they are very complicated to use and have their own set of clever-sounding naming conventions. 使用大型公司构建的工具，因为他们会更好地了解它，并且您的1人创业公司肯定会从构建它们的数千工时中受益。 如果它们使用起来非常复杂并且有一套自己的听起来不错的命名约定，则可以加分。
Do not use version control, and do not even version the code at all. After all there’s just one right version of the program. You can easily remember all the changes you perform and most importantly why a change was made. No need to track it in an external repository.
不要使用版本控制，甚至也不要对代码进行版本控制。 毕竟，该程序只有一个正确的版本。 您可以轻松记住您执行的所有更改，最重要的是进行更改的原因 。 无需在外部存储库中跟踪它。
- Freely copy and paste code from Stack Overflow or random blogs without understanding it first 从Stack Overflow或随机博客中自由复制和粘贴代码，而无需先了解它
- Indentation does not matter. At all. Mix spaces and tabs, too. 缩进无关紧要。 完全没有 也要混合空格和制表符。
- Freely overuse abstractions. Abstractions are great. Make everything reusable and overthink things like a king. 自由使用抽象。 抽象很棒。 使一切都可重用，并像国王一样思考过多。
- Perhaps you’ll reuse this library in every project you’ll make in the next 20 years, who knows? Better think about all the possible edge cases first. 也许您会在未来20年内将在每个项目中重用该库，谁知道呢？ 最好先考虑所有可能的极端情况。
- Always implement every single great idea you have 始终实施您拥有的每一个好主意
- 2000-lines functions are a great idea 2000行功能是个好主意
- Assume there’s a 10x engineer watching over your shoulders while you code. 假设在编写代码时有10倍的工程师在您的肩膀上看着。
扫一扫
2927
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
