如果您的公司以相同的样式生产几种产品，那么有一天您将想到创建具有通用代码的库的想法。 例如，使用UI组件，授权服务或使用第三方API。 您可能想知道：谁应该支持此代码？ 如何将变更传达给用户？ 毕竟，您如何让他们使用图书馆？
自2015年以来，我一直在企业服务部门的Tinkoff工作。 在这段时间里，我们的团队从3名开发人员增长到60多名，而Tinkoff Business生态系统从3种增加到50种Web应用程序。 在开发的不同阶段，我们以不同的方式来处理通用代码，我想在本文中对此进行讨论。
基金会：便宜开朗
因此，快进到2015年。 我们只有三个Web应用程序：现金管理服务，工资单项目和控制面板。 和许多开发人员一样。
应用程序界面以相同的样式制作，并且常规代码移至单独存储库中的Foundation库。 该库不会编译-严格来说，那里没有任何编译，ES5上的所有代码均未在npm中发布，而是通过package.json中的分支名称进行连接。 为产品版本创建了单独的Foundation版本分支，以修复状态。 如果我们忘记提交Foundation分支，则使用该修补程序，结果是Foundation已更改，而该修补程序版本根本就不会更改。
这是package.json中的Foundation连接的样子：
"dependencies": { ... "sme-foundation": "git+https://stash_url/sme-foundation.git#develop" ... },
库的主要原则是通用代码所有权。
如果产品功能需要对Foundation进行修订，则功能开发人员自己进行。 而且，如果它们与以前的版本不兼容，那么他还规定在所有项目中都应使用此代码。 大规模重构也是如此：如果您想重构组件并更改其API，请-但同时要遍历所有用途。
如果要在一个项目中重用，在另一个项目中已经存在-也不是问题，只需将其带到库中即可。
幸运的是，没有太多代码。 这种方法对于三个，四个，五个项目非常有效……并具有许多优点：
- 通用代码放在一个地方，可以在项目中重用。
- 项目开发速度更快。
- 图书馆正在成长。
- 每个人都对通用代码和项目都有所了解，这使得审查和采用体系结构决策更加有效。
- 完善通用代码的需求并未阻碍功能的发展。
至此，我们只有很少的文档：一些JSDoc和单元测试。 对于UI组件，没有足够的可视窗口显示，我们看到了一种便宜且快速的解决方案-演示UI。 实际上，这是一个有角度的应用程序，在这些页面上插入了组件本身和相应的标记。
在2019年，您不太可能这样做。 但是这可以从这个故事中学到：
- 共享通用代码非常适合小型团队。
- 即使只有三个人，也不要懒于重复编写代码，这适用于任何规模的团队。
- 即使是带有组件列表的常规页面也可以极大地简化您的生活。
随着时间的流逝，Tinkoff业务生态系统和开发团队不断壮大。 当有十多个项目时，这种方法停止了工作。
更改通用组件变得太昂贵了。 一个项目的开发人员不再熟悉所有其他项目，寻找组件使用和进行更改变得更加复杂。 实施影响基金会的新功能的时间越来越长。
新开发人员对所完成的工作及其使用方式没有完整的了解。
更改组件的API令人恐惧，因此，科学怪人组件出现时带有大量输入参数。
有时这会导致
UX中的不一致 。 在不同组件中，诸如使用键盘，使用焦点等细节在实现方式上有所不同。 在某些地方，它们根本没有实现，因为开发人员专注于业务功能。
公司中出现了其他Angular项目，我们建议它们也使用我们的库。 最初，他们甚至都同意...但是，一旦需要改进，我们就陷入了困境：我们所有的开发人员都在忙于他们的项目，而我们的同事没有动力去处理别人的图书馆。
每个人都对基金会负责，特别是没有人负责，这不适合同事。
UI套件和工作组织的新方法
在2017年进行重新设计和新版UI套件时，我们开始以不同的方式开发新组件。 首先，我们有一支敬业的团队。
团队
我们从产品团队中选择了三个人，他们说：“现在，这些人正在为其他项目制作UI组件。”
敬业的团队奉献了什么？
- 首先，在短时间内，我们为产品团队准备了基本组件。 开发开始两周后，同事收到了最必要的东西。 然后，我们开发了库，重点关注客户的优先事项。
- 专门的团队专注于组件和UX。 我们的任务是从接口的最终用户的角度（正确的缩进，对比，使用键盘的角度-对鲸鱼团队而言这不是一件小事）和产品团队的开发人员的观点（一致的API，便捷的连接，可扩展性）制造出定性的组件。 。
- 一个敬业的团队是责任。 如果在组件中找到了组件，则产品开发人员将不会孤单。 严重的bug会以高优先级修复，并准备了一个修补程序，而次要的bug会按优先级顺序修复。 此处值得注意的是，在突出显示的团队出现之前，对于产品团队而言并不重要的缺陷（例如，输入和选择中占位符的颜色略有不同）可能会长时间积压，从而让位于业务功能。 但是对于鲸鱼团队来说，组件的外观是第一要务。
如果组件方面的专业知识集中在一个团队中，那么如何教别人使用这些组件？ 为此，我们做了出色的文档。
该文件
重新设计演示台的想法由来已久，新图书馆的开发使之成为可能。
然后Angular的Storybook尚未发布，所以我们走了自己的路。 做到最好：我们自己的实现并没有限制我们的想象力，我们可以做任何我们想做的事情。
这是我们所做的：
- 添加了有关整个库的信息：有关库连接方式的分步说明以及受支持的浏览器列表。
- 我们准备了每个组件的详细说明：为什么需要它，如何连接，它支持哪些输入输出参数（具有戳戳功能，如Storybook），典型用法示例，相似组件列表。
- 添加了使用此组件的项目列表。
- 他们开始收集有关不同项目中鲸鱼使用情况的统计信息：每个项目中连接了哪些项目，使用了哪个版本，使用了多少组件，每个项目中的鲸鱼和鲸鱼的版本-该信息用于计划不兼容的更改并拒绝支持框架的旧版本。 收集这些统计信息的工具的描述值得单独介绍。
- 添加了版本控制：查看每个先前发布的UI Kit版本的文档。
当然，所有这些并没有立即出现，而是演变了。
在我们部门内，一个专门的团队和文档就足够了。 同事们习惯于使用通用代码，他们熟悉UI Kit的开发人员，并且通常非常忠诚。
但是UI Kit设计本身被定位为公司所有产品的共同点，这意味着数十个团队需要相同的组件-从内部HR项目到WebOffice，WebOffice是一个可容纳数万名远程员工的工作系统。 因此，鲸鱼团队面临着更广泛的任务：创建所有Angular团队都将使用的高质量内部产品。
总的来说，其他部门的同事对此表示肯定，但仍然有一些疑问：他们所需的功能是否可以足够快地开发，质量是否会很高……某人已经开始亲自制作零件。
为了解决这些疑问，我们尽可能透明地组织了工作。
透明性
如果您仅从本文中得出一个想法，那么就可以将其作为以下想法：要使图书馆成功，仅靠制造好的组件是不够的。 您应该尽可能透明且以客户为导向。 在这种情况下，客户是最终产品开发人员。
您必须通过所有可能的方式，将您在做什么，为什么以及如何使用它传达给您的同事。
我们使用了哪些工具？
定期发布和演示。 第一个演示在开发开始两周后进行，然后每周举行一次，即下一个发行日。 有时有许多新功能，有时只有错误修复。 无论如何，我们都进行了演示。
展望未来，我要说的是主要工作已经完成，API稳定了，团队已经切换到发行版本的变更-一个具有功能的版本，一个具有编辑和改进的版本-并且该演示仅在具有新功能的版本上进行。
变更日志 。 我们介绍了常规提交，并从中生成了变更日志，从而大大简化了团队向新版本的过渡。
“响应式”团队 。 像所有团队一样，我们在Slack中拥有自己的渠道，这并不是什么新鲜事物。 实际上，我们甚至有两种渠道：一种用于团队内部的交流，一种用于用户的-回答问题，公告，调查，进行演示和其他活动。
真正解决传入的问题很重要。 在这种情况下，有些问题很复杂，有些则指出了文档中的空白（或者让我们知道并非所有人都读过它）。 有时Angular的新手会写他们的困难。 准备就绪的鲸鱼团队为所有人提供了帮助，如果在聊天中问题仍未解决，就不会懒得打电话，甚至不会自己下载别人的代码。 这样的通信自然会浪费开发人员的时间，但这是图书馆工作的一部分。
现在，鲸鱼频道中有200多个用户，许多问题在没有鲸鱼开发人员参与的情况下得以解决：同事分享他们的经验并互相回答问题。
发行后带有更改列表的新闻通讯。 他们的目标受众是开发人员，经理和产品设计师。 在时事通讯中，对更改进行了简单，轻松的描述-在Changelog中并不总是可能的-并包含“是/成为”图片。 我仍然确定这是一个很好的工具，但是很难每周准备高质量和清晰的摘要。 一段时间后，我们停止发送这些消息，但也许我们会返回到这种做法。
用户调查提供了一个外部视图并揭示了弱点。 例如，根据下一次调查的结果，我们了解到，大多数同事完全同意UI Kit的开发人员已准备好提供帮助，这意味着我们正在朝着这个方向努力。 但是，有了“正在迅速开发新组件”的声明，较少的受访者表示同意。 这样的结果怎么办？ 一方面，引起所有团队成员的注意，并在弱点上开展工作。 另一方面，与用户合作。 如果速度很重要，请更多注意这些术语的来源。
调查包括诸如“我们可以改善什么？”之类的开放性问题。 我必须说，我们的同事给了我们一些宝贵的提示：例如，为代码示例创建“复制”按钮，或者为我们的班级讲授日期以便与unixtime一起使用。
团队角色
上面，我已经写过关于“响应团队”的信息，这对于整个公司图书馆的成功至关重要。 我想再次强调这个想法，并讨论两种相关的做法。
值班 在某些时候，与同事之间的交流变得如此之多，以至于不可避免地引入了职责。 这就是Tinkoff中有多少服务团队工作。 每天一次，两天一次，一周一次，其中一名团队成员值班。 他监视频道，回答问题并进行大部分沟通，而他的队友却不会因为支持而分心。
我们还没有达到这一点，随着时间的流逝，这种需求已经消失了。 但是，其他值班团队也得到了帮助。
稽核 没有人比开发它们的团队更了解鲸鱼的组成部分。 经过两年的发展，他们在Angular也积累了出色的专业知识。 现在，我们介绍“鲸鱼队的审核”的做法。 他们联系到产品项目的审查，以及查看最终产品及其代码。 他们的目标是识别滥用，完善文档并列出好的和坏的做法。 我们将讨论下次会发生什么。
挑战与妥协
像具有大量利益相关者的任何过程一样，公共图书馆的发展迫使我们寻求妥协。
我们很难在代码质量和API稳定性之间找到平衡。 一方面，设计在工作开始时就发生了变化：出现了新组件或旧组件的新状态； 相反，有些东西已经过时并被锯掉了。 另一方面，开发人员对正确的组件API的看法正在改变。 所有这些不可避免地导致了重大变化。 但是图书馆用户的数量在增加，我们的重大变化给他们带来了极大的不便。
我们找到了一个折衷方案：进行重大更改的频率不超过每五个发行版一次，即每五周一次。 例如，此类更改可能会调用版本0.50、0.55、0.60。 但是，从0.50过渡到0.51不需要任何努力。 这一直持续到稳定版本1.0.0发行为止。 现在，API稳定了，所有的大范围更改都将无限期地推迟到2.0.0。
几次，切换到新版本需要大量常规工作：重命名前缀，更改图标导入等。 对于这种情况，我们已经实现了迁移脚本。
结论
本文介绍了我们四年使用共享代码库的经验。 我们得出了什么结论？
- 即使是很小的团队也不应忍受代码重复。 将代码删除到库中是每个人都可以使用的解决方案。
- 共同拥有共同代码对于小型团队非常有效，该库的用户最多为10个项目。
- 随着所涉及的项目或开发人员的数量不断增加，选择一个专注于通用代码的团队会更加方便。
- 专门团队工作的重要部分是与用户的交流：演示，培训，帮助，文档。
- 不要害怕思考更多，并在工具上投入时间。 在我们的情况下，这是一个方便的展示柜，其中包含文档和使用组件的分析器。