黑客秘籍:渗透测试实用指南_企业架构和开发人员经验的秘诀：走的路

黑客秘籍:渗透测试实用指南

When I was in college, my university built a “green” (a fancy field for people to hang out in the middle of campus). Instead of building paths immediately through the green, the university waited until “natural” dirt paths were built — and then paved those paths.

当我上大学时，我的大学建立了一个“绿色”(供人们在校园中间闲逛的理想场所)。 这所大学没有立即建立穿过绿色的道路，而是等到建立了“自然”的土路，然后才铺好这些路。

Why did they do this? I imagine, they did this because they didn’t know the exact paths that people would take or how the field would be used — and left it to the users of the field to figure it out.

他们为什么这么做？ 我想，他们之所以这样做，是因为他们不知道人们会走的确切路径或该字段的使用方式，而是将其留给该字段​​的用户来解决。

In the enterprise architecture role, it is easy to become overly “zoomed out,” or focused completely on the abstract. When this happens, it tends to slow innovation down or stop innovation completely. Why? Because our mindset shifts from solving problems to fitting solutions into individual problems.

在企业体系结构角色中，很容易过度“缩小”或完全专注于抽象。 发生这种情况时，它往往会减慢创新速度或完全停止创新。 为什么？ 因为我们的思维方式从解决问题转变为解决个别问题的方法 。

So what can we do to “pave the way” for developers without getting lost in abstraction?

那么，我们该怎么做才能为开发人员“铺平道路”而又不会迷失在抽象中？

为个人解决问题 (Solve Problems For Individuals)

Imagine a team wants to expose a service as an API or set of APIs without any pre-defined guidelines. What are the common concerns when the time comes to implement this? (Please note we are assuming the API has already been strategized, designed, and mocked — and skipping straight to implementation.)

想象一下，一个团队想要在没有任何预定义准则的情况下将服务公开为一个API或一组API。 是时候实施这一点了吗？ (请注意，我们假设已经对API进行了策略化，设计和模拟-并直接跳至实现。)

1. Security
   安全
2. Adherence to global standards (logging, security again)
   遵守全球标准(再次记录，安全)
3. Resiliency (Retries, failover, graceful degradation, timeouts, circuit breaking)
   弹性(重试，故障转移，正常降级，超时，电路中断)
4. Observability (Logging, metrics, tracing)
   可观察性(记录，指标，跟踪)
5. Exposing the API for consumption and being a good “API Citizen” (versioning your API, giving deprecation notices, etc.)
   公开使用该API并成为良好的“ API公民”(对您的API进行版本转换，提供弃用通知等)

Typically, the application team will have a strong opinion on how to solve these problems — and that is a good thing! As an enterprise architect, letting the app team drive can be equated to a university letting students “create a path” where one wasn’t before.

通常，应用程序团队会对如何解决这些问题有强烈的意见-这是一件好事！ 作为企业架构师，让应用程序团队带动精神可以等同于让学生“创造一条前所未有的道路”的大学。

Of course, when a similar problem or requirement from another team comes up, that same architect will be able to draw on the previous experience and implementation details, speeding up the implementation process for the next team.

当然，当另一个团队提出类似的问题或要求时，该架构师将能够借鉴先前的经验和实施细节，从而加快下一个团队的实施过程。

Once a few teams have come up with similar solutions, a path has been blazed. At that point, it may be good to officially endorse the path/pattern, and start taking steps to smooth the pain points that developer teams have experienced. Smoothing pain points can take many forms including:

一旦有几个团队提出了类似的解决方案， 那就开辟了道路 。 到那时，最好正式认可该路径/模式，并开始采取步骤缓解开发人员团队遇到的痛点。 缓解痛点的方法有很多，包括：

• Implementation guides
  实施指南
• Automation
  自动化
• Tutorials
  讲解
• Video Series
  视频系列

When solving for pain points and implementing an enterprise process, it is important to note that every situation is different, but making the process simpler and easier for beginners to understand and start using effectively is almost never a bad choice.

解决痛点并实施企业流程时，必须注意每种情况都是不同的，但是让初学者更轻松，更轻松地理解和开始有效使用流程几乎从来都不是一个坏选择。

这有什么作用？ (What does this accomplish?)

• Makes it much easier for new developers to get onboarded and start contributing.
  使新开发人员更容易加入并开始贡献。
• Allows natural standardization of workflows (and hopefully graceful evolution if those workflows are modular!)
  允许对工作流程进行自然标准化(如果这些工作流程是模块化的，则可以进行顺畅的演进！)
• Creates a how-to guide for new hires.
  为新员工创建操作指南。
• Improves developer experience by giving a baseline that can then be innovated on top of, effectively “standing on the shoulders of giants”
  通过提供可以在“有效地站在巨人的肩膀上”之上进行创新的基准来改善开发人员的体验

The idea is not to set standards for the sake of standards — instead the standards can be set based on real life examples that have already been optimized and battle tested. This allows developers to use their brain power and effort for higher level outcomes.

这个想法不是为了标准而设置标准，而是可以根据已经过优化和战斗测试的真实示例来设置标准。 这使开发人员可以利用他们的脑力和精力来获得更高水平的结果。

If we really think about it — teams are made up of individuals. Individuals are the ones building true value — and the ability for individuals to focus on interesting problems instead of mundane ones that have already been solved directly correlates to both the velocity of value an individual can add to a project as well as that individual’s enjoyment of his or her work.

如果我们真的考虑一下，那么团队就是由个人组成的。 个人是建立真正价值的人-个人专注于有趣的问题而不是已经解决的平凡问题的能力直接关系到个人可以为项目增加的价值速度以及个人对项目的享受或她的工作。

翻译自: https://medium.com/dev-genius/secrets-to-enterprise-architecture-developer-experience-the-path-well-traveled-600e82dde636

黑客秘籍:渗透测试实用指南