40、应对技术评审：从模拟场景到实战技巧

应对技术评审：从模拟场景到实战技巧

1. 模拟场景中的开发与测试

在功能从一个环境部署到另一个环境时，所有的 Apex 单元测试和自动化测试脚本都会自动被调用。这样做能确保执行所有回归测试，并且新开发的功能满足所有验收标准。虽然仍会有手动测试，但我们应尽量自动化最关键的用例。

在问答环节，评委很可能会提出与该领域相关的问题，比如卓越中心（CoE）的结构、提议的开发方法、持续集成（CI）环境背后的原理、源代码管理（SCM）中分支的使用、如何保持所有开发环境的更新，以及如何确保测试能持续被调用等。

在展示过程中，有一个全面检查需求的阶段。在此阶段，需要逐一检查需求，确保涵盖了各个方面。如果是现场评审，会收到场景的打印版本，还会有笔和标记笔，可在阅读和解决场景时突出或下划线标注需求，若有解决方案可写在需求旁边。如果是线上评审，可获取场景的数字版本，使用 MS PowerPoint 和 Excel，将需求复制到幻灯片或表格中，在展示时使用。

展示结束后就是问答环节，评委可能会提出问题，以填补展示中遗漏或未清晰解释的内容。

2. 问答环节的应对策略

在问答环节，要放松并为自己目前取得的成果感到自豪。评委可能会改变一些需求，以测试现场解决问题的能力，这也是考试的一部分。

当评委挑战提出的解决方案时，不要轻易怀疑自己。即使评委的语气暗示方案可能有误，也要相信自己和解决方案，但不要过度辩护。如果发现自己犯了错误，要虚心接受并纠正解决方案，评委会对此表示赞赏。

例如，评委可能会问：“你提议引入一个集成接口从设备中拉取智能电表读数，这意味着在可能的情况下我们无法获得电表的实时读数。你为什么提出这个解决方案，是否有其他方法可以提供实时数据？”回答时要简洁明了，可参考以下示例：
- 问题表明只有两个系统可以通过发布/订阅（pub/sub）将电表读数推送到服务器，并且要求每月读取一次电表。电力部门（PDU）热衷于开发一种统一的机制从所有供应商处检索智能电表数据。
- 因此，我考虑在 MuleSoft 中开发一个每月定时任务，从所有平台拉取电表读数，然后更新 Salesforce 中的读数。
- 或者，我们可以研究是否在不支持发布/订阅的两个系统之上引入一个发布/订阅层。这可以通过将 MuleSoft 连接到它们的数据库并定期检查更改来实现，前提是这些系统能提供一种机制来检索更改数据的差异，类似于变更数据捕获（CDC）概念。
- 如果这些系统不支持此功能，我们可以考虑以两种不同的方式与这些系统集成。第一种是统一的拉取接口，第二种是使用 MuleSoft 订阅两个系统提供的发布/订阅通道。这样，我们可以实时从四个系统中的两个系统获取更新，但这与公司的原始要求相悖。
- 我倾向于拉取机制，因为它能确保我们不会不必要地更新 Salesforce 记录，从而遵守治理限制并避免任何性能挑战。

回答时间最好不超过三分钟，要确保给评委留出尽可能多的提问时间。

再如，评委可能会问：“你提到 MuleSoft 将使用 OAuth 2.0 网络服务器流，然后使用刷新令牌流来对 Salesforce 进行身份验证。是否有其他可以使用的身份验证流，以及何时使用每种流？”回答如下：
- 可以使用 OAuth 2.0 JWT 流，它支持机器对机器的身份验证，两个流程都能满足此需求。但 JWT 流在使用上下文用户而不是命名主体/集成用户/服务用户进行身份验证时更有用。通过结合上下文用户身份验证和 JWT，我们可以启用更高级的审计功能并支持不同的访问权限。
- 网络服务器流（后跟刷新令牌流）不太适合基于上下文用户的深度机器对机器身份验证，因为它涉及每个用户的手动身份验证步骤。但对于单个命名主体的身份验证来说不是问题，并且考虑到不需要在两端交换和托管多个 TLS 证书，网络服务器流对于命名主体可能更容易设置。因此，我为公司选择了这个解决方案。

