编码规范重要性_沟通比您的编码技能更重要

编码规范重要性

TL; DR (TL;DR)

Communication is More Important Than Your Coding Skills

沟通比您的编码技能更重要

A few short months ago when I started writing on Medium I vowed never to write a post with a clickbait title. So, there you have it. The title is the thesis to this whole post. Feel no obligation to continue reading (reading only the title is a common practice anyways, right?).

几个月前，当我开始在Medium上写作时，我发誓永远不会写带有clickbait标题的帖子。 所以你有它。 标题是整个帖子的论文。 感觉没有义务继续阅读(无论如何，只阅读标题是一种惯例，对吗？)。

沟通与编码 (Communication and Coding)

There’s a famous quote attributed to Phil Karlton:

菲尔·卡尔顿(Phil Karlton)有句著名的话：

There are only two hard things in Computer Science: cache invalidation and naming things.

在计算机科学中只有两件难事：缓存无效和命名。

That quote is certainly true while purely discussing the topic of computer science. If we expand to include areas that use computer science though, it’s clear that communication takes the cake as the hardest part.

在纯粹讨论计算机科学主题时，该引用肯定是正确的。 如果我们扩展到包括使用计算机科学的领域，那么很显然， 沟通是最困难的部分。

如果您无法交流，则无论您的编码水平如何都不重要 (It Doesn’t Matter How Well You Code, If You Can’t Communicate)

It’s true. Sure you need to be competent, but most developers already are, and have been for a long time. Communication is the skill that takes a junior, or medior, and makes them a senior. Or take a senior and makes them an even more effective senior. Communication is the skill that takes a good team member and makes them invaluable.

这是真的。 当然，您需要有能力，但是大多数开发人员已经并且已经从事了很长时间。 沟通是需要初级或中级才能使他们成为高级的技能。 或者选一个长辈，让他们成为更有效的长辈。 沟通是技巧，需要一个好的团队成员并使他们变得无价。

With that said let’s walk through many, if not all, aspects of being a developer and see why communication is important.

这样说来，让我们逐步了解成为开发人员的许多(如果不是全部)方面，并了解为什么沟通很重要。

拉取请求/代码评论 (Pull Requests/Code Reviews)

I hope you’re already doing code reviews for all new pull requests wherever it is that you work! If you’re not this is also something that can help take your skills to the next level. The opportunity to talk through your code with someone else and hear their perspective is extremely valuable and can help you learn a ton.

希望无论您在哪里工作，都已经对所有新的请求请求进行了代码审查！ 如果您不是，这也可以帮助您将技能提高到一个新的水平。 与其他人一起讨论您的代码并听取他们的观点的机会非常宝贵，可以帮助您学习很多东西。

But at the end of the day, code reviews are only as valuable as you make them. You need to be able to clearly explain your thought processes and decisions to enable the reviewer to truly grasp the whole picture. Some coding choices might seem strange at first to a reviewer who lacks full context of the problem being solved. They will rely on your communication to decide whether or not you’ve found the best possible solution to a problem.

但是，归根结底，代码审查的价值仅取决于您进行的审查。 您需要能够清楚地说明您的思维过程和决策，以使审阅者能够真正掌握整个情况。 对于缺乏充分解决问题的上下文的审阅者，某些编码选择一开始可能看起来很奇怪。 他们将依靠您的沟通来决定您是否找到了解决问题的最佳方案。

设计评论 (Design Reviews)

At many companies, large projects will often start with a design review. This is a meeting with stakeholders (or just interested people) where engineering architecture and design are discussed to find possible faults, or potential improvements.

在许多公司中，大型项目通常从设计审查开始。 这是与利益相关者(或只是感兴趣的人)举行的会议，讨论了工程架构和设计以发现可能的故障或潜在的改进。

However much like the code reviews the efficacy depends on your ability to articulate your thoughts. If you have the most brilliant architecture for a new product or tool in your head, its development can be hindered by your ability to convey it properly to your colleagues. Why would your VP of Engineering choose to invest time into a project that you yourself cannot explain. In theory it should be much easier to make a deck for a new project, then to actually execute it. Being able effectively convey potential designs and project plans will help you develop better projects, and will demonstrate that you can be trusted with interesting and tough assignments.

但是，就像代码审查一样，效力取决于您表达思想的能力。 如果您对新产品或工具拥有最出色的体系结构，则可能无法通过将其正确传达给同事的能力来阻碍其开发。 您的工程副总裁为什么会选择将时间投入您自己无法解释的项目中。 从理论上讲，为新项目创建平台，然后实际执行它应该容易得多。 能够有效地传达潜在的设计和项目计划将帮助您开发更好的项目，并证明您可以通过有趣而艰巨的任务得到信任。

撰写文件 (Writing Documentation)

