sql做频繁模式挖掘代码_您应该更频繁地编写错误代码

sql做频繁模式挖掘代码

Every week a “don’t do this” article is posted somewhere. Don’t use inheritance, never write a singleton, scrum is dead. But are we really supposed to abandon it all? Is an if-statement really that bad a thing? How can we tell what advice is worth listening to?

每周都会在某处发布“请勿执行此操作”文章。 不要使用继承，不要写单例，scrum已经死了。 但是我们真的应该放弃这一切吗？ 如果陈述真的那么糟糕吗？ 我们如何知道哪些建议值得倾听？

There isn’t a perfect programming language, nor is there a right way to code. There are guidelines (and known pitfalls). Browsing through programming advice on the internet today is terrifying — everyone is telling you to stop doing something. Soon we’ll be out of commands to use. Everything is a source of bugs.

没有完美的编程语言，也没有正确的编码方法。 有准则(和已知的陷阱)。 如今，在Internet上浏览编程建议真是令人恐惧-每个人都告诉您停止做某事。 很快我们将无法使用命令。 一切都是错误的来源。

Consider this analogy: You don’t send a truck down a wooden bridge and expect it to reach the other side. That doesn’t means wooden bridges are dead nor that you should stop using trucks.

考虑一个比喻：您不要将卡车送下木桥，不要期望它会到达另一侧。 这并不意味着木桥已经死了，也不意味着您应该停止使用卡车。

Programming languages give us tools. It’s up to us to know when, why, and how to use them. Don’t throw your hammer away because you hit your finger — improve your aim.

编程语言为我们提供了工具。 我们有责任知道何时，为什么以及如何使用它们。 不要因为碰到手指而将锤子扔掉-提高目标。

如何发现不良建议？ (How to Spot Bad Advice?)

Good advice has three parts. First, the information itself, second, its when, and third its when not to. Bad advice often lacks the second and third part — it’s presented as something that always works.

好的建议包括三个部分。 首先，信息本身，第二个，它的时候 ，和三分之一的时候不要 。 错误的建议通常缺少第二部分和第三部分，它始终是可行的。

A common theme is to “avoid inheritance at all costs.” If left without the when or when not to, you might end up blindly following this and lose one of OO’s most essential tools. Instead, consider the following: “inheritance is a great tool. However, deep hierarchies are often harmful.” This time around its clear that the problem is depth. This explanation is far more precise and provides a direct insight into the matter, telling us that shallow hierarchies are fine.

一个共同的主题是“不惜一切代价避免继承”。 如果没有何时或何时不这样做 ，您可能会盲目地遵循此步骤，并失去OO最重要的工具之一。 相反，请考虑以下内容：“继承是一个很好的工具。 但是，深层次通常是有害的。” 这一次很明显，问题出在深度上。 这种解释要精确得多，并且可以提供对问题的直接见解，告诉我们浅层次结构是可以的。

Another thing to keep an eye on is language. Many writers are trained to “write boldly and never ask forgiveness.” This kind of tone is known to do well on the internet and particularly Medium. The problem is that boldness for the sake of boldness is damaging. People forget to add that their advice is not for every case. To avoid sounding weak, they ignore the when not to.

注意的另一件事是语言。 许多作家受过训练，可以“大胆地写作，从不要求宽恕”。 众所周知，这种音调在互联网上尤其是在Medium上效果很好。 问题在于，为了大胆而大胆具有破坏性。 人们忘记补充说，他们的建议并不适合所有情况。 为避免听起来微弱，他们会忽略何时不这样做 。

Good advice is friendly, not intimidating. Recall all the genuine help you have had over the years. Has any of it been given angrily?

好的建议是友善的，而不是令人生畏的。 回顾您多年来获得的所有真正帮助。 有没有生气地给它？

经验法则 (Rules of Thumb)

When it comes to coding, in particular, two rules of thumb apply:

特别是在编码方面，有两个经验法则适用：

1.语言的创建和维护成本很高。 如果某个功能不断添加到新语言中，那么它仍将发挥重要作用。 (1. Languages are expensive to create and maintain. If a feature keeps being added to new languages, it still has an important role to play.)

That’s why the global scope is still a thing, as is inheritance and the if-statement. Any article stating that those should be avoided entirely is missing a pretty important aspect of these features.

这就是为什么全局范围以及继承和if语句仍然是一个问题的原因。 任何一篇文章指出应该完全避免这些操作，却缺少了这些功能的一个非常重要的方面。

A good example is typing. The sensual type-less world of Python and JavaScript allured many developers to their embrace, who would later regret writing ten thousand lines in such unstructured languages. None of that existed on the old fashioned world of Java and C# (which doesn’t mean they were any paradise either).

