不同的软件开发团队做事风格迥异，即使在企业内部，团队与团队之间也存在诸多差异。作为一名软件工程师，和新的伙伴一起工作、开发新的软件通常是件令人兴奋的事情，同时他们还应考虑很多问题。最近，软件工程师 Thomas Stringer 就从技术、协作、外部、产品多个角度进行了分析。
技术
1. 如何在本地构建软件？
这是你应该学习的第一件事。毕竟，对于开发和运行软件来说，构建是第一步！
2. 如何在本地测试软件？
CI pipeline 对于纠正测试错误非常有用，同时它还可以缩短内部开发循环周期，确保测试顺利进行，同时检查回归。该 pipeline 不应成为创建或导致测试失败的首个迹象。
3. 如何设置开发环境？
团队文档应对此有明确要求。此外你还应了解在开发机器上要使用哪些不同的工具，以便使自己成为团队的生产者。一次性设置好环境来处理 95% 的需求，要比在开始开发后遇到错误和 gradle 依赖好得多。
4. 源代码在哪里？
通常情况下，在新团队中你将在一个预先存在的代码库中工作。因此，你需要知道代码在哪里，如何在本地机器上获取代码。
5. CI/CD pipeline 在哪里，它是如何工作的？
希望你能加入一个确保交付产品质量的团队。最常见的工具之一是 CI/CD pipeline。找出它的位置，并简单了解其工作原理，查看最近的一些运行，了解已经进行的步骤。
6. 产品 backlog 在哪里？
你面临的是软件的当前状态，但最好先了解其未来状态。快速浏览 backlog，查看产品即将推出的一些优先事项。
7. 预生产和生产测试是如何进行的？
新团队有集成环境吗？团队用 canary build 和部署来进行测试吗？团队是否引入混沌工程？你需要了解新团队如何确保其生产软件保持在特定标准。
8. on-call 以什么形式进行？
这款软件需要 on-call 吗？如果是，怎么轮换？事故发生频率是多少？on-call 是否有非工作时间要求？当我执行 on-call 时，如何得到通知？通常在你加入新团队时不会立刻开始 on-call 轮换，因此随着时间的推移，你可以在执行 on-call 前得到一些答案。
9. 内部文档在哪里？
新团队在哪里维护内部文档？是最新版吗？
协作
10. 团队中的每个人在关注什么？
软件团队通常有多名工程师，了解团队中不同程序员的关注点是不错的做法。
11. 团队每周的节奏是怎样的？
有每日站立会议吗？需要每周签到（weekly check-in）吗？你需要了解新团队的 “典型” 一周是什么样子。
12. “初学者”问题该向谁提问？
加入新团队后，你通常会被分配一个“入职伙伴”——一个知道事情如何运作的团队老人。这是一件非常有价值的事情，尤其是在你对新软件几乎一无所知、提出的问题非常初级的情况下。这很正常，提出初学者问题并不丢人，即使你是高级工程师。
13. 谁来驱动新功能？
这款产品是否有产品经理？团队中有架构师与工程师协同工作吗？你需要了解特性请求的上游源头。如果能抽出时间和这个人（或这些人）了解产品的近期和远期前景就更好了。
14. 团队如何沟通？
新团队使用 Slack 或者 Teams 吗？还是大部分异步通信通过电子邮件实现？工程师们通常整天都在谈论问题或进行其他类型的讨论。作为团队中的新成员，你需要了解这些沟通渠道。
外部
15. 如何获得客户反馈？
这是 GitHub 上的开源软件吗？GitHubissue 是我们获得反馈的方式吗？还是有销售团队作为从客户到产品团队的代理人？我们可以从不同的支持团队处收集常见的客户痛点吗？换句话说，你需要了解新团队如何获得用户反馈，无论是通过另一个平台、个人还是团队。毕竟，我们是为用户编写软件的。
16. 我们对客户有哪些支持协议？
我们是否必须遵守 SLA？我们支持什么样的用户场景？
17. 公共 / 客户文档在哪里？
这是一个重要的问题。不管软件有多好，客户文档都应该是准确和最新的。你需要了解在哪里浏览这些文档，文档如何保持最新，以及谁对此负责（希望答案是“所有人”）。
产品焦点
18. 软件的高级痛点是什么？
你需要了解软件和团队是否正在处理一些大问题。是不是某些架构问题导致了其他问题？是否存在可利用的安全漏洞？是否有常见的客户问题不断出现，并需要解决？
19. 利益相关者的关注点是什么？
软件的某些特性是否是关键个人或其他团队希望看到的？通常，这些利益相关者会对软件的短期和长期路线图产生重大影响。了解他们的关注点有助于想象软件的未来路线。
20. 软件的发布周期是什么？
你还需要了解软件发布的频率和时间节奏。团队是否每天持续部署多次？还是一年两次发布？了解软件发布时间表可以让你对软件开发节奏有一个很好的了解。
扩展阅读：
Linux 内核爆出权限提升漏洞，Ubuntu、Debian、Fedora 均受影响
