在开发人员的日常生活中，存在三种不同类型的项目：
- 原型：目标是挑战现有的“想法”（产品，UX，开发人员…），但我们并不打算将其完全投入生产。
- “一次性应用程序”：这可能是您产品的真正特定/隐藏功能，或者说是一个“临时”项目，例如为发布新产品而创建的创意网站。
- 您将要长期使用的应用程序，例如公司的主要网站。
我将集中讨论最后一种情况，您确实需要考虑项目每个区域的长期可扩展性。 当然，它将会发展，并且您已经知道了。
1.可扩展性
了解产品和用户体验策略非常重要。 您是否需要尽快将您的网站转换为电子商务？ 如果是这样，那么了解您的公司的产品和用户体验策略就更为重要。 根据不同的发展，您可能已经需要在开发方面计划一些任务来预期它，并以不同的方式设计您的体系结构。
无论如何，一旦您了解了它，就需要真正了解产品的下一个里程碑，以相应地适应您的工作。
2.可维护性
如果以前端开发为例，则必须使用npm（或yarn）来管理依赖项。 甚至不要像以前那样考虑将库手动导入到您的项目中，否则您将被诅咒大约5代。
快速了解整个项目的依赖关系非常重要（通过package.json ）。 我也强烈建议您在依赖包上设置固定版本。 这样，您可以确保与所有同事共享相同的环境。
但是对于npm来说，这并不是完全正确的，因为内部依赖关系并不总是固定的……
在许多项目中，通常会在计算机上安装全局依赖项以使其运行。 可能是一些后台脚本，应用程序，Go，Node …我也强烈建议您修复这些版本。 首先，您需要尽可能减少全局安装的数量，例如，测试在CI中使用的库的版本。您还可以使用容器在本地工作（这样，您可以使用相同的全局到处都是依赖项）。
看起来确实很琐碎，但实际上有很多好处：
- 这样可以避免由于错误的软件包版本而导致数小时的调试。
- 您需要手动更新依赖项的版本，这具有迫使您也阅读更改日志的好处。
您知道，如果每个人都可以轻松地从头开始安装项目，那么您做得很好。
3.一致性
当您在同一代码库中与人一起工作时，标准确实非常重要。 所有人都需要以相同的方式设置代码格式，以使每个人都很清楚。 您可以通过两种方式在前端进行此操作：
- 您可以定义代码库规则，并将其用作短子（就像Airbnb一样）。 或者，您也可以扩展由Airbnb创建的规则并添加自己的规则。
- 您不想费心编写自己的Linter，也没有时间花在与团队争论特定规则上。 您可以使用更漂亮或标准。
只要您使用一种选择，任何选择都是好的。
4.效率
同样，创建一些脚手架将使您能够标准化您的代码库，并在执行重复的任务上花些时间。 我鼓励这样做也是一种好习惯，因为它可以帮助您快速启动功能，并且可以帮助您通过codemods轻松切换到另一个实现。
我和JérômeSmadja已经在BlaBlaCar上撰文介绍了前端设计系统的起源（ 如何构建设计系统 ？以及用于Web的设计系统 ）。 如您所见，我们已经制作了一些脚手架，以使用其文件夹，CSS文件，单元测试，可访问性警告等来创建组件。
另一个示例是我们的预提交钩子。 在BlaBlaCar，我们有一些脚本测试环境的节点版本，即package.json的格式，以确保所有依赖项均已固定（参考点2可维护性）。
一致的工作流程→自动化→没有人为错误
5.结构
我在这里不是在讨论代码体系结构，而主要是在团队交互方面。 如果在微服务中有什么要实现的东西，那么您不应该破解并将其放入API，因为“它更快”。
有时，由于“另一个团队拥有更多的带宽”，因此可以更快地实现原本不应实现的功能。 一定不行。 为了保持项目的一致性和可伸缩性，您需要将职责保持在所属位置。 否则，您肯定会早晚为此付费。
6.意识
在BlaBlaCar前端团队中，我特别喜欢一件事：没有人真正拥有某项功能甚至Jira门票。 每个人都可以从事所有工作，我认为这是一件好事。 没有任何一点或失败，它会导致代码库更加一致，代码审查更为相关。 但是，要像这样工作，您需要具有良好的代码库规范。 我不是在谈论隐藏在Wiki分支中的功能文档，而是关于：
- API如何工作？ （SDK，API文档…）
- 如何监控网站？ （诸如哨兵，新遗物等资源）
- 如何释放？ （发布脚本和过程…）
注释有时可以充当代码中的规范。 老实说，我们没有那么多：只有在我们觉得自己很难理解（上下文必要或函数定义）时，我们才会发表评论，通常是PR中的某人提出来的
但是，我认为单元测试非常重要。 在代码运行状况方面，以及在规范方面。 它很容易阅读，也很容易理解这段代码应该是什么。 如果您在TDD中工作，甚至可以从一开始就与产品负责人一起编写这些规范。 如果不是这样，编写测试通常会反过来挑战您的代码，以使您意识到实现还不够好……而且更重要的是，该规范与项目一起存在。 有时我会参考代码覆盖率。 我真的不相信通过代码覆盖实现代码库的合理性，但是我仍然认为这是确保测试和记录每个关键部分的一个良好的开端。
出于相同目的，将“ Wiki产品规格”转换为功能开发的规格，端到端测试也很有趣。
7.信心
做如此出色的工作而最终失败了，真是太可惜了。 您需要对要推向生产的信心。
- 拥有良好的CI
- 依赖版本已检查
- 易于回滚
- 易于投入生产（“推产品”按钮是我的圣杯）
当您将某个功能推向生产时，您需要让产品团队事先检查预生产以验证分支，并确保我们对推向生产的目标保持一致。
在进行逐步发行时，需要考虑的一些真正重要的事情：您需要制定推出计划。 看到此功能的用户百分比是多少？ 我们从一个特定的国家开始吗？ 这个国家的翻译已经准备好了吗？ 一旦开始部署功能，我建议您（或/和您的产品负责人）与数据分析师密切合作以监控部署。
以某种方式知道最后的变化非常重要。 根据项目的不同，您可能需要更新变更日志（更新+日期），或者它可能是Slack上的一个钩子脚本来警告所有人。 自动化该部分可能是一个好主意！
最后但并非最不重要的一点是，我想谈谈完成的定义。 您需要知道任务的结尾。 合并机票时是吗？ 什么时候通过质量检查验证？ 什么时候生产？ 逐步推出何时完成？ 何时删除旧代码？ 只要您的任务没有完成，您仍然应该保留一张票或提醒您（和您的团队）完成它的东西。
8.数据驱动
我不理解人们如何在技术和产品效率方面无法确定代码是否正常工作地将某些代码推入生产环境。 对我来说，必须对关键点添加一些监视，并跟踪用户的行为以了解如何发展，这是强制性的。 如果指标不够好，您将掌握所有信息以进行改进。 您需要能够比较自己的工作，因此，越早添加侦听器越好。
让我给你一个新的Blablacar前端架构的第一个版本的例子。 我们从旧的Symfony2 / Twig / Jquery堆栈移到了全新的服务器端渲染的ReactJS应用程序。 我们决定在登录页面上对其进行测试，因此，我们要做的第一件事是检查“旧”页面上的跟踪，以进行更新。 然后，我们发布了新页面，但是具有相同的HTML / CSS和UX / UI。 我们为什么要这样做？ 很简单：如果我们一次更改了太多事情，就无法验证架构，则指标可能由于太多原因而发生了变化。
现在，我们已经对跟踪系统进行了标准化，并且每个流程都有：
- 流的开始事件。
- 尝试完成：成员到达流程的结尾，并且正在尝试执行API调用以验证其操作。
- 其次是成功或失败事件。
通过发布新页面，我们会立即收到有趣的反馈，这使我们能够更新/改进某些功能。 非常有价值！
结论……
您可能会发现所有这些显而易见的情况，以建议人们进行有条理的准备。 但是，很少有团队能够从一开始就真正建立起这样一个良好的工作环境并能够随着时间的推移进行维护的团队。 作为项目的开发者，您有责任为这一级别的要求而战。