一个很好的例子是打字。 Python和JavaScript的无类型感世界吸引了许多开发人员，他们后来对使用这种非结构化语言编写一万行代码感到遗憾。 在Java和C＃的老式世界中，没有一个存在(这也不意味着它们是任何天堂)。

It is no wonder TypeScript is a thing. Typing has returned as loosely typed languages — you type just enough, the compiler fills the rest. This idea was so successful that it entered the C# and C++ worlds, through the var and auto keywords, respectively. Even Python has typing features by now.

难怪TypeScript是一回事。 键入已返回为松散类型的语言-您键入的恰好足够，其余的由编译器填充。 这个想法非常成功，以至于通过var进入了C＃和C ++世界 和auto 关键字。 甚至Python现在都具有打字功能。

In the opposite direction, the second rule of thumb is:

相反，第二个经验法则是：

2.现代语言通过设计消除了所有真正令人讨厌的东西 (2. Modern languages have taken down all the really nasty stuff by design)

That’s why we don’t see macros anymore or goto statements or explicit memory management. Java had quite some bad press for its GC back in the day, but GCs have outgrown the JVM to pretty much all modern languages.

这就是为什么我们不再看到宏或goto 语句或显式内存管理。 过去，Java对GC的要求不高，但对于几乎所有现代语言来说，GC都已超越了JVM。

A recent removal is the null pointer exception. Modern languages like Kotlin and Swift enforce null checking by design. C# 8 is following a similar route. Raw threading and async callbacks have also had their share of problems. Now, we code asynchronous tasks with handy async/await constructs.

最近删除的是空指针异常 。 像Kotlin和Swift这样的现代语言在设计上会强制执行null检查。 C＃8遵循类似的路线。 原始线程和异步回调也有很多问题。 现在，我们使用方便的async / await结构编写异步任务。

All this brings us to the following:

所有这些将我们带到以下几点：

如果您想成为更好的程序员，请了解编程语言的历史 (If you want to be a better coder, learn about programming language history)

While most languages were born out of individuals with an excellent sense of tooling, their developments are led by committees. Whenever new features are added, there is an entire body of work dedicated to discussing their relevance and worth to the community, as well as to perfect its design. The same goes for changing and removing features. Python 3 brought many breaking changes that were hard to ignore, but it all paid off.

尽管大多数语言是由具有出色工具意识的人诞生的，但它们的发展却由委员会领导。 每当添加新功能时，都会进行一整套工作，以讨论它们与社区的相关性和价值，以及完善其设计。 更改和删除功能也是如此。 Python 3带来了许多难以忽视的重大更改，但所有这些都得到了回报。

经常写错误代码 (Write Bad Code More Often)

All we use is the product of decades of innovations and failed designs.

我们使用的只是数十年创新和失败设计的产物。

You can only truly grasp the beauty of a garbage collected language if you dive on some nasty C/C++ code. Until then, all you can do is imagine how painful it was back in the day. The whole hate over singletons can only really be understood by those that got to write one and faced the many issues associated with them (such as writing tests).

如果您沉迷于一些讨厌的C / C ++代码，则只能真正掌握垃圾收集语言的优点。 在那之前，您所能做的只是想像一下当日的痛苦。 对于那些单身人士的仇恨只能由那些必须编写单身并且面对许多与之相关的问题(例如编写测试)的人来理解。

Theres a whole world between textbook samples and real-life experience. The former is no more than a hint; the latter really changes how you code.

教科书样本和现实经验之间存在一个世界。 前者不过是一个提示而已。 后者确实改变了您的编码方式。

Most of us, back in our beginner days, coded without Git or Unit Tests. These projects tended to be buggy, and, more often than not, they would stop working at all. Without Git, you couldn’t tell what you might have accidentally changed. Without tests, things would stop working days before you bumped into them again. This experience is what motivates us to use these tools every day.

我们中的大多数人，在我们开始的时候，都没有Git或单元测试的编码。 这些项目往往是越野车，而且往往会完全停止工作。 没有Git，您将无法判断自己可能意外更改了什么。 如果没有测试，事情将在几天后停止工作。 正是这种经验促使我们每天使用这些工具。

To truly understand how to write good code, you must write bad code first.

要真正理解如何编写好的代码，您必须首先编写不好的代码。

There a couple of ways you can force yourself to write bad code (or to see ugliness in your current snippets). It all boils down to one thing: try coding some other way. This will either show you how much better your solution is or how stupid it was (“was” because you’ll change it, right?)