同时，要准备好绘制所有这些身份验证流的序列图，因为很可能会被要求解释其中一个或多个流，序列图是描述它们的最佳工具。

还有可能被问到：“在你的环境和发布策略中，能否进一步解释谁将在环境之间移动元数据以及如何移动？能否也解释一下如何检测和解决冲突，以及由谁来做？”回答如下：
- 开发人员会为每个开发的功能在新的功能分支上工作。完成后，他们可以发起一个拉取请求，将此分支与 CI/构建分支合并。
- 拉取请求会通知发布经理（有时也称为 DevOps 管理员）。发布经理会验证拉取请求并检测任何冲突，SCM 提供了相应的机制和工具。发布经理会尝试解决一些小冲突（如页面布局的更改），对于更复杂的冲突则会退回拉取请求，开发人员必须修复问题并发起另一个拉取请求。
- 一旦拉取请求被接受，自动化构建工具会尝试将 SCM 中的代码库部署到构建环境。发布经理会根据预定义的标准（如被 QA 团队接受）适时将这些功能部署到更高的环境。

在回答问题时，不要过于详细，要留意时间。

以下是一个简单的流程图，展示了开发与发布过程：

graph LR
    A[开发人员在功能分支开发] --> B[发起拉取请求]
    B --> C[发布经理验证]
    C -->|有小冲突| D[发布经理解决]
    C -->|有复杂冲突| E[退回给开发人员]
    E --> F[开发人员修复并重新发起请求]
    D --> G[自动化构建工具部署到构建环境]
    G --> H[发布经理部署到更高环境]

3. 评审场景的结构剖析

评审场景通常有特定的结构，一般包含以下部分：
| 部分名称 | 内容描述 |
| ---- | ---- |
| 项目概述 | 提供关于公司的一般信息，如公司提供的服务、痛点、地理覆盖范围、增长计划等，有助于理解整体情况，还能帮助初步了解潜在参与者和角色层次结构细节，可能包含一些重要数据，如员工数量，这些数据可能会显著影响目标数据量。 |
| 当前系统景观 | 解释现有客户的系统景观，有助于起草景观架构，包含系统的任务、规格信息，如对 API 的支持和更改的灵活性，可帮助确定适用/不适用的集成模式，还可能包括支持的业务功能、公司保留或替换现有系统的策略以及一般痛点和风险。 |
| 业务用例/业务流程需求 | 是场景中内容最多、可能最长的部分，包含大部分业务需求，描述业务使用的一般流程，业务流程通常以一系列要点描述，每个要点可能包含一个或多个需求，由功能、数据和集成需求组成。处理此部分的最佳方法是为每个流程创建业务流程图。 |
| 数据迁移需求 | 可能是一个独立部分或包含在其他部分中，通常描述源系统中的预期数据量，这些数据有助于制定数据迁移策略和计划，可能会影响大数据量（LDV）的定义和 LDV 缓解策略。 |
| 可访问性需求 | 通常包含身份和访问管理（IAM）需求、移动可访问性规范以及内部和外部预期用户体验，可能会补充业务流程部分的需求，特别是在系统和数据可访问性方面，在某些考试场景中可能与安全需求部分合并。 |
| 安全需求 | 是最关键的部分之一，也是第二复杂的部分（仅次于业务用例部分），通常包含应用程序和网络安全需求，可能会挑战对多个平台安全功能的知识，如共享规则、配置文件、权限集、平台加密、多因素认证（MFA）和共享集。 |
| 报告需求 | 包括关键所需报告的描述，可能会指出这些报告所需的数据（如来自多个系统的记录），还可能包含报告的可用性和受影响的参与者的详细信息。 |
| 项目开发需求 | 描述当前的发布过程，可能列出一些痛点，有助于定义正确的开发和发布策略以及适当的治理模型。 |
| 其他需求 | 可能存在也可能不存在，在某些情况下可能与项目开发需求部分合并，包含前面部分未涵盖的其他需求，包括可能影响提议的治理模型的信息和风险。 |

需要注意的是，这些部分的命名可能因场景而异，上述结构只是一个通用结构，实际考试场景可能包含更多或更少的部分，或者有完全不同的结构，要做好应对各种结构的准备。

