代码不朽_这些常见的错误将导致不朽的错误。 了解如何避免它们。

代码不朽

by David Yu

由于大伟

这些常见的错误将导致不朽的错误。 了解如何避免它们。 (These common mistakes will lead to immortal bugs. Learn how to avoid them.)

Didn’t we already fix that?

我们不是已经解决了吗？

The question that you or your teammate would ask after the product manager posts a snapshot of the bug.

产品经理发布错误快照后，您或您的队友会问的问题。

This whole event feels like a Deja Vu. You try to retrace the time you fixed that bug in the commits, but what’s the point?

整个事件感觉就像Deja Vu。 您尝试回溯在提交中修复该错误的时间，但是有什么意义呢？

The reality is if you don’t get to the root cause of the bug, it will come back like the Hydra of Lerna.

现实是，如果您没有找到该错误的根本原因，它将像Lerna的九头蛇一样回来。

Here are some patterns that lead to immortal bugs.

这是导致不朽错误的一些模式。

硬编码值 (Hardcoding a value)

When we’re doing front-end development, we often use dummy data to build out the user interface quickly. That’s fine.

在进行前端开发时，我们经常使用虚拟数据来快速构建用户界面。 没关系。

The problem is having dummy data at multiple locations. Then it’s easy to forget one or two when you push your code.

问题是在多个位置都有伪数据。 然后，在推送代码时很容易忘记一两个。

Here are some tips:

这里有一些提示：

• Use a single variable for your dummy data and share it across different components
  对您的虚拟数据使用单个变量，并在不同组件之间共享

• Write a comment like // TODO: remove later to allow easy search later

  编写类似// TODO: remove later ，以便以后轻松搜索

• Don’t rely on backend data to always be the same
  不要依赖后端数据总是一样

// ?

<img src={require(`./assets/${backendData.fileName}.png`)} />

// This will break if fileName is an unexpected string

// ?

let img;

try {

img = require(`./assets/${backendData.fileName}.png`)

} catch(e) {  // Catch error if file doesn't exist

}<img src={img} />

// ?

<img src={backendData.imgUrl} />

让我们稍后重构 (Let’s Refactor Later)

Your codebase will only grow larger and larger as you work on it. Your client or your boss won’t know the negative effect of not refactoring the code, because everything looks fine on the surface.

您的代码库只会随着您的工作而变得越来越大。 您的客户或老板不会知道不重构代码的负面影响，因为表面上看起来一切都很好。

Plus, it’s always more satisfying to write something new and show it to other people. “Hey, check out what it can do now.”

另外，写一些新的东西并展示给其他人总是很满意的。 “嘿，看看它现在能做什么。”

So how do we know when to refactor the code?

那么我们如何知道何时重构代码？

According to Refactor Guru, follow the Rule of Three

根据Refactor Guru的说法，遵循三法则

1. When you are doing something for the first time, just get it done.
   当您第一次做某事时，只需完成即可。
2. When you are doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
   当您第二次做类似的事情时，您不得不重复，但无论如何都要做同样的事情。
3. When you are doing something for the third time, start refactoring.
   当您第三次执行某项操作时，请开始重构。

将所有内容保存在一个文件中 (Keep everything in one file)

This goes along with code refactor. When the project is fresh, it’s difficult to predict how large a feature will become.

这与代码重构一起。 当项目刚出现时，很难预测功能的规模。

In the past, I had a file that grew into thousands of lines of code. Refactoring that code is like performing surgery, delicate, but rewarding at the end.

过去，我有一个文件，后来变成了数千行代码。 重构该代码就像执行外科手术一样，精致但最终会有所回报。

Most people have a principle of how their project is structured. Separation of files by pages, features, dev. or production, private or public method, MVC model, etc.

大多数人都有一个关于项目结构的原则。 按页面，功能，开发文件分隔文件。 或生产，私有或公共方法，MVC模型等。

How to structure a project folder is a large discussion by itself. I will save that for another article.

如何构造项目文件夹本身就是一个大讨论。 我将其保存为另一篇文章。

不要编写API规范 (Don’t write specs for API)

“Wait, why don’t the pictures show up anymore?” the product manager asks the front-end developers.

“等等，为什么这些图片不再显示？” 产品经理询问前端开发人员。

“Wait, why doesn’t the data have the picture_url anymore?” The front-end developer checks the console for network response.

“等等，为什么数据不再有picture_url了？” 前端开发人员检查控制台的网络响应。

“Oh yea, now the pictures come in three sizes. large_pic_url, med_pic_url, small_pic_url.” The back-end developer heard the discussion and jumped in.

“哦，是的，现在这些图片有三种尺寸。 large_pic_url，med_pic_url，small_pic_url。” 后端开发人员听完了讨论并跳了进来。

Sounds familiar?

听起来很熟悉？

Everyone is trying to do their job. But synergy won’t happen in the silo. It’s everyone’s job to communicate what’s needed.

每个人都在努力工作。 但是协同作用不会在筒仓中发生。 交流需要的东西是每个人的工作。

Here are some simple solutions to start.

