我真的知道编程吗-CSDN博客

According to SlashData, in 2019 the world reached 26.4 million active software developers.

根据SlashData的数据，2019年全球活跃软件开发人员达到2640万。

Whether you’ve been in IT since the beginning of your career or you just started, the question you should ask yourself is the same: Do I really know programming?

无论您是从职业生涯开始还是一直从事IT工作，您都应该问自己一个问题：我真的知道编程吗？

两个程序员 (The Two Programmers)

Though countless shades and differences exist between programmers, I’ve most often met two types in my life: the impostor and the self-confident programmer.

尽管程序员之间存在无数的阴影和差异，但我一生中经常遇到两种类型：冒名顶替者和自信的程序员。

冒名顶替者 (The impostors)

Impostors, a category I sometimes include myself in, are those developers who never feel adequate enough for their role. The constant fear of not being good enough for a job or responsibility seeds doubt that we’re not doing enough to keep the fast pace of evolving technology, making us feel behind the group.

冒名顶替者(那些有时我自己也属于其中的人)是那些从来没有对自己的角色感到足够满意的开发者。人们一直担心自己不能胜任出色的工作或承担责任，这引发了人们的怀疑，即我们没有为保持技术的快速发展做出足够的努力，这使我们感到自己落后于团队。

This often leads to always studying more and more to fill that gap — which, in the process, transforms us into more skilled developers than we even realize.

这通常导致需要进行越来越多的研究以填补这一空白，在此过程中，这使我们成为了甚至超过我们所能意识到的更加熟练的开发人员。

However, being someone affected by impostor syndrome isn’t something to be ashamed of. Around 70% of all developers have gone through this state of mind at least once in their life, so it’s pretty common, especially at the beginning of one’s career, when what we know is still a drop in the ocean.

但是，受冒名顶替综合症影响的人并不感到羞耻。大约70％的开发人员在一生中至少经历过一次这种状态，因此这很普遍，尤其是在职业生涯的开始，那时我们所知道的仍然是沧海一粟。

自信的程序员 (The self-confident programmers)

On the other hand, some programmers have the exact opposite perspective of their skill level. I’ve passed through a phase of this as well, luckily realizing it before it was too late.

另一方面，某些程序员在技能水平上却截然相反。我也经历了一个阶段，幸运的是，在为时已晚之前意识到了这一点。

I’m talking about when we become overconfident with our own skills and believe we are extreme programmers.

我说的是什么时候我们对自己的技能过于自信，并相信我们是极端的程序员。

Achieving our first coding successes on simple projects is a really good feeling, of course. It finally shows us that we can do it — that we’re coding. But with great powers shouldn’t come the following aspects:

当然，在简单项目上实现我们的首次编码成功是一种非常好的感觉。最后，它向我们表明我们可以做到—我们正在编码。但是，拥有强大能力的人不应该涉及以下方面：

Arrogance: Every time we believe our solution is better than someone else’s, we’re taking is one step closer to a closed mindset. In programming, there are tons of solutions to the same problem, and never comparing what we do because we think our solution is the greatest doesn’t help since we limit our chances of seeing the problem from a different perspective.
傲慢：每当我们认为我们的解决方案比别人的解决方案都要好时，我们所采取的措施就比封闭的心态迈出了一步。在编程中，有很多解决同一问题的解决方案，并且从不比较我们所做的事情，因为我们认为我们的解决方案是最大的，这无济于事，因为我们限制了从不同角度看问题的机会。
Laziness: Just because we cover an important role in our company or we demonstrate a good breadth of knowledge on a specific topic doesn’t mean we’re at the top of our career or that it’s time to take a seat and stop learning. No one will ever know everything, and the moment we stop being curious is the real end of our growth as developers.
懒惰：仅仅因为我们在公司中担当了重要角色，或者在某个特定主题上展示了广博的知识，并不意味着我们处于职业生涯的顶峰，或者是时候坐下来停止学习。没有人会一无所知，而当我们停止好奇时，便是我们作为开发人员成长的真正终点。

Unluckily, I used to be affected by the first (and worst) of these aspects, feeling like a god when I really knew nothing about coding. And I still don’t.

不幸的是，我曾经受到这些方面的第一个(也是最糟糕的)的影响，当我对编码一无所知时，我感觉像个上帝。而且我仍然没有。

But the right people will always help us get better, not only as developers but as human beings as well.

但是合适的人将永远帮助我们变得更好，不仅是作为开发人员，还是作为人类。

For me, this help came in the form of feedback from my former CTO. I had been working for a bit more than one year at the company, and I was cocky enough to think I was doing really good as a programmer and that my level was really advanced. I had never been so wrong.