Let’s be honest, writing documentation probably isn’t your favorite aspect of development. Yeah, me either. On the flip side, how amazing is it when you find an awesome tool (package, API, SDK, etc.) and it has awesome documentation along with it? An okay tool with great docs is always more useful than an extraordinary tool with no docs. Useful tools are only useful if you know how to use them.

老实说，编写文档可能不是您最喜欢的开发方面。 是的，我也是。 另一方面，当您找到了一个很棒的工具(程序包，API，SDK等) 并且它附带了很棒的文档时，它有多神奇？ 具有出色文档的好的工具总是比没有文档的非凡工具有用。 有用的工具仅在您知道如何使用它们时才有用。

With that in mind, you can boost the effectiveness of your own work simply by documenting it. That’s a pretty amazing thing, don’t you think? If you write decent code that does its job, and you can document it so that other people can easily use your code, it magically becomes 10x better code! Writing good documentation can be your X-factor.

考虑到这一点，您只需记录下来即可提高自己的工作效率。 这是一件非常了不起的事情，您不觉得吗？ 如果您编写了能发挥作用的体面代码，并且可以对其进行记录，以便其他人可以轻松使用您的代码，那么它神奇地变成了10倍更好的代码！ 编写良好的文档可能是您的X要素。

写评论 (Writing Comments)

I’m sure you’ve heard that your code should be clear enough that it doesn’t require comments to be understood. Your variable names should be perfect. Line length should be no more than 79 (nice, round number) characters. Functions and/or methods should be no more than 10 lines long. Right.

我敢肯定，您已经听说过您的代码应该足够清晰，不需要理解注释。 您的变量名应该是完美的。 行长不能超过79个字符(整数，整数)。 函数和/或方法的长度不得超过10行。 对。

If you’ve worked on a large software project you also know that it’s not always possible to adhere to this. You wish it were, but it’s just not. Sometimes a well-placed and succinct comment can really make all the difference.

如果您从事大型软件项目，那么您也知道并非总是可以遵守这一要求。 您希望它是，但事实并非如此。 有时，恰当而简短的评论确实可以发挥作用。

Kevlin Henney is a really great developer and speaker with many interesting (and hilarious) talks on YouTube. In one of his talks he said something along the lines of “If someone can’t write clear code, what makes you think they can write clear comments”. It’s a funny thought (and was delivered perfectly and got a big laugh from the audience), but I don’t really believe it to be true. Development skills are separate from communication (in this case written) skills. I’d argue the reason that comments are frowned upon is because most of them aren’t effective, not that they can’t be effective. If you stumble upon a difficult piece of code that takes you a while to figure out, and can leave behind a short, sweet, and helpful comment, you should go for it! The person behind you will praise your name.

Kevlin Henney是一位非常出色的开发人员和演讲者，在YouTube上进行了许多有趣的(有趣的)演讲。 在他的一次演讲中，他说了类似“如果某人无法编写清晰的代码，是什么让您认为他们可以编写清晰的注释”。 这是一个有趣的想法(传达得很好，并引起了观众的大笑)，但我真的不相信这是真的。 开发技能与沟通(在这种情况下为书面)技能是分开的。 我认为，意见是不可取的，因为他们大多是没有效果，不是说他们不能有效的原因。 如果您偶然发现一段困难的代码，需要花费一段时间才能弄清楚，并且可能留下简短，甜美和有用的注释，那么您应该去做！ 您背后的人会称赞您的名字。

管理期望 (Managing Expectations)

Have you ever gotten an impossible ask? A feature request that would require more computing power than exists on the planet? A UI design that looks more like a Picasso than the Material component library your whole product is built on?

你有没有想过的问题？ 一个功能要求比地球上需要更多的计算能力？ UI设计看起来更像毕加索，而不是整个产品所基于的Material组件库？

As developers it’s our jobs to make the magic happen. It’s not always clear to the folks giving you the work (be they product managers, executives, or whomever) what’s possible to do and what isn’t. It’s their job to ask, and it’s your job to answer.

作为开发人员，使魔术成真是我们的工作。 给您工作的人们(无论是产品经理，高管还是其他人)并不总是很清楚，哪些可以做，什么不可以做。 询问是他们的工作，回答是您的工作。

Let’s say your VP of Product comes to you with an impossible new feature or offering. If you can’t explain to them clearly, in less-than technical terms, why something can’t be done, it switches from a technical problem to a you problem.

假设您的产品副总裁为您提供了一项不可能的新功能或新产品。 如果您不能用不到技术的角度向他们清楚地解释为什么无法完成某事，那么它就会从技术问题转变为您的问题。

If you can explain in layman’s terms the technical limitations, they’ll understand that not everything they can dream up is doable. Plus you’ll be surprised at the ingenuity that arises when you get close to those limitations. You might just be able to dream up something better than your VP originally had planned.