这里是一些简单的解决方案。

• Before building an API, start with a JSON file of the data that both front-end and back-end developers have access to.
  在构建API之前，请先从前端和后端开发人员均可访问的数据的JSON文件开始。

• When the API is completed, generate the document with https://github.com/apidoc/apidoc

  API完成后，请使用https://github.com/apidoc/apidoc生成文档

• Notify of breaking changes before deployment
  部署前通知重大更改

There are more sophisticated approaches to writing specs and handling documentation. And I would love to hear about what approach your team uses in the comment section.

有更复杂的方法来编写规范和处理文档。 我很想在评论部分中了解您的团队使用的方法。

合并代码而不会读取冲突 (Merge code without reading conflicts)

Breaking things is less of a worry since you can always revert back to the previous commit.

无需担心，因为总可以恢复到上一次提交。

It’s your or your teammate’s code disappearing during the process that’s the problem.

问题出在您或您队友的代码消失。

This often happens when you want to “save time” and move forward.

当您想“节省时间”并前进时，通常会发生这种情况。

When in doubt, get in contact with the developer who made the commit that conflicts with yours.

如有疑问，请与做出与您的冲突的提交的开发人员联系。

When you mess up, git merge --abort or git-reset --hard.

当您搞砸时， git merge --abort或git-reset --hard 。

When it breaks beyond repair, remove the project and clone it again.

当它无法修复时，请删除该项目并再次克隆它。

Think twice when doing git push -f.

做git push -f时请三思。

修复可重复使用的组件而无需测试 (Fix a reusable component without testing)

Reusable components are the magical trick up every developer’s sleeve. Like when the client pitches you the wireframe that contains the same date picker across several pages.

可重用的组件是每个开发人员的魔术。 就像客户向您推销时一样，跨多个页面包含相同日期选择器的线框。

In your mind, you think, “I am going to make an awesome date picker component. Write less code. Do more.”

在您看来，您会认为：“我将制作一个很棒的日期选择器组件。 编写更少的代码。 多做。”

A few months later, the client says, “I want the date picker in this page to explode with fireworks and on other pages, different kittens to represent months”. Now you need the date picker to be more dynamic than it was.

几个月后，客户说：“我希望此页面中的日期选择器因烟花而爆炸，在其他页面上，不同的小猫代表几个月。” 现在，您需要使日期选择器更具动态性。

Then after you make the changes, you discover that fireworks are coming out of the kittens.

然后，在进行更改之后，您会发现烟花从小猫身上冒出来。

If you are on a larger team, you can defer quality assurance to a different team.

如果您的团队规模较大，则可以将质量保证推迟到其他团队。

But if there is no such functionality in your organization, you will have to do a global search for your component’s name to see what your component affects.

但是，如果您的组织中没有此类功能，则必须对组件的名称进行全局搜索，以查看组件的影响。

Make a note to yourself of those files. Test those file visually and functionally depending on what they do.

给这些文件做个记录。 根据它们的功能在视觉上和功能上测试这些文件。

每当你说“现在很好” (Anytime you say, “It’s fine for now”)

You know you will have to go back to it later. The key is “don’t forget”

您知道以后将不得不重新使用它。 关键是“不要忘记”

When you decide between speed of development and stability of the software, we must be careful not to always put speed as a top priority. It’s similar to driving a car without ever checking the condition of the car.

当您决定开发速度和软件稳定性之间时，我们必须注意不要始终把速度放在第一位。 这类似于在不检查汽车状况的情况下驾驶汽车。

You can decide a ratio between speed and quality assurance. Maybe it’s two speedy iterations and one quality assurance iteration, whichever makes sense for your team.

您可以决定速度和质量保证之间的比例。 也许这是两次快速迭代和一次质量保证迭代，这对您的团队来说都是可行的。

结论 (Conclusion)

• Avoid hardcoding a value if you can. If you have to, leave a note for yourself.
  如果可以，请避免对值进行硬编码。 如果需要，请自己留个便条。
• Refactor when you’re doing the same thing for the third time.
  当您第三次执行相同的操作时，进行重构。
• Split code and refactor often
  拆分代码并经常重构
• Front-end and back-end engineers must work together to agree on the data being passed around.
  前端和后端工程师必须共同努力，以就传递的数据达成一致。
• If merge conflicts does not make sense to you, double check with the person who wrote the commit.
  如果合并冲突对您没有意义，请与编写提交的人仔细检查。
• When making changes to a reusable component, test for the location(s) where it’s being used.
  更改可重用组件时，请测试其使用位置。
• Find a healthy balance between speed and quality for your team.
  在团队的速度和质量之间找到健康的平衡。

当我们在这里时... (While we’re here…)

If you want to reach the 1 billion users of WeChat, you have to understand it first. Here’s a free glossary to get started.

如果要覆盖微信的十亿用户，您必须首先了解它。 这是一个免费的词汇表 开始。

翻译自: https://www.freecodecamp.org/news/these-common-mistakes-will-lead-to-immortal-bugs-learn-how-to-avoid-them-eee79ee43cd5/

代码不朽