团队编写代码

Software is rarely written in a silo. Whether you’re building the next social media app for mimes at some SF startup or maintaining a legacy system for a faceless company in Idaho, you are almost certainly working on a team. But working on a team and being a team are different things. It’s entirely possible to have a team of individuals, basically rogue coding their way through tickets, cohesiveness be damned.

软件很少用孤岛编写。 无论您是要在某个SF初创公司为哑剧制作下一个社交媒体应用程序，还是为爱达荷州一家不知名的公司维护旧系统，几乎都可以在团队中工作。 但是团队合作和团队合作是不同的。 完全有可能有一个个人团队，基本上是无赖编码票证的方式，该死的凝聚力。

但是，为什么如此重要？ (But, Why Does It Matter?)

There are two developers, Abe and Lenora (John and Sally were out that day), working with some data from an API that requires formatting dates to display on a graph. They are both using the ubiquitous JS library for handling dates, MomentJS, but in wildly different ways:

有两个开发人员Abe和Lenora(John和Sally当时不在)，他们使用API​​中的一些数据，这些数据需要格式化日期才能显示在图形上。 他们俩都使用无处不在的JS库MomentJS来处理日期，但方式却大相径庭：

Lenora abstracts her logic to a clever helper class with a function to format the Unix based time format to local time based on the user timezone which is stored in the front end app in local storage. Not bad Lenora, not bad at all.

Lenora将她的逻辑抽象到一个聪明的帮助器类中，该类具有根据用户时区将基于Unix的时间格式格式化为本地时间的功能，该时区存储在本地存储的前端应用程序中。 不错，莱诺拉，一点也不差。

Abe has a similar need but he opts to format the dates directly in the file that constructs the chart and does not take user timezone into account. Dates, amirite?

安倍也有类似的需求，但他选择直接在构成图表的文件中设置日期格式，而不考虑用户时区。 日期，无磷吗？

Without a thorough code review, both these pieces of code make it to the master branch and they work… for a while. Just after Halloween, when Daylight Savings ends, customers begin noticing that some of the charts on their page are suddenly not working. Not all, but some.

如果不进行全面的代码审查，这两个代码段都将其发送到master分支，并且它们会工作一段时间。 万圣节之后，夏令时结束时，客户开始注意到页面上的某些图表突然不起作用。 不是全部，而是一些。

After some furious debugging and comparison, Lenora discovers that Abe neglected to account for user timezone. “Why didn’t you just use my helper function?” she asks.

经过一番激烈的调试和比较，Lenora发现安倍忽略了用户时区问题。 “为什么不只使用我的助手功能？” 她问。

使用图案更快地工作 (Work Faster with Patterns)

The problem with this rogue style of coding is that it’s slowly strangles the code base. Each developer might be writing quality code but with duplication and different flavors of handling the same problems, like formatting time, fetching asynchronous data or in the case of Abe and Lenora, how to format chart data, the code base not only becomes bloated but hard for a new developer, Steve, to reason about. He sees two equally good (or bad) ways of handling the same logic and thinks, hmm, I’ve got an even more clever way to do this task, which he then adds to the gumbo pot.

这种流氓风格的编码的问题在于，它缓慢地扼杀了代码库。 每个开发人员可能都在编写高质量的代码，但是具有重复性，并且具有不同的风格来处理相同的问题，例如格式化时间，获取异步数据，或者在Abe和Lenora的情况下，如何格式化图表数据，代码库不仅变得肿而且困难。让新开发者史蒂夫(Steve)来思考一下。 他看到处理相同逻辑的两种同样好(或坏)的方法，并认为，嗯，我有一种更聪明的方法来完成此任务，然后他将其添加到了浓汤锅中。

Ha! A library eh? I think I’ll just roll my own here

哈！ 图书馆是吗？ 我想我会自己滚到这里

Refactoring all these pieces of logic into a cohesive unit is now not only a daunting task but inevitably each piece of logic is slightly different. Which is the true King?

现在，将所有这些逻辑部分重构为一个内聚的单元不仅是一项艰巨的任务，而且不可避免地，每个逻辑部分都略有不同。 哪个是真正的国王？