对我而言，此帮助来自我以前的CTO的反馈。我在公司工作了一年多，而且我很自负，以为自己做程序员真的很出色，而且我的水平真的很先进。我从来没有错。

Speaking with him, he helped me realize that my skills as a developer were nothing without the most important one: being able to listen.

与他交谈时，他帮助我认识到，作为开发人员，我的技能离不开最重要的一个：能够听。

When you start listening more to other people’s opinions without rushing in to expose yours, you’ll gain more value in their eyes — and hopefully in your own as well.

当您开始更多地听取别人的意见而又不急于公开自己的意见时，您会在他们的眼中获得更多的价值，希望自己也能有所收获。

This has been a real change for me, and I continue to look at making my future choices hold more of an open view of how to behave as a programmer.

对我来说，这是一个真正的变化，我将继续着眼于使我未来的选择更多地体现出如何成为一名程序员。

我知道什么？ (What Do I Know?)

To define our programming-knowledge level, we can’t simply ask our grandma if we’re good enough — that doesn’t work since they love us more than anybody else.

要定义我们的编程知识水平，我们不能简单地问我们的奶奶我们是否足够好–这是行不通的，因为他们比任何人都更爱我们。

To make this distinction, it’s important to define some criteria for establishing our competence level. But before doingthat, I’d like to state something I think is really important to interiorize:

为了做到这一点，重要的是定义一些标准来建立我们的能力水平。但在此之前，我想说明一些我认为对内部化非常重要的内容：

There are no bad programmers — only less experienced ones.

没有糟糕的程序员，只有经验不足的程序员。

This is really important because it gives a different perspective and reminds each of us of how we were when coding our first lines of code.

这一点非常重要，因为它给出了不同的观点，并提醒我们每个人在编写第一行代码时的状态。

So how do we evaluate if we really know to code? For this exercise, I’ll refer to “The Four Pillars of a Good Software Developer” described really well by Bradley Braithwaite.

那么我们如何评估我们是否真的知道编码呢？对于本练习，我将参考Bradley Braithwaite所描述的“优秀软件开发人员的四个Struts”。

代码质量 (Code Quality)

When I inspect some of my code, a natural question I ask myself is “Does this snippet look good enough to be understood by myself in one week?”

当我检查一些代码时，我自然会问自己：“这段代码看起来是否足够好，一周之内就可以被我自己理解？”

This makes the code quality aspect much more personal since everyone has a different perspective. However, there’s a list of generic questions we can answer in order to determine if we effectively respect good standards or if we can improve:

因为每个人都有不同的看法，所以这使得代码质量方面更加个性化。但是，我们可以回答一些通用问题，以确定我们是否有效地遵守了良好的标准或是否可以改进：

我的代码容易阅读吗？ (Is my code easily readable?)

Code readability should be one of our main concerns. Modern programming languages introduced lots of fancy and short-syntax tricks to allow for less verbose code, creating a lot of one-line coders, who tend to use them to write less.

代码的可读性应该是我们主要关注的问题之一。现代编程语言引入了许多花哨的语法和短语法技巧，以减少冗长的代码，从而创建了许多单行编码器，这些编码器倾向于使用它们来编写更少的代码。

That’s good for our ego because it makes us proud of the cool feature written in one single line, but when you go to check the same code after six weeks, you’ll have loved if you had used a more descriptive syntax of what that snippet was supposed to do.

这对我们的自我是有好处的，因为它使我们为单行编写的出色功能感到自豪，但是当您六周后去检查相同的代码时，如果您使用了该代码段的更具描述性的语法，那您一定会很喜欢本来应该做的。

The same function written in different versions. — The same function written in different versions

What we tend to forget is that while it may not be difficult for a computer to understand our code, for humans it is. We should write our code so people can understand it. For a computer, those lines will get converted to 0s and 1s, so it doesn’t matter if you used a cool syntax or something more descriptive.

我们倾向于忘记的是，虽然计算机可能并不难理解我们的代码，但对人类而言却并非如此。我们应该编写代码，以便人们可以理解它。对于计算机，这些行将转换为0和1，因此，无论您使用的是凉爽的语法还是更具描述性的内容，都没有关系。

“Code is for humans.”

“代码是给人类的。”

— Kyle Simpson

—凯尔·辛普森(Kyle Simpson)

我的代码是否一致？ (Is my code consistent?)

Being consistent when writing code is as important as writing clean code.

编写代码时保持一致与编写干净的代码一样重要。