应对技术评审：从模拟场景到实战技巧

4. 应对评审的实用技巧

为了更好地应对评审，有许多实用技巧可以提前掌握并运用。

4.1 心理准备

评审会给候选人带来很大的心理压力，但要明白通过考试后的回报是巨大的，它能让人进入一个精英群体，并为职业生涯带来显著提升。因此，在参加评审前，必须做好心理准备，保持放松、精神饱满且专注的状态。这就需要在前一晚保证充足的睡眠，在考试当天找到能让自己充满能量的方式。有些人在面对挑战时会充满动力，而有些人则是渴望证明自己。无论哪种方式，动机都应该是积极的，因为恐惧失败并不是一个好的动力来源，积极的动机能让人更有信心地完成考试。

4.2 场景分析技巧

在面对评审场景时，要根据不同的部分采用不同的分析方法。
- 项目概述 ：仔细阅读这部分内容，提取关键信息，如公司的业务范围、痛点等。可以将这些信息记录下来，以便后续分析潜在参与者和角色层次结构。例如，如果提到公司有多个分支机构，那么在考虑系统架构时就要考虑到分布式的需求。
- 当前系统景观 ：重点关注系统的规格信息，如 API 支持和灵活性。可以制作一个表格，对比不同系统的特点，从而确定适用的集成模式。
| 系统名称 | API 支持 | 灵活性 | 适用集成模式 |
| ---- | ---- | ---- | ---- |
| 系统 A | 支持 | 高 | 实时数据同步 |
| 系统 B | 部分支持 | 中 | 定时数据传输 |
| 系统 C | 不支持 | 低 | 手动数据导入 |
- 业务用例/业务流程需求 ：按照前面提到的方法，为每个业务流程创建流程图。在创建过程中，要详细梳理每个步骤的功能、数据和集成需求，确保不遗漏任何重要信息。

graph LR
    A[业务流程开始] --> B[步骤 1: 数据收集]
    B --> C[步骤 2: 数据处理]
    C --> D[步骤 3: 结果输出]
    D --> E[业务流程结束]

• 数据迁移需求 ：根据源系统的预期数据量，制定合理的数据迁移策略。可以考虑分阶段迁移、数据清洗等方法，以确保数据的准确性和完整性。
• 可访问性需求 ：关注用户体验和身份验证方面的要求。如果需要支持社交登录，要考虑如何与第三方平台集成，以及如何保证用户数据的安全。
• 安全需求 ：深入研究平台的安全功能，如共享规则、加密等。可以制定一个安全策略文档，明确每个安全需求的实现方法和责任人。
• 报告需求 ：明确关键报告的内容和数据来源，以及报告的可用性和受影响的参与者。可以创建一个报告需求清单，确保所有报告都能按时、准确地生成。
• 项目开发需求 ：根据当前的发布过程和痛点，制定合适的开发和发布策略。可以采用敏捷开发方法，提高开发效率和质量。
• 其他需求 ：仔细分析这部分内容，确保没有遗漏任何重要信息。如果有影响治理模型的风险，要提前制定应对措施。

4.3 时间管理

在评审过程中，时间管理非常重要。在展示环节，要合理安排每个部分的时间，确保重点内容得到充分展示。在问答环节，要控制回答时间，每个问题的回答最好不超过三分钟，以便给评委留出更多的提问时间。可以在考试前进行模拟练习，提高自己的时间把控能力。

5. 总结与展望

通过对评审场景的结构剖析和应对技巧的介绍，我们可以看到，应对评审需要全面的知识和良好的心理素质。在面对评审时，要保持冷静，按照合理的步骤进行分析和解答。同时，要不断学习和积累经验，提高自己的技术水平和解决问题的能力。

在未来的职业生涯中，这些应对评审的经验将非常宝贵。它不仅能帮助我们通过考试，还能让我们在实际工作中更好地应对各种挑战。希望大家能够充分利用这些技巧，顺利通过评审，开启新的职业篇章。

总之，应对技术评审是一个综合性的过程，需要我们从多个方面进行准备和提升。相信通过不断的努力和实践，我们都能成为优秀的技术人才。