人工智能 发展关键节点
介绍 (Introduction)
In the fast-paced world where we find ourselves, businesses are measured not just by the value they deliver to customers but also by the speed at which they provide it.
在我们所处的快节奏世界中，不仅根据业务为客户提供的价值来衡量业务，还可以根据业务提供给客户的速度来衡量业务。
For software-based companies, an integral part of that equation is the development velocity of both individual developers and developer teams.
对于基于软件的公司，此等式的组成部分是各个开发人员和开发人员团队的开发速度。
But what is development velocity?
但是什么是发展速度？
发展速度 (Development Velocity)
Firstly, let me offer you my definition.
首先，让我为您提供我的定义。
Development velocity is a measure of the ability to deliver customer value.
发展速度是衡量交付客户价值能力的量度。
Please, go back and re-read the previous sentence. These words were chosen with care. You will note that it does not say “feature”, and it does not say “code” anywhere.This is very intentional and extremely important.
请返回并重新阅读上一句话。 这些话是精心挑选的。 您会注意到，它没有说“功能”，也没有在任何地方说“代码”。这是非常有意且非常重要的。
Let’s dive deeper into this.
让我们更深入地了解这一点。
开发人员为什么不提及代码？ (Why doesn’t developer velocity mention code?)
As coders, it’s easy to think that the answer to all problems is code, typically more code.
作为编码人员，很容易想到所有问题的答案就是代码，通常是更多的代码。
This is simply not true.
这是不正确的。
In fact, adding code often makes the problem worse.
实际上，添加代码通常会使问题变得更糟。
Consider this, for every line of code that a project has, there is a cost.It has cost someone time to write it.It has cost someone time to test it.And it will continue to cost the team to maintain it.
考虑到这一点，项目拥有的每一行代码都会产生成本，花费了一些时间来编写它，花费了一些时间来测试它，这将继续使团队维护它。
Once we acknowledge that code has a cost, we can contrast the cost of this code with the value that it brings to either the customer or the team.
一旦我们意识到代码是有成本的，就可以将代码的成本与其为客户或团队带来的价值进行对比。
This cost/value trade-off actually forms the basis of many arguments in software engineering like:
这种成本/价值的折衷实际上构成了软件工程中许多争论的基础，例如：
YAGNI — You-ain’t-going-to-need-it
YAGNI - 你- ain't持续到需求，它
Minimalist API — i.e., exporting only the bare minimum
极简主义API-即仅导出最小的
Minimal config/options — flexible code is sexy but expensive, unnecessarily so, for options that are seldom or never used.
最小的配置/选项 -对于很少使用或从未使用过的选项，灵活的代码很漂亮，但价格昂贵，不必要。
Removing unused features and Deleting dead code — removing code that is no longer used has very low risk. Once removed, it is not costing us anymore.
删除未使用的功能并删除无效代码 -删除不再使用的代码的风险非常低。 一旦删除，它不再花费我们。
Buy vs. Build — It is always tempting to build the “perfect” version of a solution, but finding an existing solution that is “good enough” and is maintained by someone else is frequently cheaper.
购买与构建 -总是很想构建解决方案的“完美”版本，但是找到一个“足够好”并由其他人维护的现有解决方案通常更便宜。
All of these arguments are based on the same idea, we should be looking to write and maintain as few lines as code as possible.
所有这些参数都基于相同的思想，我们应该寻求编写和维护尽可能少的代码行。
开发人员为什么不提及功能？ (Why doesn’t developer velocity mention features?)
As developers and product owners, we are bombarded with opportunities to add more features, more config options, and more customization.
作为开发人员和产品所有者，我们面临着增加更多功能，更多配置选项和更多自定义功能的机会。
These features will often even make some people happy.
这些功能通常甚至会使某些人高兴。
However, the question we need to be asking ourselves, is it worth it?
但是，我们需要问自己一个问题，这值得吗？
It might seem harsh, but if you could add a feature that would make 1% of our users happier, is that worth it?The answer to this question should not be an automatic, yes.If the development cost is too high, then it might be a no.If the maintenance cost is too high, then it might be a no.If the feature causes the system to become slow or unstable, then it is almost certainly a no.
这看似很苛刻，但是如果您可以添加一项使我们1％的用户更快乐的功能，那是否值得？这个问题的答案应该不是自动的，如果开发成本太高，那么如果维护成本过高，则可能为否;如果此功能导致系统变慢或不稳定，则几乎可以肯定。
Hopefully, you can see where I am going with this.
希望你能看到我要去的地方。
When it comes to maintaining and extending our systems, we should be continuously asking ourselves two questions:
在维护和扩展我们的系统时，我们应该不断问自己两个问题：
- Is this feature or code worth the cost to develop and maintain? 此功能或代码值得开发和维护吗？
- Are there any old features or code that no longer provide enough value to keep around? 是否有任何旧功能或代码不再提供足够的价值以供保留？
By spending the time keeping our “work area” clean using these ideas above, we ensure that new work is not inhibited by what came before it.
通过使用上面的这些想法，花时间保持我们的“工作区”整洁，我们确保新工作不会受到之前工作的限制。
If the key to development velocity is not blindly adding more code or more features, then what is it?
如果开发速度的关键不是盲目添加更多代码或更多功能，那又是什么？
发展速度的关键 (Keys to Development Velocity)
There are 6 keys to development velocity, these are:
开发速度有6个关键，它们是：
- Code Clarity 代码清晰
- Trust (or lack of fear) 信任(或缺乏恐惧)
- Code Quality 代码质量
- Automation 自动化
- Support 支持
- Introspection 内省
Let’s explore these.
让我们探索这些。
代码清晰 (Code Clarity)
Code Clarity is, by far, the most crucial factor when it comes to velocity.
到目前为止，代码清晰度是最关键的因素。
By clarity, I mean the readability and, by extension, the usability of the code itself.
明确地说，我的意思是代码本身的可读性，以及扩展性。
When a programmer can read and easily understand both the intention and implementation of a piece of code, API, or module, then it is easier and faster to work with.
当程序员可以阅读并轻松理解一段代码，API或模块的意图和实现时，则使用起来更容易，更快捷。
Code clarity is not easy to achieve and does require continuous monitoring and effort.It is often achieved and maintained by frequent tweaks (aka refactoring).
代码清晰度不容易实现，并且需要持续的监控和努力，它经常通过频繁的调整(又称为重构)来实现和维护。
The freedom to achieve risk-free refactoring is itself achieved through a lack of fear, which is the next item.
实现无风险重构的自由本身是通过缺乏恐惧实现的，这是下一个项目。
Recommended reading for Code Clarity:
建议阅读有关代码清晰度的内容：
信任(缺乏恐惧) (Trust (lack of fear))
When we have trust in our system, we have confidence that every level, from a single function to modules, to the system as a whole does what we intend it to do.
当我们对我们的系统信任时，我们就会相信，从单个功能到模块，再到整个系统，每个级别都可以完成我们想要的工作。
By extension, this trust allows a developer to be confident that they can make changes and not break something else.
通过扩展，这种信任使开发人员确信他们可以进行更改而不破坏其他内容。
Such trust is hard-earned and based in a history of such successful changes.
这种信任是来之不易的，并且建立在这种成功变革的历史上。
Developers can develop a sense of trust with the following activities:
开发人员可以通过以下活动建立信任感：
Adding unit tests — these tests will serve to document the codes’ intention on a small scale. Ensuring that these tests are run often (as part of the build or more) allows the tests themselves to deliver the maximum value.
添加单元测试 -这些测试将用于小规模记录代码的意图。 确保这些测试经常运行(作为构建的一部分或更多)，可以使测试本身提供最大的价值。
Adding tests to prove bugs — these are special tests (unit or UAT) that are added as a result of a bug report. These tests fail because of the bug and will only pass when the bug has been fixed. Beyond their initial value of documenting and proving the bug fixed, these tests prevent the bug from reoccurring; and there is nothing worse for a programmer or user than having the same bug more than once.
添加测试以证明错误 -这些是由于错误报告而添加的特殊测试(单元或UAT)。 这些测试由于该错误而失败，并且仅在修复该错误后才能通过。 这些测试除了记录和证明已修正的错误的最初价值之外，还可以防止错误再次发生。 对于程序员或用户而言，没有比一次拥有相同错误的情况更糟的了。
Adding UAT tests — these tests ensure that the customer value (feature) that we promised to deliver is actually being delivered. When both unit and UAT tests are in place, most of the risks associated with developing and deploying new features are reduced to a point where deployment failure is almost always the result of a config problem.
添加UAT测试 -这些测试可确保实际上已交付了我们承诺提供的客户价值(功能)。 当进行单元测试和UAT测试时，与开发和部署新功能相关的大多数风险都降低到了这样的程度，即部署失败几乎总是由配置问题导致的。
Hopefully, testing is part of your standard development practice, but if this is not the case, I would strongly encourage you to adopt it.
希望测试是您标准开发实践的一部分，但是如果不是这种情况，我强烈建议您采用它。
We mentioned earlier that every line of code has a code associated, in both creation and maintenance, and while this is absolutely true for test code as well, test code brings immense value.
前面我们提到过，代码的每一行在创建和维护时都有相关的代码，尽管对于测试代码也是如此，但是测试代码带来了巨大的价值。
The lack of fear that adequate test coverage brings is extraordinarily liberating and empowering, especially when compared with attempting to maintain legacy, buggy, or lousy code.
缺乏足够的测试覆盖范围带来的恐惧可以极大地解放和授权，尤其是与尝试维护旧有，错误或糟糕的代码相比。
Recommended reading on testing:
建议阅读的测试：
Just say no to end-to-end tests (Google)
只是对端到端测试说不 (Google)
Practically anything written by Kent Beck (Twitter / Medium / Amazon) — You do not have to do TDD or agree with it; there is tremendous value in his work regardless
肯特·贝克( Twitter / Medium / Amazon )几乎写的任何东西—您不必做TDD或同意它； 无论他的工作有多么巨大的价值
代码质量 (Code Quality)
One of the most significant problems in our industry is the lack of a concrete or codified set of guidelines or metrics that define precisely what is good code and bad.
我们行业中最重要的问题之一是缺少一套明确定义好代码和坏代码的具体或编纂的准则或指标。
In many cases, beauty truly is in the eye of the beholder. Just like physical beauty, folks instinctually believe what they have created is the right or best outcome; after all, who doesn’t think their kids are beautiful?
在许多情况下，情人眼中确实有美丽。 就像身体上的美丽一样，人们本能地相信自己创造的东西是正确的或最佳的结果。 毕竟，谁不认为他们的孩子漂亮？
The problem with this ambiguity is that it necessitates that every programmer, team, and company must define what quality means to them.
这种含糊不清的问题在于，它要求每个程序员，团队和公司必须定义质量对他们意味着什么。
My ego is not big enough for me to tell you, “this is the right style” Instead, I will say this:
我的自我还不足以告诉您“这是正确的风格”，我会这样说：
- A team style should be defined 应该定义团队风格
- It should be enforced by code reviews 应该通过代码审查来实施
- Where possible it should be automated with formatters and linters 在可能的情况下，应使用格式化程序和短绒棉纸将其自动化
Yes, I know it sucks to have to write code in a style that is not your own. Sadly, there really is no way around it.
是的，我知道必须以非您自己的方式编写代码很烂。 可悲的是，确实没有办法解决它。
Code that is annoying and clumsy for you to write would be annoying and clumsy for your team to read if you did not follow the team style.
如果您不遵循团队风格，那么您编写的代码烦人且笨拙的代码对于您的团队而言将是烦人且笨拙的。
On the flip side, the annoying and clumsy feeling goes away after using a new style for a week or so.
另一方面，使用新样式一周左右后，烦人和笨拙的感觉消失了。
Many style choices and common mistakes can be either fixed or surfaced using linters.
许多样式选择和常见错误可以使用短绒棉布固定或浮出水面。
短绒和指标 (Linters and Metrics)
I know many people hate code linters, but I have a very different perspective.
我知道很多人讨厌代码短绒，但我有不同的看法。
I think linters are fantastic and here are my reasons why:
我认为短绒棉棒极了，这是我的原因：
- They can help individual programmers find issues in their code before sending the code for review; saving precious review time 它们可以帮助个别程序员在将代码发送给审阅之前发现其代码中的问题。 节省宝贵的审查时间
- They can teach you how to write better code and help you eliminate bad habits or develop new ones 他们可以教您如何编写更好的代码，并帮助您消除不良习惯或养成新习惯
Beyond these reasons, I am very happy to admit that one of the best advice I got over the years was to “turn on all the linters in Eclipse”.
除了这些原因之外，我非常高兴地承认，多年来我获得的最佳建议之一是“打开Eclipse中的所有短毛绒”。
It seemed silly at the time. Especially as many of the lint issues that were raised, I did not understand at all.
当时看起来很傻。 尤其是在提出了许多皮棉问题时，我一点也不明白。
But I persisted with it, and over the weeks and months, I found the time to research what particular lint issue was and why it was important.
但是我坚持不懈，在数周和数月的时间里，我找到了时间来研究什么是皮棉问题，以及为什么它很重要。
After this process, I came to understand why the code was better after fixing the issue.
经过这个过程，我开始理解为什么在解决问题后代码会更好。
And as a consequence, I was putting out much better code because of it.
结果，我因此发布了更好的代码。
Because of this, I have continued to find and adopt even more linters over the years, and as such, I often run many more lint checks that team or company requires; it is my personal preference and the standard I want to set and maintain for myself.
因此，这些年来，我一直在寻找并采用更多的皮棉，因此，我经常进行团队或公司所需的更多皮棉检查。 这是我的个人喜好，也是我要为自己设定和维护的标准。
Linters are not without issues, though. The most common, and likely why many people hate linters, is turning on too many lint checks too fast.
不过，棉短绒并非没有问题。 最常见的原因(可能也是为什么许多人讨厌皮棉的原因)是打开太多皮棉检查的速度太快。
When a check gets employed, it will generate noise. If it becomes required that this gets fixed immediately, then this is annoying, and people will hate it.
进行检查时，会产生噪音。 如果需要立即解决此问题，那么这很烦人，人们会讨厌它。
When folks are required to fix issues in the code that they do not recognize as an issue, then it becomes annoying, and they will hate it.
当人们被要求在代码中解决他们不认为是问题的问题时，这将变得很烦人，他们会讨厌它。
While I believe that folks should adopt as many linters as they reasonably can, it must be done gradually.
虽然我认为人们应该尽可能多地采用幼仔，但是必须逐步进行。
In fact, the easiest way to set and maintain a high bar in terms of lint is with new projects. When checks are turned on from the start, the cost is lessened, spread out, and seems far less arduous.
实际上，就皮棉而言，设置和维持较高标准的最简单方法是使用新项目。 从一开始就启用检查功能，可以降低成本，分散成本，并且看起来也很轻松。
One last word of warning to any team lead/manager that is thinking of adopting linters. You must find a balance between requiring that all lint issues are resolved and the cost of adoption.
最后警告对正在考虑采用短绒棉的任何团队负责人/经理。 您必须在要求解决所有皮棉问题和采用成本之间找到平衡。
If there is too much noise, then the warnings will cause alert fatigue, and they will be ignored.
如果噪音太大，则警告将引起警报疲劳，因此将忽略它们。
If folks fall into the habit of ignoring these warnings, then the linter will just be wasting everyone’s time.
如果人们习惯于无视这些警告，那么短毛猫只会浪费每个人的时间。
It might be best to either turn things on one by one or find a way to separate the fatal issues from the warnings and provide sufficient time for items to be addressed before being blockers to the build.
最好将问题一一打开，或者找到一种方法将致命问题与警告分开，并为被阻止的项目提供足够的时间来解决这些问题。
I have talked mostly about linters in this section, but any tool that provides an automated measure of quality should be considered.
在本节中，我主要讨论了短绒棉，但应考虑使用任何可以自动测量质量的工具。
Tools like Sonar and GolangCI-Lint can be invaluable. Just make sure you spend the time to configure them well, and you communicate your expectations/requirements clearly.
诸如Sonar和GolangCI-Lint之类的工具可能是无价的。 只需确保您花时间配置好它们，并清楚地传达您的期望/要求。
If you are just starting out with these tools, I would recommend enabling tests for:
如果您刚开始使用这些工具，建议您启用以下功能的测试：
- Unit test coverage 单元测试范围
- Dead code 死码
- Code coupling 代码耦合
- Common Errors (like Go’s vet or Java’s NPE checks) 常见错误(例如Go的审核或Java的NPE检查)
Sorry, but I must repeat myself if you do not care about a lint check do not enable it.
抱歉，如果您不关心皮棉支票，请勿启用它。
I cannot tell you how many times I have seen teams (read managers) turn on checks for things like documentation that, while valuable in theory, the team just did not care about.
我无法告诉您我有多少次看到团队(读经理)对诸如文档之类的东西进行检查，尽管从理论上来说很有价值，但团队根本不在乎。
As a result, the team just used auto-generated comments or added only enough comments to make the linter shut up.
结果，该团队只使用了自动生成的注释，或仅添加了足够的注释以使短绒棉布关闭。
The code didn’t get any better, and the programmer wasted time (and angst), making the linter happy.
代码没有得到任何改善，程序员浪费了时间(和焦虑)，使短毛猫高兴了。
Nothing was gained, and time and effort were lost.
一无所获，浪费时间和精力。
自动化 (Automation)
Automation is designed to address two fundamental issues:
自动化旨在解决两个基本问题：
- Humans make mistakes 人类犯错
- There are only 24 hours in a day 一天只有24小时
Yes, I am being glib, but these are important issues.
是的，我是glib，但是这些是重要的问题。
It is very easy to make mistakes; you could be tired, you might be rushing or just unlucky.
犯错很容易； 您可能会累，您可能会匆忙或不幸。
Automation in the form of build tools (like Maven or Gradle), scripts (bash), or full tools (like Jenkins or Bitbucket Pipelines) ensure that things are done the right way every time.
构建工具(例如Maven或Gradle)，脚本(bash)或完整工具(例如Jenkins或Bitbucket Pipelines)形式的自动化可确保每次都以正确的方式完成工作。
They also offer the ability to do things for us automatically and with confidence.
他们还具有自动为我们做事的能力。
An excellent Continuous Integration (CI) pipeline allows developers to throw code changes at the CI server with the confidence that it will perform all the checks (tests, lint, and metrics) without any extra cost.
出色的持续集成(CI)管道使开发人员可以放心地在CI服务器上进行代码更改，因为它可以执行所有检查(测试，皮棉和度量标准)而无需任何额外费用。
These checks should be automatically triggered and done asynchronously to the development process. Allowing the developer to get on with other things.
这些检查应自动触发并与开发过程异步完成。 允许开发人员继续其他工作。
Similarly, there are many other tasks we programmers frequently perform that can be automated, like code formatting, code generation, and even pull-request submission.
同样，程序员经常执行的许多其他任务可以自动执行，例如代码格式化，代码生成，甚至是请求请求提交。
Where possible, these tasks should be automated to ensure consistency and to reduce the effort required.
在可能的情况下，应自动执行这些任务，以确保一致性并减少所需的工作量。
This should either be done automatically in the CI pipeline or as part of the provided developer tooling. Either way, the impact on the developer and reviewer must be minimized.
这应该在CI管道中自动完成，也可以作为提供的开发人员工具的一部分来完成。 无论哪种方式，都必须最小化对开发人员和审阅者的影响。
支持 (Support)
Up until this point, I talked mostly about code and the individual developer, but development velocity extends beyond this.
到目前为止，我主要讨论代码和单个开发人员，但是开发速度不止于此。
There are three main things that the tech lead (or higher) must ensure that all developers are provided to ensure that development velocity is not hampered. These are:
技术负责人(或更高职位)必须确保具备三项主要条件，以确保提供所有开发人员，以确保不影响开发速度。 这些是：
- Tooling / Base Libraries 工具/基础库
- Prompt code reviews 提示代码评论
- Clear deliverables 清晰的交付物
Let’s dive deeper into these points.
让我们深入探讨这些要点。
工具/基础库 (Tooling / Base libraries)
Most of the work a particular development team will do will be for the same purpose, e.g., building web services or creating tools or maintaining shared libraries.
一个特定的开发团队将完成的大部分工作都是出于相同的目的，例如，构建Web服务或创建工具或维护共享库。
To achieve this work, developers will often use the same tools or libraries over and over.
为了完成这项工作，开发人员经常会反复使用相同的工具或库。
The team should decide on a set of tools or libraries that they want to use, and it is the tech lead’s responsibility to ensure they are available.
团队应决定要使用的一组工具或库，技术负责人有责任确保它们可用。
When developing web services, these will typically include:
开发Web服务时，通常包括：
Instrumentation — tools like StatsD (Datadog), NewRelic or Grafana. It does not matter which tool is used as long as it is standard across the development team
仪器 -像StatsD(Datadog)，或NewRelic的工具Grafana。 只要使用整个开发团队的标准工具，都没有关系
Logging — as with instrumentation, the key here is standardization. Logs, like instrumentation, must be centrally accessible (using tools like Scalyr or AWS CloudWatch).
记录 -与仪器一样，此处的关键是标准化。 日志(如检测工具)必须可集中访问(使用Scalyr或AWS CloudWatch之类的工具)。
Consistent usage of Logging and instrumentation — the team should develop and adopt standard practices when it comes to how they log and how services are instrumented. This typically takes the form of wrapper or convenience libraries that help ensure consistency. A typical example of this would be ensuring that user-related log messages include a RequestID.
一致地使用日志记录和工具 -团队在记录日志和服务的方式时应制定并采用标准做法。 这通常采用包装或便捷库的形式，以帮助确保一致性。 一个典型的例子是确保与用户相关的日志消息包含一个RequestID。
Config — teams should have a standard way of handling configuration. This could be environment variables, config files, or a configuration server. It does not matter which approach as long as it is known and consistent across the team.
配置 -团队应该具有处理配置的标准方法。 这可能是环境变量，配置文件或配置服务器。 只要是整个团队中已知且一致的方法，都没有关系。
Feature flags — beyond basic configuration, it is crucial for service owners to change the configuration of a running service. This includes being able to turn features on and off, changing limits, and even user-related configuration. Again it does not matter if this configuration is available via something simple like a collection of Redis keys or a configuration system like LaunchDarkly; the key is that a solution exists and is consistent.
功能标志 -除了基本配置之外，对于服务所有者来说，更改正在运行的服务的配置至关重要。 这包括能够打开和关闭功能，更改限制，甚至与用户相关的配置。 同样，通过一些简单的东西(例如Redis键的集合)或类似LaunchDarkly的配置系统可以使用此配置也没关系 ； 关键在于解决方案的存在和一致性。
Central Handling of Common Concerns — when providing web services (plural) to users, it quickly becomes apparent that all services, particularly public-facing services, have many shared requirements. These include instrumentation, user authentication, security, rate limiting, and even DDOS protection. A practical approach is to handle as many of these concerns as possible “at the edge” of our network. This allows service developers to trust that these concerns have been taken care of, which in turn reduces the scope and complexity of the service. Take user authentication, for example, if the service developer can just trust that the request includes the user’s identity and that the user is logged in and valid. Then there is no need to call an authentication service. They can just perform their tasks without validation or dependency on user authentication or validation services.
共同关注点的集中处理 -在向用户提供Web服务(复数)时，所有服务(尤其是面向公众的服务)都具有许多共同的需求，这很快变得显而易见。 其中包括检测，用户身份验证，安全性，速率限制，甚至DDOS保护。 一种实用的方法是在我们的网络边缘尽可能多地处理这些问题。 这使服务开发人员可以相信已经解决了这些问题，从而减少了服务的范围和复杂性。 以用户身份验证为例，如果服务开发人员可以仅信任请求包含用户的身份并且用户已登录且有效。 这样就无需调用身份验证服务。 他们可以执行他们的任务而无需验证或不依赖用户身份验证或验证服务。
This is by no means a definitive list. As a team, we should regularly take stock of similarities between projects and look to lessen their cost by standardization and/or centralization.
这决不是绝对的清单。 作为一个团队，我们应该定期评估项目之间的相似性，并希望通过标准化和/或集中化来降低其成本。
提示代码评论 (Prompt Code Reviews)
As a senior Individual Contributor (IC), this point is a pet hate of mine. There is nothing more frustrating than quickly producing code and then having it stuck in review for days.
作为高级个人贡献者(IC)，这一点是我的宠儿。 没有什么比快速生成代码然后将其停滞几天审查更令人沮丧的了。
Similarly, it is frustrating to have to pester my teammates for a review continually.
同样，令人沮丧的是必须不断困扰我的队友进行审查。
Not only does it limit my personal velocity, it frequently causes double work in the form of rebase/merge conflicts.
它不仅限制了我的个人速度，而且经常以重新设置/合并冲突的形式引起双重工作。
It is the tech lead’s job to ensure that code reviews are performed promptly and thoroughly.
确保及时彻底地执行代码审查是技术主管的工作。
I am not saying that it is the tech lead’s job to do the reviews, in fact, quite the opposite, they should not be doing anymore or less than other members of the team.
我并不是说进行审查是技术负责人的工作，实际上，恰恰相反，他们不应该比团队中的其他成员做得更多或更少。
Reviews are an excellent opportunity for the reviewer and reviewee to learn the system and improve as developers.
对于审阅者和被审阅者而言，审阅是一个学习系统并作为开发人员进行改进的绝好机会。
Rubber stamp reviews don’t help anyone, and if the code really has problems, then it is quite detrimental as it impacts quality.
橡皮图章评论对任何人都无济于事，如果代码确实有问题，那么它会影响质量，因此非常有害。
Personally, I try to work on small chunks of work, small enough to finish two or more a day. As such, I find it useful to submit my work and then check the review queue and do some reviews while waiting for my code to build and get reviewed.
就我个人而言，我尝试着做一些小的工作，这些工作足够小，一天可以完成两个或更多。 这样，我发现提交我的工作，然后检查审阅队列并在等待我的代码生成并获得审阅的同时进行一些审阅很有用。
This ensures that reviews for others in the team are not pending for long, and I can do something useful while waiting.
这样可以确保对团队中其他成员的审核不会等待很长时间，并且我可以在等待时做一些有用的事情。
Ideally, reviews should not be pending for more than about 4 work hours. Reviews should not need to be requested, but if folks need an emergency review or want a review from a specific person, they should be able to request it.
理想情况下，审核的待决时间不应超过4个工作小时。 不需要请求审阅，但是如果人们需要紧急审阅或需要特定人员的审阅，则他们应该能够提出请求。
清晰的交付物 (Clear Deliverables)
These are another task for the tech lead (or product owner). Simply put, a developer cannot build something unless they know what it is.
这是技术负责人(或产品负责人)的另一项任务。 简而言之，除非开发人员知道它是什么，否则他们无法构建它。
This does not mean developers need to be told how to do their job. Actually, the best approach is to outline the business or user value that they need to provide and let them determine the appropriate implementation.
这并不意味着需要告诉开发人员如何完成工作。 实际上，最好的方法是概述他们需要提供的业务或用户价值，并让他们确定适当的实现。
Taking the perspective of user value has two advantages.Firstly, this is usually the default perspective of the product owner and, therefore, the easiest to convey.Secondly, it allows the developer the greatest flexibility in how the goal is achieved.
从用户价值的角度来看有两个优点：首先，这通常是产品所有者的默认角度，因此最容易传达;其次，它使开发人员在实现目标方面具有最大的灵活性。
As developers, we can sometimes be a bit straightforward in our thinking. If you tell us to build X, we may build X without thinking much about it. However, when we fully understand what you are asking for, the solution we provide might surprise you.
作为开发人员，有时我们的思维可能会有些直截了当。 如果您告诉我们构建X，我们可能会在不考虑太多的情况下构建X。 但是，当我们完全了解您的要求后，我们提供的解决方案可能会让您感到惊讶。
Clear deliverables can take many forms, but generally speaking, we should be aiming for “just enough” documentation and formality.We don’t need a full development plan for every change, but significant changes should have an RFC or some kind of software design/architecture document.
清晰的交付物可以采用多种形式，但是通常来说，我们应该以“足够多”的文档和正式形式为目标。我们不需要为每项更改制定完整的开发计划，但重大更改应具有RFC或某种软件设计/体系结构文档。
Similarly, when adding small features or tweaking an existing one, it is often enough to write a user story or two using a form like this:
同样，在添加小功能或调整现有功能时，通常使用如下形式编写一两个用户故事就足够了：
As a merchant, when I send an order with $0.00 value, then my request should be rejected
作为商人，当我发送价值$ 0.00的订单时，我的请求应被拒绝
User stories like this are clear to both product owners and developers and can easily be turned into both UAT and manual tests.
这样的用户故事对于产品所有者和开发人员而言都是清楚的，并且可以轻松地转换为UAT和手动测试。
内省 (Introspection)
This last point is perhaps the one most often missed or forgotten when it comes to development teams.
最后一点可能是开发团队最常错过或遗忘的一点。
It is natural to get caught up in the day-to-day grind of fixing bugs and adding features.
很自然地会陷入修复错误和添加功能的日常工作中。
As such, we often forget to take the time to perform an honest review of ourselves and our progress.
因此，我们经常忘记花时间对自己和我们的进步进行诚实的审查。
Once in a while, perhaps quarterly, teams should set aside an afternoon for themselves.
有时，也许每季度一次，团队应该为自己留出一个下午。
In this session, the team should:
在此会议中，团队应：
- Review the current state of all code and services that are under their care 查看他们所关心的所有代码和服务的当前状态
- Review the processes and practices of the team 审查团队的流程和实践
The goal of this session is to celebrate the successes, acknowledge any on-going concerns, and make adjustments.
本届会议的目标是庆祝成功，承认任何持续存在的问题并进行调整。
Teams should be asking themselves questions like:
团队应该问自己一些问题，例如：
- Where did we succeed, and how can we do more of that? 我们在哪里取得成功，又如何做得更多？
- Where did we fail, and how can we fix it? 我们在哪里失败了，我们该如何解决？
- Do the current practices and processes help or hinder? How can we streamline them? 当前的做法和流程对您有帮助还是阻碍？ 我们如何精简它们？
- Are the tools we adopted helping or hindering? 我们采用的工具在帮助还是阻碍？
- Did the linters we have adopted to make things better or worse? 我们采用的短毛绒使事情变得更好或更糟了吗？
- Can we enable more linters or checkers and take our code to the next level? 我们可以启用更多的linter或checker并将我们的代码提升到一个新的水平吗？
- Do we have any significant tech debt that we need to spend more time on? 我们是否有需要花费更多时间的重大技术债务？
How, when, or where this is done is not nearly as important as ensuring that it is done.
如何，何时或何地完成此操作几乎不像确保完成操作那么重要。
We (developers) are responsible for the quality of the work we produce, and we can influence how this work gets done.
我们(开发人员)对我们生产的工作质量负责，我们可以影响这项工作的完成方式。
Mistakes can only be fixed after they have been identified.
错误只有在被识别后才能解决。
Inconveniences can only be addressed after they have been acknowledged.
不便之处只有在得到承认后才能解决。
Best practices can only become standard practice once everyone knows about them.
最佳实践只有在每个人都知道之后才能成为标准实践。
结论 (Conclusion)
As a programmer, I love to solve problems and deliver value with code.
作为程序员，我喜欢解决问题并通过代码交付价值。
I hope this article has given you an idea of the sorts of things I do to make myself more productive, what I believe teams should do to make themselves more productive and how supporting folks (tech leads and product owners) also have a part to play.
我希望本文能使您对我为提高自己的生产力所做的各种构想，我认为团队为提高自身生产力所应该做的事情以及支持人员(技术负责人和产品所有者)如何发挥作用的想法有关。
As you can see, many things can impact development velocity. I do not recommend that you adopt everything in this article blindly or all at once.
如您所见，很多因素都会影响开发速度。 我不建议您盲目或一次采用本文中的所有内容。
Instead, try incrementally adopting these ideas and use the introspection session to reject anything that does not work for you or your team.
相反，请尝试逐步采用这些想法，并使用自省会话拒绝对您或您的团队不起作用的所有内容。
翻译自: https://medium.com/ovo-tech/the-keys-to-development-velocity-4efa121de701
人工智能 发展关键节点
13万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