You can follow your favorite code style — it doesn’t really matter. What is essential for keeping your code well-written and easy to read is to stick to that coding style so that others reading your code base can easily navigate it.

您可以遵循自己喜欢的代码样式-没关系。保持代码的良好编写和易读性的本质是坚持那种编码风格，以便其他阅读您的代码库的人可以轻松地对其进行导航。

There are plenty of good guidelines that can help us to discover what our coding style should be, especially some well-written books — which I recommended in “4 Books Everyone in Tech Should Read and Why.” They’ve been essentials to me for building my own coding practices.

有很多好的指南可以帮助我们发现我们的编码风格，尤其是一些写得很好的书，我在“技术中的每个人都应该读的四本书和为什么”中推荐了这些书。对于我建立自己的编码实践来说，它们是必不可少的。

代码正确性 (Code Correctness)

Now that we got an idea on how we should write our code to keep it clean and maintainable, there’s a little detail we should take care of: Your code should work as expected.

既然我们已经知道如何编写代码以保持代码的清洁和可维护，我们应该注意一些细节：您的代码应该按预期工作。

What I mean is we should write code that not only matches the requirements we have for it but also takes care of corner cases and error cases. Just to go straight to the point, check the following snippet, where we want to write a function that sums two numbers:

我的意思是，我们应该编写不仅符合我们要求的代码，而且还要处理极端情况和错误情况。只是为了直截了当，请检查以下代码段，我们要在其中编写一个将两个数字相加的函数：

A function to sum two numbers. It doesn’t cover corner cases.

Do you see what I mean? This function is actually receiving two numbers and returning their sum, but it only covers the best scenario. In case we pass something different from numbers as parameters, it’ll behave differently from the required functionality.

你明白我的意思吗？该函数实际上是接收两个数字并返回它们的和，但是它仅涵盖最佳情况。如果我们将数字以外的内容作为参数传递，则其行为将与所需的功能有所不同。

This simple example gives us some questions to answer:

这个简单的例子给我们一些问题要回答：

Do I cover edge cases and different behaviors in my code?
我是否在代码中涵盖了极端情况和不同的行为？
Do I handle errors in case they occur in my code?
如果我的代码中出现错误，我该如何处理？
Do I test properly my code functionalities?
我是否可以正确测试我的代码功能？
Does this code depend on external dependencies I should consider?
此代码是否取决于我应该考虑的外部依赖关系？

We can keep these questions as a checklist our code should respect when creating new functionalities (or refactoring them). Of course, it’s not always possible to do everything perfectly, but always aiming to solidify our code into its role is a good way to become a great developer!

我们可以将这些问题保留为清单，以确保我们的代码在创建新功能(或重构它们)时应予以尊重。当然，并非总是可以完美地完成所有事情，但是始终以巩固我们的代码为目标是成为优秀开发者的好方法！

“Perfection is not attainable, but if we chase perfection we can catch excellence.”

“不可能达到完美，但是如果我们追求完美，我们就可以追求卓越。”

— Vince Lombardi

—文斯·伦巴第

代码性能(Code Performance)

After seeing that our code looks good, is maintainable, and satisfies all the correctness requirements, we can start going deep down into the rabbit hole of software programming and talk about performance.

在看到我们的代码看起来不错，可维护并且满足所有正确性要求之后，我们可以开始深入研究软件编程的难题，并讨论性能。

I really care about how performant my code is, and this usually is the biggest mistake I keep repeating: Writing fast and reliable code is important, but overthinking your code and including premature optimizations can literally destroy your productivity and slow down functionality.

我真的很在乎我的代码的性能，这通常是我不断重复的最大错误：编写快速可靠的代码很重要，但是过分考虑代码并包括过早的优化会从根本上破坏生产力并降低功能。

We can’t neglect the need to write our implementation so users can enjoy a smooth experience with our software. However, we should do it step by step.

我们不能忽略编写我们的实现的需求，以便用户可以享受我们软件的流畅体验。但是，我们应该逐步进行。

性能代码的5条诫命 (The 5 commandments of performant code)

There are some simple rules I try to follow (not always successfully) that are a good starting point:

我尝试遵循一些简单的规则(并非总是成功)，这是一个很好的起点：

Make it work. Then refactor. Then deep optimize.
让它起作用。然后重构。然后进行深度优化。
Don’t trade code quality for code performance (if the app isn’t strictly performance-sensitive).
不要以代码质量为代价来换取代码性能(如果该应用对性能不严格敏感)。
If the code has external dependencies, check how they work before optimizing.
如果代码具有外部依赖性，请在优化之前检查它们的工作方式。
Measure performance when integrating new code to immediately detect possible deoptimizations.
集成新代码以立即检测可能的反优化时，请评估性能。
If it’s an architectural decision, deeply think about the right data structure to use.
如果这是一个体系结构决策，请仔细考虑要使用的正确数据结构。

