将网站设计文件转化为HTML、CSS和JavaScript的组合，是许多前端网络开发工作的面包和黄油，但这项工作有一部分并不适合在任何特定主题的教程中整齐地进行。有一个分解设计和弄清如何构建的过程，似乎属于新的前端开发者的在职培训。这不是与核心技术一起教授的东西（无论我们在哪里学习这些技术--大学、训练营、或自己学习）。
在这篇文章中，我们将看看如何从设计到代码，以及为什么你可能想要遵循这样一个过程，而不是一头扎进代码中--让我们面对现实吧，我们喜欢这样做!这篇文章的内容是基于我在接纳新的开发人员方面的经验，我们所进行的各种对话，以及我在这些情况下所提供的帮助和反馈。
从设计到代码的过程是一个前端开发的核心专业技能，原因之一是如果没有一些方法来挖掘和预测你将如何处理一些事情，就很难提供一个估计，即需要多长时间来制作，或者在开始之前可能需要回答哪些问题。 许多设计乍一看可能很简单，但一旦你进入杂草丛中，很快就会变得复杂。我看到这导致了过度的承诺，这往往会导致更紧的期限、压力和更糟糕的副作用。突然间，一切都比我们最初想象的要长得多。讨厌。让我们看看我们是否可以避免这种情况。
评估一个设计
作为谈论这个问题的一种方式，让我们使用一个 "营销风格 "网页的设计实例，并假设我们被要求实施它。我们也可以假设这个网站是在这样的背景下创建的，营销专家可能会进来通过一些内容管理系统（CMS）来编辑内容，重新安排章节的顺序，替换图片，并进行风格的改变。因此，我们需要决定页面的组成部分，这些组成部分将成为CMS中使用的构建块。
这就涉及到另一个在教育中可能被忽略的原因：在我们自己的单独项目中，我们可以在HTML中拥有静态内容，而组件部分不会被陌生人用科学怪人的方式组合起来，形成全新的页面和部分。但是一旦你踏入更真实的开发环境，事情就会变得更加动态，我们经常在 "做一些非开发人员可以用来做网页的东西 "这一层工作。
由我的朋友丹-奥特制作并提供的设计
让我们以这个临床试验的网站为例。我们可以看到有很多熟悉的设计元素。营销网站往往有共同的模式：
- 一个大的主角部分
- 产品图片
- 独立的小部分短篇内容，强调一件事或另一件事
- 关于公司的信息
- 等等。
在移动端，我们可以认为，在每个部分，左边的列将堆叠在右边的上面，还有一些其他相当典型的回流将发生。在手机上，没有什么结构性的变化。所以我们要看的是设计的核心部分。
在这个例子中，有一个页眉，然后是许多不同的部分，还有一个页脚。一眼望去，有些部分看起来有点类似--例如，有几个部分采用了两栏式布局。有一些按钮和标题的风格似乎是一致的。只要你看一看这样的东西，你的眼睛就会开始注意到这样的重复模式。
这就是我们开始做笔记的地方。在我们做任何编码之前，让我们了解设计中包含的想法。这些想法可以分为几大类，我们希望我们的最终产品--网页本身--能够正确地表达所有这些想法。下面是我常用的几个桶：
- 布局级模式--重复的布局思想和整体网格
- 元素级模式--标题、文本大小、字体、间距、图标、按钮大小
- 颜色调色板
- 结构理念--各部分的逻辑组织，独立于布局。
- 其他的东西--只存在于一个部分的想法。
以这种方式记录模式，不仅有助于我们确定CSS的方法，还有助于选择使用哪些HTML元素，并在有不清楚的地方开始与设计师或其他利益相关者对话。如果你能接触到设计的源文件，其中的章节和图层可能会被标示出来，让你很好地了解设计师的想法。当你想讨论特定的部分时，这可能很有帮助。
因此，让我们来看看我们的设计实例中所包含的想法。我们将对这个设计做几次检查，在所有的检查中，我们将从外到内，从上到下，从左到右，以确保我们评估每一个元素。在这五次检查中的每一次，我们都在寻找那些只属于其中一个桶的东西。
我们并不关心这个清单是否完美；它总是可以在以后被改变--我们只是想记录我们的第一印象。
通道1：布局层面的想法
在这个设计中，我们有几个布局的想法，一开始就很突出。
- 一个带有水平导航部分的页眉
- 在内容区域内有一个主要的内容栏--从页眉到页脚的所有部分的左右边缘对齐
- 有两列的栏目
- 有一个居中的单列的部分
- 单一左对齐列的部分
- 有三列的页脚
- 每一节内有相当大的填充物
第一印象
我们应该注意到我们在这第一遍中的任何其他第一印象，无论好坏。我们的第一印象不可能有两次，如果我们现在忽略了记录，我们的一些直觉反应和问题会被遗忘。另外，当我们与设计师交谈时，确定你在设计中喜欢的具体内容会很好。这既有助于赞美好的东西，也有助于将其与其他建设性的批评意见混合在一起。
我们的第一印象可能是这样的：
- 👍 设计看起来很干净，可读性强。
- 👍 所有的章节都以问题为标题（很好，有助于吸引读者，并给每个章节一个明确的目的）。
- 🤨 标题中的问号使用不一致（可能只是疏忽？
- 🙋♀️有时字体大小非常相似，彼此相邻（可能需要跟进，看看这是否是故意的，因为它看起来没有网站的其他部分那么光滑和专业）。
- 👍 徽标的小渐变效果不错。
第2关：元素层面的想法
以下是我们在第二轮设计中可能注意到的东西：
- 主要（蓝色）和次要（白色）按钮样式，加上标题中带有小箭头的 "了解更多 "按钮（也许是一个扩展菜单？
- 标题和副标题样式
- 三种 "正文 "尺寸 (
16px,18px,20px) - 一个 "深色模式 "部分，文本颜色为白色，背景为深色
- 一致的 "图像和标题 "集介绍
- 自定义各种类型的子弹头
- 文本中的内联链接有下划线，而，其他链接，如页脚中的链接，则没有。
- 一个重复的卡片组件，上面有一个图标，卡片内有一个标题和一个列表
- 标志在不同的背景/尺寸下重复了几次。
- 页脚包含其他地方没有出现的大写字母标题。
Pass 3: 调色板
在这个设计中，从颜色上看没有太多的变化。
- 蓝色/紫色的主色调
- 浅色/深色的主体文字颜色
- 浅/深的链接色
- 标志中的 "希望 "一词下有漂亮的渐变色
- 浅灰色背景色
- 深蓝色的背景颜色
- 特定的红色和绿色 "复选标记 "和 "停止 "图标颜色
有些设计工具可以让你导出设计文件中使用的颜色十六进制值，甚至是完全的Sass或CSS变量声明。如果你有这个选项，请使用它。否则，就自己想办法抓取这些值并为它们命名，因为这些是我们很多初始CSS工作的基础。
在我们的CSS和其他代码中，我们希望用标签或像 "主要 "和 "次要 "这样的类来指代颜色，以便我们在整个代码中重复使用。这使得我们在将来调整数值时更加容易，如果需要的话，也可以在以后添加主题。
第4关：结构思路
在这里，我们可以用对我们有意义的方式来命名页面的区域，并确定内容的层次结构。我们可以通过用简单的语言记录我们所看到的页面内容的性质和结构，来开始了解我们实施的可访问性需求。一如既往，在我们进行评估时，要从外到内，从上到下，从左到右。
关注结构有助于我们找出最终成为我们组件的基本模式，也有助于我们理解我们希望使用辅助技术的人感知内容的方式。反过来，就我们需要使用哪些HTML元素来编写语义HTML而言，这也是对我们的指导。语义化的HTML讲的是内容的性质和结构，以便让浏览器能够正确地感知它。浏览器使用我们的HTML来创建辅助技术（如屏幕阅读器）用来呈现页面的可及性树。他们需要一个强有力的纲要才能成功，而语义HTML则提供了这种坚实的结构。
这意味着，我们需要很好地理解页面上的内容的性质，以至于我们可以在没有视觉支持的情况下对其进行口头解释。从这种理解出发，我们可以通过可及性树（accessibility tree）来倒推，找出表达这种理解的正确的HTML，这可以在你的浏览器的开发工具中进行检查。
下面是Chrome浏览器中可访问性树的一个快速例子，如果页面上的所有内容都是div ，并且正确选择元素以匹配内容的性质。确定在特定情况下的最佳元素选择已经超出了本篇文章的范围，但我只想说，下面这个富有表现力的、非 "通用通用 "的可访问性树完全是用HTML元素和属性创建的，它使内容及其组织更容易被使用辅助技术的人所感知。
所以，在这第四遍中，我们可能会做以下说明：
- 顶层结构。
- 页首
- 主要内容
- 页脚
从上到下的第一遍还不错。让我们再深入一个层次。我们仍然不关心章节本身的内部元素--我们只想要足够的信息来标记每个章节内的顶级项目：
- 在标题中，有：
- 首页链接
- 导航部分
- 在主要内容中，有：
- 英雄部分
- 关于疾病本身的简短解释
- 关于治疗的解释
- 试验的介绍
- 关于试验的更多细节的解释
- 关于谁可以参加研究的说明
- 参与行动的呼吁
- 关于公司的简短说明
- 在页脚内有：
- 标志
- 摘要句子
- 一些带有标题的链接清单
- 分隔符
- 版权声明
这段话揭示了几件事。首先，页眉和页脚部分是相当浅的，已经暴露了链接和文本等原始元素。第二，主部分有八个不同的子部分，每个部分都有自己的主题。
我们要在这里再做一次，在这些部分中了解一些更深层次的细节。
- 页眉首页链接--呜呼，这只是一个链接，我们已经完成了。
- 标题导航--这是一个扩展的悬停导航，需要JavaScript来正确工作。可能有很多可供借鉴的例子，但与我们使用原始链接相比，仍然需要更多时间来开发和测试。
- 英雄
- 标题
- 第一栏
- 副标题（我们在第一个元素层面上错过了这一点
- 段落
- 主按钮链接
- 二级按钮链接
- 第二栏
- 英雄图像
- 疾病解释器
- 标题
- 段落
- 无序列表
- 大文本
- 无序列表
- 图像和标题（图和图解）。
- 链接列表
- 治疗解释器
- 标题
- 第一栏
- 段落
- 第二列
- 图像和标题（图和图例说明）。
- 试验-介绍
- 标题
- 专栏1
- YouTube视频播放器
- 第2列
- 段落
- 试用-更多细节
- 标题
- 副标题
- 卡片（包括图标、标题和列表
- "谁可以加入 "声明
- 标题
- 第1栏
- 段落
- 无序列表
- 第2栏
- 段落
- 无序列表
- 行动呼吁
- 标题
- 段落
- 二级按钮链接
- 关于公司
- 标题
- 段落
Yowza，这段话很快就变得很长了!但现在我们已经很清楚地了解了我们需要构建的东西的种类，以及哪些部分可能比较棘手。我们还看到，可能有一些需要建立的辅助组件并不完全被这些部分所代表，例如，一个双栏布局组件，在移动端堆叠成一栏，并在上面有一个标题，或者一个通用的 "章节容器 "组件，它需要一个背景和前景颜色，并提供正确的样式和标准化的内部填充。
顺便说一下，通过这个分解，我们已经很好地表达了我们希望我们的HTML创建的最终可访问性树，所以我们很好地让实施成为一个顺利的体验，而不需要大量的重新工作来获得可访问性。
第5关：其他一切
这个设计中包含的其他想法，突出的东西，或者我们注意到的挑战是什么？也许不多，但这是 "第一印象 "笔记的另一面。现在我们的脑子里充满了设计中的背景。
如果现在有什么突出的东西，特别是如果它是一个关于某些东西如何工作的问题，就抓住它。一个例子是，"嗯，导航中的'了解更多'链接应该是做什么的？"答案可能是。"这是一个通往每个部分的链接列表，当你把鼠标移到那里时就会打开。"每当这个时候，设计师就会想到，这种东西已经隐含在设计中了，即使没有明确地记录下来，也是在那个东西开发出来_后_的设计审查阶段才出现的--这往往是在不影响日期和期限的情况下来不及纠正的。
我们现在还应该深入观察并确定任何隐藏的 "胶水工作"--比如把我们的样式整理好，处理好移动端，配置好CMS，为我们的构件添加并测试编写选项和安排，以及添加自动测试。诸如此类的事情。
在这一点上，我们已经准备好确定在CMS中可以创建哪些组件。也许在过去的工作中，我们已经在当前的系统中完成了一些基本设置。无论怎样，我们已经有了足够的依据，可以对所需的工作进行适当的估计，并将其分为几类。例如，我们可以将以下组件分类：
- 已经100%准备就绪（不需要开发时间）。
- 已经存在，但需要为这个新的目的进行调整 （ 需要可预测的 开发时间）。
- 完全是新的，但路径是明显和安全的 （ 需要 可预测的 开发时间）。
- 完全是新的，需要一些研究来实现。或者设计不明确，或者有些东西让你感到毛骨悚然，你需要和利益相关者进行讨论。你越早发现这个问题就越好。和负责项目的人讨论一下。
现在我们有足够的信息来做一个合理的估计。更重要的是，我们已经减少了项目所需的总时间，并限制了我们在途中可能遇到的麻烦，因为我们已经从规划中获得了一些优势。
拥有一个过程的优势
我们所采取的具体步骤和完成的顺序并不是重点。最重要的是了解你在开始做一个项目时需要收集什么样的信息。你可能对工作的完成方式和顺序有自己的想法，只要适合你的就是好的。
以下是我在评估设计时意识到的优势，与仅仅是潜心研究，"把东西弄好"，并在事情出现时加以处理相比。
你可以做一些额外的发现
尽管我们希望每个项目都能完全成型，并且完全准备好开始，但在现实中，设计常常包含一些假设，这些假设可能是不切实际的，或者与我们关心的其他事情相矛盾，比如可及性。在这种情况下，你可以预先评估整个事情，并与那些能够在过程早期解决这些问题的人开始对话。这可以在你潜心研究准备编码的部分时发生，并将阻止你在以后即将建立该部分时碰上这些路障。尽早标明关注点，肯定会得到需要解决这些问题的人的赞赏。
你可以得到别人的帮助
如果没有计划，就很难了解你在完成项目方面有多大进展，也很难知道你是否需要帮助来完成最后期限。即使你确实需要帮助，并且能够请求帮助，但如果不把工作分解成容易分担的小块，就很难有效地利用额外的帮手。当你有一个有意义的计划时，你可以迅速委托某些票据，知道这些拼图最后会拼在一起。
对于一个新的开发人员来说，认为巨大的工作量和昼夜不停的工作是一件好事，这很容易（也很常见）。但是，随着你在这个角色上的成熟，你会发现，对一个项目的全貌，甚至是一个单一的票据有深刻的理解，是更有价值的，同时也会给人留下更好的印象，让人觉得你是 "在事情的顶端"。尽早认识到一个时间表看起来不对，让你可以选择如何解决这个问题，而不是试图成为一个英雄，扔下一些周末去做。
组件架构更流畅
架构决定对我来说是_最糟糕的_。命名组件，弄清楚东西应该放在哪里，哪些组件需要相互对话，在哪里把东西分成更小的组件。只有当我们从大局出发，考虑到某些元素可能被访问者和内容创造者使用的各种方式时，这些选择才有意义。_很多_选择都是边缘化的--在两个可接受的解决方案中选择 "最佳 "选项可能会耗费大量时间，或者完全是主观的。
有一个过程有助于解决这个问题，因为在深入挖掘开发工作之前，你会得到关于设计的所有或大部分信息。对我来说，弄清楚我需要做什么作品，和弄清楚做这些作品的最佳代码，是两件不同的事情。有时候，我需要的东西并不是从代码中最自然产生的东西。有时，在了解了所需的东西之后，我可以避免花时间在边缘决定上，因为我更清楚哪些决定是真正不重要的。
当然，你在写代码的时候还是会学到新的东西，但是你现在已经为处理这些东西做好了准备，当它们出现的时候。你甚至对那些可能出现的问题有了一个很好的概念。
风格更有意义
当你计划工作时，你可以真正弄清楚哪些样式是全局的，哪些是特定的部分，哪些是特定的组件，哪些是一次性的例外。如果你还没有一个你喜欢的系统，Andy Bell的Cube CSS可以很好地配合我所说的那种细分。这里有一段Andy与Chris Coyier一起完成一个例子的视频，你可以查看一下，以了解更多关于这种方法的信息。
可访问性在流程中尽早开始
这一点对我来说是非常重要的。通过真正理解设计中所包含的想法，你将更容易挑选语义丰富的HTML元素，并找到适当的可访问模式来构建你所看到的东西。可访问性可以在你的日常工作中发挥作用，而不是事后考虑或额外负担。我们的观点是，高质量的前端代码能够正确地向所有用户表达其内容的性质和结构，而无障碍性是我们衡量的方式。
在一个相当短的时间内，你会发现设计经常符合一种或另一种已知的模式，而将一些东西分解成已知的模式来实现的流程会大大加快。Carie Fisher很好地总结了与这种 "可及性优先 "方法有关的想法。
总结
就像我一开始说的那样，这些东西很多都属于在职培训，也就是网络开发的 "口头传统"。当你开始担任你的第一个前端角色时，你可能会从你的团队中的一个高级开发人员那里听到这些东西。我相信很多人都会有与我不同的优先级，并推荐一个稍微不同的过程。我也知道，很多人在工作中都没有一个坚实的流程，也没有人可以咨询。
如果你处于这种情况，或者还没有进入你的第一个角色，我希望这能给你一个基线，让你在考虑如何做这项工作时能有所参考。理想的情况是，这项工作不只是潜入和把东西放在div里，直到事情看起来 "正确"，但这往往是我们的操作模式。我们急于取得进展，看到结果。
我非常感谢在我的第一份开发工作中确实有人和我一起工作，他向我展示了如何分割设计的各个部分，并对大型长期项目的工作进行估算。这启发了我开始思考这个问题，并且在我开始监督其他开发人员和团队的时候，思考我想如何调整这个过程并使之成为我自己的过程。我还意识到，在教授使用某种特定语言的技术技能时，我并没有注意到人们谈论过这个问题。所以谢谢你，Nate!