Taking the time to decide, as a group or at least delegate to a single person, the responsibility for developing reusable pieces of logic for common tasks or wrappers around widely used libraries gives everyone THE way to do a certain thing. It speeds up development and makes the code highly testable since there is a single source of logic that many components may leverage.

花时间来决定，作为一个小组或至少委派给一个人，负责为常见任务或广泛使用的库周围的包装开发可重用逻辑的责任为每个人提供了做某事的方式。 由于存在许多组件可以利用的单一逻辑源，因此它可以加快开发速度并使代码具有很高的可测试性。

组件库 (A Component Library)

If you’re on a team making widespread use of charts or other presentational components like our friends up there, it might be worthwhile to create a component library if you are using a framework like React for example.

如果您所在的团队广泛使用图表或其他展示性组件(例如我们的朋友)，那么例如在使用像React这样的框架时，可能值得创建一个组件库。

Using a library like MaterialUI or AntD for your components offers a lot of ways to do the same thing. One developer decides to create a button with slightly different padding than another. More flavors of buttons abound as the velocity and feverish pace to deliver tickets increases. Now there are no less than 20 different variations of a button in the code base. Why?

为组件使用MaterialUI或AntD之类的库可提供多种方法来执行相同的操作。 一个开发人员决定创建一个按钮，其填充与另一个开发者略有不同。 随着发送票证的速度和发烧步伐的加快，按钮的种类越来越丰富。 现在，代码库中有不少于20种不同的按钮变体。 为什么？

In the rush to push out a product, the team is now faced with a large cleanup ticket to change ALL the buttons to a uniform style after the Product Manager notices the small inconsistencies. Oops.

在急于推出产品时，在产品经理注意到细微的不一致之处之后，团队现在面临着一张大的清理票，将所有按钮更改为统一样式。 哎呀。

Creating a library of shared components to use requires some ongoing effort but the payoff is the speed at which developers can easily power through trivial front end tasks like building forms or adding buttons by simply importing them into their code.

创建要使用的共享组件库需要付出一些不懈的努力，但要付出的代价是，开发人员可以轻松地完成一些琐碎的前端任务，例如构建表单或通过将其导入到代码中来添加按钮，就可以轻松实现这一目标。

使用短绒 (Using Linters)

Perhaps the lowest hanging fruit to ensure some level of cohesiveness is using a linter in the code to catch and alert developers to errors like unused variables, odd indentation, or whatever else you want to configure. Prettier and ESlint are incredibly popular among JS developers and easy to configure in editors like VSCode.

保证最低程度的凝聚力的最低目标可能是在代码中使用linter来捕获并警告开发人员注意未使用的变量，奇数缩进或您要配置的任何其他错误。 Prettier和ESlint在JS开发人员中非常受欢迎，并且易于在VSCode这样的编辑器中进行配置。

Creating git pre-commit hooks to keep developers honest and make sure no sloppy code gets past git is a cheap way to create the kind of codebase that is at least leaning towards uniformity, but can’t be a substitute for things like good code reviews and pattern development.

创建git pre-commit钩子以保持开发人员的诚实并确保没有马虎的代码通过git是一种廉价的方法来创建至少趋于统一的代码库，但不能替代诸如良好的代码审查之类的东西和模式发展。

您的代码看起来像是由团队编写的吗？ (Does Your Code Look Like It’s Written by a Team?)

“If you do not take time to maintain your software, it will make time for you.”

“如果您不花时间维护软件，它将为您腾出时间。”

A wise person, or maybe a bumper sticker, said “If you do not take time to maintain your software, it will make time for you.” In the rush to create, it’s easy to take shortcuts, cowboy code and create a hodgepodge of code that works but doesn’t quite work together. Remember, team work makes the dream work.

明智的人，或者也许是保险杠贴纸，说：“如果您不花时间维护软件，它将为您腾出时间。” 在急于创建的过程中，很容易采用快捷方式，牛仔代码并创建可以一起工作但不能完全一起工作的大杂烩。 记住，团队合作使梦想成真。

翻译自: https://medium.com/@brianjenney/writing-code-as-a-team-9e8fca90a5a7