Following these suggestions will definitely make you slower in the beginning, but repeating them in cycles and making mistakes, in the long term, will improve the way you work, allowing you to automatically follow better practices and reduce errors.

遵循这些建议无疑会使您起步较慢，但是从长远来看，不断重复这些建议并犯错会改善您的工作方式，使您能够自动遵循更好的做法并减少错误。

代码生产力 (Code Productivity)

Do more. — Photo by Carl Heyerdahl on Unsplash

With practice, all developers in the long term get better. They learn to apply solid programming principles and know how to write professional code. Something that may distinguish the excellent develop from simply the good developer is how productive they are on producing their qualitative code.

通过实践，所有开发人员从长远来看都会变得更好。他们学会应用扎实的编程原则，并且知道如何编写专业代码。优秀开发人员和优秀开发人员可能区分开来的一点是，他们在生产定性代码方面的生产力。

Here again, we could ask ourselves some questions:

再一次，我们可以问自己一些问题：

Do I know my coding rhythm?Getting an idea of what distracts us, how often we need a break, or what makes us delay our tasks is the first step in preventing that situation where you find yourself looking at your screen with no idea of how to implement something. Get to know yourself and your habits in order to be able to fully concentrate and stay productive.
我知道我的编码节奏吗？ 了解防止我们分心，需要多长时间休息或使我们延迟工作的原因，这是预防这种情况的第一步，即您不知道如何执行某些操作而看着自己的屏幕。了解自己和您的习惯，以便能够完全专注并保持生产力。
Do I automate my tasks?Programmers are people who program, so who’s better than us to give instructions to our devices on how to do tasks we repeat many times?
我可以自动执行任务吗？ 程序员是编程的人，所以谁比我们更好地向我们的设备提供有关如何重复执行多次任务的指令？

For example, I wrote a script to automate a release process at our company, which save us much more time than we could have expected on every iteration.
例如，我编写了一个脚本来自动化公司的发布过程，这比我们每次迭代节省的时间要多得多。
Do I know my tools?Thanks to recent progress in software development, we have plenty of amazing tools, such as IDEs, task managers, terminals, and much more. Using them at 100% of their potential can boost our productivity so much — soon we’ll forget how we ever used to be so slow at moving the mouse across the screen just to close windows. Whenever you start using a new tool, inspect all the possibilities it has, and learn how to integrate them into your workflow.
我知道我的工具吗？ 得益于软件开发方面的最新进展，我们提供了许多出色的工具，例如IDE，任务管理器，终端等。以100％的潜力使用它们可以极大地提高我们的生产力-很快我们就会忘记过去曾经如此缓慢地在屏幕上移动鼠标以关闭窗口的过程。每当您开始使用新工具时，请检查它的所有可能性，并了解如何将它们集成到您的工作流程中。

第五Struts (The Fifth Pillar)

In the beginning, I said to refer to the four pillars to answer our question about how much we know about programming, but that was a lie. There’s a last pillar which I consider the most important — the one that characterizes the best developers.

在开始时，我说过要参照四个Struts来回答我们对编程了解多少的问题，但这只是一个谎言。我认为最后一个Struts是最重要的-代表最佳开发人员的Struts。

It’s about communication. The greatest developers in the world are those able to communicate and explain easily how their code works or makes concrete an abstraction.

这是关于沟通的。 世界上最伟大的开发人员是能够交流和轻松解释他们的代码如何工作或具体化抽象的开发人员。

Teachers, conference speakers, writers … all of them not only prove to be great programmers but also to be able to make others become great, giving pills of wisdom in a way that would be more difficult to learn alone.

老师，会议演讲者，作家……所有这些人不仅被证明是优秀的程序员，而且还能够使其他人变得更好，以一种难以独自学习的方式给予智慧。

“If you can’t explain it simply, you don’t understand it well enough.”

“如果您不能简单地解释它，那么您将无法充分理解它。”

— Albert Einstein

- 艾尔伯特爱因斯坦

结语(Wrapping Up)

This has been a long reflection I started some time ago that I wanted to share with you. I hope you’ll reap the benefits of asking more questions of yourself — and answering them, as I did.

这是我很久以前就开始想与大家分享的反思。我希望您能像我一样，从问自己更多的问题中获益，并回答自己的问题。

Thanks for reading!

谢谢阅读！