您可以通过两种方法强迫自己编写错误的代码(或查看当前片段中的丑陋情况)。 归结为一件事： 尝试以其他方式编码 。 这将显示出您的解决方案有多好或有多愚蠢(“是”是因为您将对其进行更改，对吗？)

Here’s a list of things you can do in your spare time:

以下是您在业余时间可以做的事情的列表：

1. Learn a Parent Language: Kotlin, for instance, is inspired by Scala. Swift, among other things, tries to solve Objective-C issues. C# superseded Java. Learning parent languages teach you how much of “what you have now” was not present back then (and what it solves). It will teach you to appreciate more a lot of things you might otherwise think are crap.

   学习母语：例如，Kotlin受Scala的启发。 除其他外，Swift试图解决Objective-C问题。 C＃取代了Java。 通过学习母语，您可以了解当时没有多少“现在拥有的东西”(以及它可以解决的问题)。 它会教您欣赏更多您可能认为很糟糕的事情。

2. Learn a “Successor” Language: If you are a C++ developer, you should try Rust. Java folks should give Go a go. Python users might try Julia or Nim. JavaScript guys ought to try TypeScript or maybe Dart. Unlike learning a parent language, this will show you how much of what you do now is crap and how it could be better handled.

   学习“后继”语言：如果您是C ++开发人员，则应尝试Rust。 Java专家应该放手一搏。 Python用户可以尝试使用Julia或Nim。 JavaScript的人应该尝试TypeScript或Dart。 与学习母语不同，这将向您显示您现在所做的大部分工作都是垃圾，以及如何更好地处理。

3. Learn LISP: This is a weird one for many. LISP has no variables. It is a fully functional programming language (that’s easier than Haskell). You don’t need to be any proficient with it, but try writing some algorithms, such as Fibonacci, quick-sort, or Huffman coding. If you take your time to do so, you will realize how variables are, many times, unnecessary.

   了解LISP：这对许多人来说都是很奇怪的。 LISP没有变量。 它是一种功能齐全的编程语言(比Haskell容易)。 您不需要精通它，而是尝试编写一些算法，例如Fibonacci，快速排序或霍夫曼编码。 如果花时间这样做，您将认识到变量是很多不必要的。

4. Write a Text Processor in Plain-C: Given a path to a text file, open it, remove all line breaks, and add new breaks after every period (.) character. Then, shuffle each word keeping the first and last characters unchanged. Bonus points if you process each line in parallel. This will (quickly) show you how string processing has evolved dramatically.

   用Plain-C编写文本处理器：给文本文件指定一个路径，将其打开，删除所有换行符，并在每个句点( . )字符后添加新的换行符。 然后，对每个单词进行混洗，使第一个和最后一个字符保持不变。 如果您并行处理每行，将获得加分。 这将(Swift)向您展示字符串处理是如何急剧发展的。

5. Look for Design Patterns: Take a list of design patterns, such as this one, and open up some project you work or worked on. Take your time to read about each pattern and try finding places that could benefit from one of such patterns. For each one you see, try picturing how much cleaner it would be if you had used it (bonus points if you refactor it). This is the best way to incorporate design patterns into your repertoire.

   查找设计模式：列出一系列设计模式( 例如) ，然后打开您正在工作或从事的某些项目。 花些时间阅读每种模式，然后尝试找到可以从其中一种模式中受益的地方。 对于您看到的每一个，尝试想象一下如果使用过它会干净得多(如果您重构它，可以得到加分)。 这是将设计模式整合到您的曲目中的最佳方法。

These tips, in essence, are all trying to either make you code differently or take a second look at what you have already done. Either way, you’ll notice that not everything is as shiny as you might have once thought.

从本质上讲，这些技巧都在试图使您的代码有所不同，或者重新考虑您已完成的工作。 无论哪种方式，您都会注意到，并非所有事物都像您曾经想过的那样闪闪发光。

Besides, I am not telling you what’s wrong or what is right, nor how to code. Instead, I invite you to…code. Code in a new language. Try doing the same thing in two different ways. Coding is the way to be a better coder. Not reading some random blog posts on the internet.

此外，我不会告诉您什么地方出了问题或什么是正确的，也没有告诉您如何编码。 相反，我邀请您进行编码。 用新语言编码。 尝试以两种不同的方式做同样的事情。 编码是成为更好的编码器的方法。 不阅读互联网上的一些随机博客文章。

Thanks for reading!

谢谢阅读！

翻译自: https://medium.com/better-programming/you-should-write-bad-code-more-often-388c6f1ba5a

sql做频繁模式挖掘代码