翻译|布加迪评论家|孙淑娟公司正在迅速扩大规模，招兵买马。公司成立时行之有效的方法有可能不再有效。员工如何沟通？如何解决技术债？一名工程师做出的选择会影响许多人，因此现在是制定策略以确保更多员工协同工作的时候了。GitHub工程副总裁RachelPotvin在她的团队规模扩大到500人后解决了许多扩展挑战！以下是他的经历。1、应对技术债，保持士气高涨如果工程师因为技术债一次又一次遇到同样的阻力，他们的士气就会低落。因此，发布新功能很重要，但公司产品组合的健康状况也很重要，这也是需要处理技术债务的时候2.为去中心化工作创建流程去中心化（扇出）工作是当你决定完成某事时——这可能是一次大规模的基于代码的演进，以清理一些技术债务；这不是只有一个团队可以做的事情，而是需要许多不同的团队共同努力。它曾经是这样的：某个部门的工程师有一个好主意，他们会在GitHub中写一个讨论线程或一个团队帖子并说'嘿，我意识到我们正在使用的这个API/技术很糟糕。我们应该重构并删除它，看到这是我的合并请求(PR)，我将它从我的项目中删除了。现在每个人都这样做。“正如你可能知道的那样，当只有少数工程师时，让有影响力的人做这样的事情是可行的，但我们很大。现在我们是一家全球性公司，员工遍布全球-工程副总裁RachelPotvin在GitHub说。在过去，一个有影响力的开发人员可能想要更改代码以解决技术债务，通过将PR重构作为项目的一个方面来实现，并要求其他人也这样做。但是在像GitHub公司这样大的站点中,不是每个人都认识彼此，很可能以半完成的重构而告终。我们都知道，唯一比需要重构的代码更糟糕的是半重构的代码！但这并不意味着不开始处理有技术债务和重构，但要说它需要有条理地完成。你需要一致决定：拟议的去中心化项目的范围是什么？它的成本是多少？有什么好处？比较所有这种方式潜在的去中心化项目，并选择一个小的每个季度要执行的项目数量，目的是完成一些高影响力的项目。每个选定的去中心化项目都得到适当的跟踪（由技术项目经理和项目经理负责跟踪），以确保项目确实交付了显着的成果。GitHub最近开始的一个这样的去中心化过程是清理单体中的功能标志。我们都知道功能标志是一种出色的部署工具，但是如果过多的功能标志挂起时间过长，则会影响代码的可读性。15年来，GitHub积累了始终开启的功能标志、从未开启的功能标志以及为某些特定企业客户而非其他企业客户部署的功能标志。没有客户愿意使用GitHub不完全了解的自定义功能标志！GitHub处理这个去中心化过程的方式是，每个项目都由一群积极进取的人统一起来，他们认为，“是的，我们真的很想做这个。我们想完成这个。这对每个人都很重要。个人受益。”该团队调查了每个功能标志图，以确定谁拥有它以及是否可以安全地删除它。GitHub在产品方面以这种方式取得了重大进展。3.使用设计指南简化设计审查随着工程部门的成长和成熟，需要清晰的路径和设计指导是另一个悬而未决的问题。构建新服务的团队如何知道要使用哪些构建块或语言？或者如何构建代码以使其与另一个团队正在做的事情很好地兼容单体应用程序？除了分层设计审查系统外，GitHub越来越致力于一条清晰的路径，以便工程师可以专注于他们所做的新工作，并拥有一个他们可以依赖的基础架构，而不必担心太多。当它到来时对于设计评审，您应该权衡工作量与变更的重要性——并不是所有的事情都需要有详细记录的设计，但是应该注意具有重大且持久的工程影响的变更充分审查和沟通。GitHub还有一个PrincipalCouncil，由公司最资深的技术个人贡献者(IC)和副总裁组成，负责审查最重要的设计决策。牵头委员会制定总体架构路线图，简化团队的设计指南。委员会可能会说，如果项目满足条件X，则应在此处使用Go构建，但如果满足条件Y，则应在单体应用程序中构建。当然，选择编程语言只是触及表面，因此牵头委员会现在正在制定更广阔的未来架构计划。4.利用委员会会议做出一致的技术决策GitHub希望团队对他们所做的新工作做出积极的决策。但还需要有一种方法，让任何工程人员都能将他们认为自己无法在自己的团队中解决的大问题（例如更大的基础设施问题、投资问题或工程问题）移交给高级管理层进行彻底和深入的审查。讨论并提供反馈。这就是委员会会议上发生的事情。任何工程人员都可以提交GitHubissueticket，在平台各个部分工作的人进行讨论，他们可以就诸如“我想开始使用这种数据库技术。我不确定是否这适用于GitHubEnterpriseServer（它将如何在我们的本地服务器部署环境中运行）或我们未来基于云的SaaS产品。这是我能做的吗？有什么限制？”当然，GitHub是建立在并使用GitHub平台的。所以GitHub使用GitHubDiscussions甚至代码仓库来进行交流。有时，他们编写GoogleDocs，因为GoogleDocs非常适合迭代评论和工作。但是，如果某个代码库被锁定，他们会将其拉入存储库。5.为高效决策分配DRI大型组织中出现的另一个问题是有时决策时间过长。不仅要有正常的升级流程，每个团队还需要一个DRI（直接负责人）。DRI能够做出决策、迭代，并确保团队有一个合理的节奏来前进，而不会妨碍自己。6.进行DevSat调查DevSat调查是一项开发人员生产力和幸福感调查。GitHubDevSat调查侧重于内部GitHub开发人员体验。他们需要回答一系列问题，例如：是什么让开发人员的工作变得困难？用户对我们的工具和系统的满意度如何？完成哪些任务难度最大？团队心理安全团队决策on-call经验做了多少计划外工作？完成了多少计划工作？GitHub使用这些回复向经理和领导层提供匿名报告，这有助于为他们的投资决策提供信息，真正改善决策制定。这方面的一个例子是GitHub在DevSat中询问在GitHub中使用代码空间的任何困难。他们从内部开发人员那里获得了大量信息，Codespaces团队可以利用这些信息，因为人们在参与匿名调查时往往会提供更多信息，因此GitHub可以根据看似更重要的内容发现真正的趋势。这也最终有助于使他们的外部产品变得更好！7.结语缩放并不容易。如果您是一家拥有多个团队的大公司，则需要建立一个工作流程。没有人能够知道正在完成的所有工作的细节，因此您需要有效的开发实践和沟通策略。在本文中，我们讨论了如何做出设计决策、处理技术债务以及与更大公司的开发人员保持联系。原文链接：https://hackernoon.com/how-to-overcome-scaling-challenges-in-technical-architecture