如果您可以用通俗易懂的方式解释技术局限性，他们就会明白，并不是他们梦can以求的一切都是可行的。 另外，当您接近那些限制时，您会惊讶于出现的独创性。 您可能只能够梦想比您的副总裁原计划更好的事情。

管理时间表 (Managing Timelines)

Presumably every task you have has a deadline. Presumably a lot of those tasks aren’t done by that deadline. It happens to everyone. Especially in the world of estimates == deadlines, which is this world.

大概您的每个任务都有最后期限。 大概很多任务都没有在截止日期之前完成。 它发生在每个人身上。 尤其是在估算世界==截止日期的世界里。

Managers know not everything will be done on time. It’s not (always) a problem if something is late, but it is always a problem if something’s late without warning. Delays should be communicated early and often. Emails, slacks, task management tools, ticketing systems, whatever you use. The more you communicate your status the happier your higher-ups will be with your work. That’s not to say everything should be done late. But if something’s going to be late, which is inevitable, let it be known sooner than later.

管理人员知道并非所有事情都会按时完成。 如果某件事迟到了，这(永远)不是问题，但是如果某事迟到而没有警告，那总是一个问题。 延误应尽早并经常传达。 电子邮件，闲暇，任务管理工具，票务系统，无论您使用什么。 您传达的身份越多，上司的工作就越快乐。 这并不是说一切都应该晚做。 但是，如果某些事情要迟到了，这是不可避免的，那就让它早点被告知。

工作面试 (Job Interviews)

It’s obvious that communication is important in job interviews. You have to answer qualitative questions about yourself, your past experience, etc. The HR portion of the interview as they say. However, what if I told you that communication is equally as important in the technical portion, including the dreaded whiteboard interviews.

很明显，沟通在工作面试中很重要。 您必须回答有关您自己，您过去的经历等的质性问题。正如他们所说，面试的HR部分。 但是，如果我告诉您，沟通在技术部分(包括可怕的白板采访)中同样重要。

That’s right! Even if you come up with the smartest solution an interviewer has ever seen, it won’t matter if you can’t clearly explain your thought process. This video from Google about how to answer Google interview questions demonstrates this perfectly. You need to have a good answer in an interview, of course, but it needs to be accompanied by an even better explanation.

那就对了！ 即使您提出了面试官见过的最聪明的解决方案，但是如果您不能清楚地解释自己的思维过程也没关系。 Google的这段有关如何回答Google面试问题的视频完美地展示了这一点。 当然，您在面试中需要有一个很好的答案，但需要伴随一个更好的解释。

The reason for this is companies are hiring you to be part of a team. They want to see that you can communicate effectively so that your PRs, DRs, documentation, everything we’ve touched on before, will be valuable to the entire team.

原因是公司正在雇用您成为团队的一部分。 他们希望看到您可以有效地进行沟通，以便您的PR，DR，文档以及我们之前涉及的所有内容对整个团队都非常有价值。

走向繁荣 (Going Forth and Prospering)

It would be so simple if all we had to do as developers was code. It’s clear that communication is just as important as our coding skills. Luckily communication is also important for just about everything, and because of that there is an abundance of resources out there to help you improve.

如果我们作为开发人员要做的只是代码，那将是如此简单。 显然，沟通与我们的编码技能同样重要。 幸运的是，沟通对于几乎所有事情也很重要，因此，那里有大量资源可以帮助您改善。

Two great books I’ve read on the subject, that you might find helpful are:

我读过的两本很棒的书可能会对您有所帮助：

How to Win Friends and Influence People — by Dale CarnegieHow to Have Impossible Conversations: A Very Practical Guide — by James Lindsay and Peter Boghossian

如何赢得朋友和影响人 -戴尔·卡耐基(Dale Carnegie) 如何进行不可能的对话：非常实用的指南 -詹姆斯·林赛(James Lindsay)和彼得·博格西斯(Peter Boghossian)

Just being aware of how you’re communicating and the role it plays in your day-to-day work is an important first step. If you have any useful tips or tricks, or great resources please share them in the comments!

重要的第一步就是要了解自己在日常工作中的交流方式及其所扮演的角色。 如果您有任何有用的技巧，窍门或丰富的资源，请在评论中分享！

聚苯乙烯 (P.S.)

Some clickbait titles I would have considered were:

我会考虑的一些clickbait标题是：

• This One Skill Will Make You a 10x Dev

  这一项技能将使您获得10倍的开发

• The Secret No One Tells You About Excelling as a Developer

  没有人告诉过您关于作为开发人员表现卓越的秘密

• Transcend Your Peers and Achieve Engineering Nirvana… With This Skill

  超越您的同辈并达到工程必杀技……

That last one might have been a stretch.

最后一个可能会很麻烦。

翻译自: https://levelup.gitconnected.com/communication-is-more-important-than-your-coding-skills-de1f204bc197

编码规范重要性