向工程团队提出的问题

回顾我作为软件工程师的第一年，我意识到有很多问题我希望自己在职业生涯之初就提出来。我把这份冗长的清单精简为十个问题，我相信任何在职或新加入工程团队的人都会觉得这些问题有用。

1. 谁负责管理申请？

在本文中，我使用“应用程序”来描述一个独立的功能单元。作为一名新工程师，我最初的主要代码贡献都集中在现有的代码库中。直到我积累了更多经验，并开始从头构建整个解决方案时，我才意识到确定谁负责应用程序的重要性。这个问题触及了责任的根本：谁负责监控应用程序？谁负责处理可能发生的任何事件？谁负责维护应用程序？谁负责响应凌晨 2 点系统宕机的警报？

2. 团队的部署流程是怎样的？

了解如何部署代码与编写代码同样重要。部署代码是将代码从一个环境移动到另一个环境的过程。通常，程序员在开发环境中编写和测试代码，最终代码会被部署到生产环境中，供真实用户实际使用！首先，了解如何部署代码非常重要，这样您才能真正进行修改，最终让这些修改惠及真实用户。其次，提出这个问题很重要，因为它可以阐明实际的部署过程，该过程可能包括运行单个命令，也可能是执行漫长而艰巨的手动过程。

3. 服务或应用程序的平均生产路径是什么样的？

这个问题与上一个问题有点相关，因为它们属于同一领域，但主要区别在于，它捕获了在将代码部署到生产环境之前可能需要经历的步骤。例如，是否有一个委员会需要在部署到生产环境之前批准代码更改？这个问题鼓励团队考虑在将代码部署到生产环境时要采取的步骤，以及这些步骤是否对新员工清晰。作为一名初级工程师，问这个问题帮助我了解是否存在标准流程，或者流程是否会因应用程序而异。这个问题将让团队真正定义流程。对于任何开发人员来说，弄清楚这一点也至关重要，因为所有开发人员都希望他们的代码能够到达用户手中。有一天，您可能会负责管理服务或应用程序的发布，这有时不是一项简单的任务。

4.团队是否实践持续集成？

持续集成 (CI) 是一种实践，开发人员会持续将代码合并到一个中央代码库中，并在该代码库中创建自动构建并运行自动测试。CI 非常重要，因为它有助于尽早缓解错误和合并冲突。其理念是，当来自独立分支的代码频繁地集成到主分支时，它破坏主分支中现有代码的可能性就会降低。这个问题的答案很简单，只需回答“是”或“否”。

5. 团队多久发布一次生产版本？

这是一个很好的问题，在加入工程团队之前，你都可以问问自己！这个问题能给你提供两个重要的信息：
你什么时候能看到你的代码投入实际使用？编写代码最令人满足的一点就是知道它最终会被使用，并且亲眼见证它的实际运行！
你的代码需要多快完成交付？发布频率越低，每次发布就越重要，确保你的代码到时能够正常运行也就越重要。

6. 工程师与业务利益相关者或客户的合作有多密切？

在加入工程团队之前，这是一个很好的问题，因为它能让你了解作为一名工程师，你将如何开展工作，并明确与谁合作。你与利益相关者和客户的合作越紧密，你的人际交往能力就会越强，这将有助于你更好地完成工作并发展你的职业发展。

7. 工作如何进入团队？

这个问题有助于明确任务是如何分配给工程师的。任务是以工单的形式分配的吗？如果是，谁负责分配这些工单？这个过程可以协商吗？它会因季度而异吗？你对工作分配方式了解得越多，就越能更好地管理时间，确保工作得到公平分配。

8. 工程师在决定建造什么时参与程度如何？

这个问题非常适合在面试或新工程工作第一天提出，这样你就能了解自己在构建的工程解决方案中拥有多少发言权。有些人满足于满足他人的要求。有些人则喜欢采取更积极主动的方式。了解公司的标准将有助于你判断他们的期望是否符合你的偏好。

9. 如何启动一项新服务？

这个问题将真正鼓励工程团队将他们的实践提炼成一个连贯且易于遵循的过程，这对入职工程师和整个团队都有好处！

10.架构决策是如何做出的？

是否有一个正式的流程？它是开放式的吗？这将帮助你了解新团队设计新解决方案的标准和流程。

概括

总而言之，我希望在开始我的第一份软件工程工作之前就知道并提出以下十个问题。我相信每个团队都应该能够明确地回答这些问题，甚至可以为新入职的工程师提供答案！

1. 谁负责管理申请？
2. 团队的部署流程是怎样的？
3. 服务或应用程序的生产路径是什么样的？
4. 团队是否实践持续集成？
5. 团队多久发布一次生产版本？
6. 工程师与业务利益相关者或客户的合作有多密切？
7. 工作如何进入团队？
8. 工程师在决定建造什么时参与程度如何？
9. 如何启动一项新服务？
10. 建筑决策是如何做出的？

您还想问您的团队哪些其他问题？🙂

封面图片由 Jennifer Tran 提供