当你的公司成立时，那些行之有效的方法将不再适用，因为现在你正在快速扩张和招聘。人们将如何沟通？技术债务将如何解决？一个工程师做出的选择会影响到更多的人，所以现在是时候为你增加的劳动力制定战略了。

　　GitHub工程副总裁Rachel Potvin在她领导的团队规模扩大至三倍（达到500人）后解决了许多扩展难题。以下就是其经验之谈。

　　解决技术债务，保持士气

　　如果工程师因技术债务而一再遇到同样的阻力，他们的士气就会低落。因此，发布新功能很重要，但公司的投资组合健康也很重要，这时候就需要处理技术债务。

　　为分散式工作创建流程

　　分散式（fan-out）工作是当你决定完成某件事时——这也许是大规模的基于代码的演变，以清理一些技术债务；这并非仅仅一个团队就能完成的事，而是许多不同的团队都必须齐心协力才行。

　　过去是这样：某个部门的工程师有一个好主意，他们会在GitHub内部写一篇讨论帖子或团队帖子，说‘嘿，我意识到我们使用的这个API/技术不好。我们应该重构并删除它，看看这是我的合并请求（PR），我从我的项目中删除了它。现在大家尽管这么做。”你也许知道，只有少数工程师时，让有影响力的人完成这样的事情可能奏效，但我们的规模很庞大。现在我们是一家跨国公司，员工遍布全球各地——GitHub的工程副总裁Rachel Potvin说。

　　在过去，一位有影响力的开发人员可能希望修改代码以解决技术债务，为此将PR重构作为项目的一个方面，并要求其他人采取如出一辙的做法。但在像GitHub这么庞大的公司，不是每个人都相互认识，很可能最终变成了只做了一半的重构。而我们都清楚，唯一比需要重构的代码更糟糕的是重构了一半的代码！但这并不意味着不应该开始处理技术债务和重构，而是说需要有条不紊地进行。您需要统一决定：

　　拟议的分散式项目的范围是什么？要花多少钱？有什么好处？

　　以这种方式比较所有潜在的分散式项目，并精选出每个季度开展的少数几个项目，目的是完成几个有影响力的项目。每个选出来的分散式项目都予以适当的跟踪（由技术项目经理和项目经理负责跟踪），确保该项目切实带来显著的成效。GitHub最近开展的一个此类分散式流程是清理单体应用程序（monolith）中的功能标志（feature flag）。

　　众所周知，功能标志是一种出色的部署工具，但如果太多的功能标志停留时间过长，就会影响代码可读性。15年来，GitHub积累了始终打开的功能标志、从未打开的功能标志，以及为一些特定企业客户而不是为其他客户部署的功能标志。没有客户会喜欢使用GitHub未充分意识到的定制的功能标志！

　　GitHub处理这个分散式流程的方法是，为每个项目统一配备一群干劲十足的人，这群人心里想“是的，我们确实很想做这件事。我们想完成这件事。这对每个人都有好处。”该团队调查了每个功能标志图，以确定谁拥有它、是否可以安全地删除。GitHub以这种方式在产品方面取得了重大进展。

　　使用设计指导简化设计审核

　　随着工程部门不断扩大、日趋成熟，需要明确的路径和设计指导是另一个有待解决的问题。构建新服务的团队如何知道要使用哪些构建模块或语言？或者如何设计代码的架构，好让代码能与另一个团队对单体应用程序所做的工作很好地兼容？

　　GitHub不仅层次分明的设计审核体系，还日益致力于明确的路径，这样工程师就可以专注于所做的新颖工作，并拥有可依赖的基础设施，不必操心太多。

　　说到设计审核，您应该权衡工作量与变更的重要性——并非所有事情都需要记录完备的设计，但应仔细审核和沟通对工程技术会有重大持久影响的变更。

　　GitHub还有一个首席委员会（Principal Council），由公司最资深的技术个人贡献者（IC）和副总裁组成，负责审核最重要的设计决策。首席委员会制定整体架构路线图，为诸团队简化设计指导。委员会可能会说，如果项目满足条件X，这里应该用Go构建，但如果满足条件Y，应该在单体应用程序中构建。当然，选择一种编程语言只是表层，所以首席委员会现正在制定更广泛的未来架构计划。

　　利用委员会会议做出一致的技术决策

　　GitHub希望团队对于所做的新颖工作积极主动地做出决策。但也需要有一种方法让任何工程技术人员可以将他们认为无法在自己团队内解决的重大问题（比如更重大的基础架构问题、投资问题或工程技术问题）交给高层，让高层进行全面深入的讨论，并给予反馈。

　　这就是委员会会议上发生的事情。任何工程技术人员都可以提交GitHub问题单，从事平台各部分工作的人展开讨论，他们能够就一些方面做出决定，比如“我想开始使用这种数据库技术。我不确定这在GitHub企业服务器（我们的本地服务器部署环境）或我们未来基于云的SaaS产品上会如何运行。这是我能做的事情吗？受到什么制约？”

　　当然，GitHub建立在GitHub平台上，并使用GitHub平台。所以GitHub使用GitHub Discussions甚至代码存储库进行交流。有时，他们会编写Google Docs，因为Google Docs非常适合迭代式注释和工作。但是如果某个代码库被锁定，他们将其引入到存储库。

　　分配DRI以实现高效决策

　　大型组织中出现的另一个问题是，有时决策花费的时间太长。不仅应该有正常逐级上报的流程，每个团队还需要一个DRI（直接负责人）。DRI能够做出决定，进行迭代，并确保团队有合理的节奏，在不妨碍自身的情况下推进工作。

　　制作DevSat调查表

　　DevSat调查表是一项开发人员生产力和幸福感调查。GitHub DevSat调查侧重于内部GitHub开发人员体验。他们需要回答一系列问题，比如：

　　什么导致开发人员的工作困难？用户对我们的工具和系统的满意度如何？要完成的哪些工作面临最大的困难？团队心理安全；；团队决策；随叫随到的体验；完成的计划外工作有多少？完成的计划内工作有多少？

　　GitHub利用这些回复向经理和领导层提供匿名报告，这有助于为他们的投资决策提供依据，从而真正提升决策能力。这方面的一个例子是GitHub在DevSat中询问在GitHub内部使用Codespaces所遇到的任何困难。他们从内部开发人员那里获得了Codespaces团队可以利用的大量信息，因为人们往往在参与匿名调查时提供更多的信息，因此GitHub可以根据看似更重要的内容发现真正的趋势。这最终还有助于使他们的外部产品变得更好！

　　结语

　　扩展规模并非易事。如果您是一家有多个团队的大公司，就需要在如何开展工作方面确立流程。没有人可以了解所有正在做的工作的细节，因此您需要有效的开发实践和沟通策略。我们在本文中讨论了在公司规模大得多的情况下，如何做出设计决策、处理技术债务以及与开发人员保持联系。

　　原文链接：https://hackernoon.com/how-to-overcome-scaling-challenges-in-technical-architecture