正则表达式替换文字表达式_如果不能用文字表达，就不能用代码表达-CSDN博客

正则表达式替换文字表达式

I often write design documents even if no one will read them.

我经常写设计文档，即使没有人会阅读。

There are a lot of resources out there on how to write good design documents. There are also many different ways to define what constitutes a design doc — what it includes, how long it is, how formal it is, etc.

关于如何编写好的设计文档，有很多资源。还有许多不同的方法来定义组成设计文档的内容-它包括什么，内容有多长时间，形式如何等等。

For my purposes, a design doc is any document that you write before you begin the actual implementation. It can be long or short, formal or informal, etc. The point is it’s something you do independently of the implementation—and before.

出于我的目的，设计文档是您在开始实际实施之前编写的任何文档。它可以是长或短，正式或非正式等。重点是您可以独立于实现以及之前进行操作。

Most of the known benefits of writing design docs center around organizational alignment. Design docs can help you plan, help you get input from others on your team or in your company, serve as a record for the future. At larger companies, they’re also a great educational channel. While experienced engineers debate pros/cons of different approaches, many other can watch from the stands.

编写设计文档的大多数已知好处都围绕组织一致性。设计文档可以帮助您进行计划，帮助您从团队或公司中的其他人那里获取意见，并作为未来的记录。在大型公司中，它们也是很好的教育渠道。在经验丰富的工程师辩论不同方法的利弊时，其他许多人也可以从展台上观看。

I’m a big fan of design documents on large teams and at large companies, but I still find them tremendously valuable even if no one else reads them.

我是大型团队和大型公司的设计文档的忠实拥护者，但是即使没有人读过它们，我仍然发现它们非常有价值。

A good design doc includes, at some level of detail:

一个好的设计文档在某些细节上包括：

What you’re planning to do.
您打算做什么。
Why you’re doing it.
为什么要这么做。
How you’re going to do it (including discussions of alternative implementations).
您将如何去做(包括其他实现的讨论)。

Being forced to write those things down (even if it’s in a few sentences or paragraphs plus a diagram or two) sets a minimum bar that can help solve a lot of software development problems.

被迫写下这些东西(即使是用几句话或几段，再加上一两个图)设置了一个最小的门槛，可以帮助解决许多软件开发问题。

Thinking strategically instead of tactically. Tactical thinking focuses on the details and on immediate results. Strategic thinking focuses on higher-level concepts (what we’d call “architecture”) as well as on the future. Code lends itself to tactical thinking. Design docs force strategic thinking.
战略思考而不是战术思考。 战术思维侧重于细节和即时结果。战略思考着重于更高层次的概念(我们称之为“架构”)以及未来。代码有助于进行战术思考。设计文档强制进行战略思考。
Creative thinking. Complementary to strategic thinking, when writing out a plan, you’ll often realize that there are alternative solutions to the problem you’re trying to solve (or in some cases, that the problem you’re trying to solve isn’t worth solving). It’s hard to do this when you’re bogged down in implementation details.
创造性思维。 与战略思维相辅相成，在制定计划时，您通常会意识到，有一些替代解决方案可以解决您要解决的问题(或者在某些情况下，您要解决的问题不值得解决) )。当您陷入实施细节时，很难做到这一点。
Avoiding complexity and obscurity. Being forced to articulate your plan in pain English can often expose complexity. Often, things that are complex tend to be hard to describe, and so, if you think your implementation is simple but are finding that writing out your high-level plan is hard, it’s a good indicator you’re wrong about how simple it is.
避免复杂和晦涩。 被迫用英语表达您的计划常常会暴露出复杂性。通常，复杂的事情往往很难描述，因此，如果您认为实现很简单，但是发现写出高级计划很困难，则这是一个很好的指示，说明您认为它很简单是错误的。

It is, of course, entirely possible to sometimes begin with the implementation first, but in this case, you should treat the implementation as a discovery implementation or a prototype to collect some “on the ground details”. But once you have those details, then you write your design doc before beginning the real implementation.

当然，有时完全有可能首先从实现开始，但是在这种情况下，您应该将实现视为发现实现或原型，以收集一些“实际细节”。但是一旦有了这些细节，就可以在开始真正的实现之前编写设计文档。