当设计成为代码工作流程的一部分

我最近做了一个实验，在三个不同的应用程序中创建了相同的矢量插图，将插图以 SVG 格式导出到每个应用程序，然后 写了一篇帖子 比较导出的代码。

虽然我喜欢评论中出现的争论和见解，但我惊讶地发现，大部分讨论都集中在编译后的 SVG 文件的大小上。

我并不惊讶，因为性能和 SVG 并不总是相辅相成，或者说性能并不是我们在前端社区普遍关心的问题。 我感到惊讶的是，我个人从实验中得出的结论提醒我，SVG 代码最终还是代码，我们在应用程序中创建 SVG 的方式现在比过去更成为前端工作流程的一部分了。

我仍然相信这是文章的关键要点，我想写一篇后续文章，不仅更清楚地阐明这一点，而且还详细说明我们可能需要改变对使用 SVG 的项目的的设计交付物的思考方式。

设计与代码之间的差距正在缩小

我们已经知道这一点，并且已经赞扬了那些懂得代码的设计师的优点。 然而，SVG 实验向我揭示的是，这些优点不再是理想，而是越来越成为必需品。

如果一个项目需要 SVG，并且设计师被要求创建插图并提供设计资产供开发使用，那么设计师不再交付静态文件，而是交付一段代码，并且根据项目的范围，这段代码很可能被内联或直接注入 HTML 文档中。

当然，我们可以介入并检查提供的代码。 我们甚至可以将其通过像 SVGOMG 这样的工具运行，或者执行自动化任务，在代码被提供给生产环境之前帮助清理和优化代码。 这很好，但它并没有改变这样一个事实，即我们最初获得的是一段代码，并且现在在我们的工作流程中增加了一个额外的考虑因素，那就是对设计资产进行代码审查。

这是一个重大的变化。 它不是一个不好的变化，甚至在所有情况下都不成立，但它是一个重大的变化，仅仅是因为它要求我们改变对项目的设计交付物的思考、请求和处理方式。

一个新的设计礼仪时代正在到来

当我第一次了解 Photoshop 礼仪网站 时，我是众多粉丝之一。 它不仅触动了与其他设计师在网络项目中合作时遇到的许多真实的痛点，还迫使我重新审视并改进我自己的设计实践，以便更好地在团队中工作。 比如，像良好组织的图层，使用一致的命名约定，当文件从一个人传递到另一个人时，就会产生巨大的差异，就像 良好文档化的 CSS 使用一致的命名约定并且有很多注释。

SVG 使这些提示更像是一种必要性，而不是礼仪。 再次，现在我们有了成为代码的设计交付物，设计师所做的决定——从配置画板到图层如何分组和命名——都会影响 SVG 代码的编译方式以及最终在生产环境中的使用方式。

也许是时候为 Photoshop 礼仪创建一个分支，更专门针对使用插图应用程序的 SVG 设计交付物。

应用程序非常智能，但仍然需要人工干预

我之前帖子中 最喜欢的评论 是对 SVG 插图的手工编码版本。 代码比任何被比较的应用程序生成的版本都要干净得多，效率也更高。

无论评论的重点是什么，我最喜欢的是它证明了我们不能总是把应用程序给我们的东西视为理所当然。 Sketch 这样的应用程序能够将我在屏幕上绘制的一系列形状转换为有效且可用的代码，这真是太棒了，但它是否是最适合这种情况的代码？ 它可能是。 另一方面，评论者证明，如果目标是更小的文件大小和更易读的代码，那么可以做得更好。

我测试的所有三个应用程序都非常智能，非常有用，并且拥有独特的优势，使它们成为任何 Web 开发人员工具箱中合法且必不可少的工具。 这里重点不是不信任它们，也不是避免使用它们。

重点是，它们只有在使用者的帮助下才能发挥最大的作用。 如果我们给它们提供不好的形状和混乱的图层，那么我们很可能期望得到不太理想的代码。 我甚至可以说，我在实验中创建插图的方法很可能影响了所有三个案例的最终输出，并且可能没有给应用程序提供生成优质代码的最佳机会。

无论如何，它需要一个人来审查生成的代码并手动优化它，才能证明这一点。

总结

我要衷心感谢所有对之前帖子发表评论的人。 这项最初只是出于个人好奇心的简单实验，变成了一个更细致的实验，我很高兴看到它引发了健康的辩论和有见地的想法。 正是这些评论以及随后的线下讨论让我更深入地思考了设计与开发之间的交接，最终成为了整个练习的关键收获。