点击联系发帖人
时间：2022-06-05 03:18
这个问题问得好，感觉是这样，开局一张图，后面都靠想，就能把 UI 设计做的效果图转换成为代码。
总体来说，程序员同学们还是非常厉害的，能够把把前端页面从一张静态的图片，转化为一个活生生、有内容又有灵魂的界面。
但是这个过程，并没有那么简单，UI 设计师并不是单纯的只输出一张效果图，就可以了，还需要其他很多的操作才可以。
如果从工程师的角度来看，还需要更复杂的过程，才能够真正的理解效果图展示的是什么，然后再通过代码的建设，把他转化为一张张图形。
这样一个流程，基本上主要还是基于设计师的角度去看待整体的实现过程，而具体开发如何处理，我其实并不是特别专业，因此希望有做研发的朋友发现错误或者更明确其中的奥妙，可以随时在留言区内跟我进行互动，或者私信我也可以哦。
首先，研发工程师需要详细了解产品需求是什么。有可能通过整体的需求讨论会议；也有可能先看文档，再参加会议，这主要的目的，是要了解即将动手去开发的这款产品，是什么样的一个应用或者网站，它的主要功能是什么，它满足用户的需求有哪些。
从整体上了解一个产品，；了解产品目标是什么，知道哪一个部分是最重要的，以此来评估开发这样一款产品需要怎样的资源和时间计划。在这个前提下，基本上要保证所有的工程师都要参与进去，这里的研发角色会包括前端工程师、后台工程师和测试工程师，他们会通过具体的功能点，去判断产品该如何实现。不同类型的产品可能会有不一样的搭配，但是行业内大致还是会差不多的。
阅读需求的过程，对于设计师和研发人员来说，都是一个非常重要的 Kick Off 的仪式，象征着项目正式启动，开始了具体的实施部分。
在需求已经敲点，并且工程师们都解决了大致的疑问以后，就可以开始制定具体的研发计划以保证接下来的工作可以稳步的执行。
针对于前端的开发、后台的开发，改投入多少人力资源，以及所耗费时长，都要明确的有计划安排，包括与设计师的沟通时间，开发上的里程碑，提交测试的时间等等。这些是保证项目能够正常执行，并且可以让项目经理或产品经理有效的控制项目进度。
研发计划除了时间计划以外，还有整体开发框架的搭建，这就是说要有高级的工程师去把控全部，告诉其他研发人员该如何进行开发，这部分我就不是很了解了，有些特别的需求，还要引入开发调研的过程。
对于前端工程师，这时候就要开始详细阅读交互设计原型，了解具体的界面操作情况。包括用户的操作流程，界面的跳转，点击控件后的反馈，以及每一个任务最终的结果等等。
一份交互设计原型的好坏，对于前端工程师的工作效率影响会非常大。清晰的展示清楚具体的交互流程和操作步骤，那么也会减少工程师出现遗漏或者含糊不清的地方。
在了解清楚具体的界面情况以后，此时的工程师们就可以去找视觉设计要东西了，针对于界面视觉效果图的投入实现这时候才刚刚开始。
视觉设计师此时要输出的内容，会包括以下几个部分：
工程师往往要拿以上元素，才能够正常的投入到前端开发和搭建过程中去。
视觉效果图是让开发人员能够非常直观的感受到具体界面的样式，能够明白自己的代码应该最终实现的目标是什么样。
我们都十分肯定的说，对于前端开发工程师来说，要把视觉设计效果图百分百的还原出来，这是最基本的要求。
在过去的项目中，我们遇到很多工程师，他们对于视觉效果图的视觉理解和设计师大相径庭，有很多的细节他们不能够完整的获取到，因此实现的时候就会投入很多自己的猜测或者臆想，如果在这个阶段沟通不到位，那么工程师可能对于每个界面要反复的投入时间去修改，才能够最终的达成目标。
对于视觉设计来说，这方面的要求要提升，而且要勤于沟通。我们曾经一起合作的项目中，外包的开发工程师说我们的 UI 设计师是他碰到的最恐怖的 UI 设计师，真的是对于他实现的界面效果与视觉效果图要求丝毫不差。
虽然很多人会觉得这样是把大量的时间投入到不必要的地方，但是在我们看来，一个产品就是要做到每一个细节都无比精致，才能让这个产品的质量保证是在一定的高度，为用户提供最佳的体验效果。
切图元素说白了，就是实现界面的时候，工程师需要搭建在界面中的材料——你可以理解为盖房子需要的砖。
一般情况下，提供的切图元素都会是比较小的图片，如果能够使用代码实现的部分，就不需要以图片的形式展示。一般情况下，会有几种情况会使用图片的方式来搭建界面。
对于设计师来说，可以提供的切图元素包括几种格式：JPG 、PNG 、GIF 、SVG 。 一般情况下， SVG 会用来实现图标，因为这种格式是矢量的，所以可以进行缩放展示。
另外，有一个要求，就是设计师要在提交所有的切图元素之前，把这些图片尽可能的进行压缩，让图片变得非常小，有利于缩减页面加载或者 APP 安装包的尺寸大小。
坐标标注就是我们常说的界面 Layout ——说白了，就是界面的整体构成，以及切图元素该如何在界面中进行布局。
在过去的很长一段时间里，坐标标注，还是要依靠设计师提前跟工程师约定好了该如何进行标注，以什么位置作为原点，然后位置的数值该如何进行展示等等一系列的规范，以保证设计师输出的标注图示工程师能够特别清晰的明白具体元素的位置。
这个行业的所有东西进步的还是非常快速的，坐标标注这种事情也是，工程师和设计师都会快速的去寻找好用的方法和工具，比如说 Sketch 的众多插件可以缩短 iOS 工程师和视觉设计师的协作链路，坐标也会很容易就被二者通过约定快速达成共识；像蓝湖这样的工具，也提升了二者之间沟通的效率。
我们之前的时候遇到一个安卓开发工程师是非常愿意动脑筋的，他自己发现可以把效果图直接导入到开发工具中，然后根据效果图中图示的位置自己把握各种元素的布局，这样就能够节约设计师非常大的工作量。
不得不提到一下，就是 iOS 研发工程师和 Android 工程师对于坐标标注的要求是不一样的，单位就会有很大的区别，标注的思路也会有一点点的不同，因此设计师在做标注的工作前，要第一时间跟工程师们分别进行沟通，然后输出不一样的标注物料。
还有一个关键的步骤，就是适配。iOS 的适配在早期屏幕尺寸比较固定，适配的工作相对来说会容易很多，Android 屏幕尺寸在市场中会比较多，所以设计师在做界面坐标标注的时候，要注意一些适用范围比较广泛的几种机型界面尺寸，然后要兼容所有的可能性。
还好现在的移动端适配工作变得越来越容易，所以设计师和工程师之间的沟通也会变得容易很多。
动画说明的输出，也是关键的步骤之一。有些动画可以直接使用 GIF ，所以只要把这类的元素考虑成为一个个体即可。
有些动画则需要工程师使用代码实现或者使用若干张图片拼接而成，那么就需要有详细的动画说明以及每个关键真输出单独的一张图。
有很多时候，工程师还是使用 GIF 的形式会更多的缩短研发时间，在设计师做具体的设计时候，也要考虑到动画的实现情况，因此也要跟工程师多做沟通，否则做出来特别复杂的动画，让研发投入大量精力去实现，这就有些得不偿失了。
UI KIT 能够包含所有的视觉效果的说明，其中有切图元素，也有控件展示等等。要注意这不仅仅是把所有的视觉元素集合在一起，而还需要把这些东西进行归纳，让后续接受的设计师和工程师都能够在第一时间获取到产品整体视觉设计的情况。
视觉设计规范的意义也在于此，全局展示这个产品整体的设计是什么，其次是为了后续有新成员加入到团队中，可以快速学习现有设计的情况。
其中，这部分内容中不仅仅是展示控件、特殊界面等，还要包括色彩、字体、所要应用的字号等等。这部分也是开发实现的时候，需要重点参考的信息。毕竟直接以文字的像是在界面中展示内容，会容易一些。
一般情况下，设计师因为时间有限，往往是先输出 UI KIT ，通过一整张图片或几张图示展示清楚所有的视觉元素。在项目后续阶段，时间允许的情况下，再逐步输出视觉设计规范。
我之前回答了如何制作 UI 设计规范这个问题，如果有兴趣的朋友可以详细阅读一下，里面还是很全面的介绍了 UI 设计规范所要包含的内容。
在前端工程师把具体的界面设计都实现了以后，那么就进入到一个关键的阶段——开始设计走查。
这个工作其实在很多团队中，会被大家都忽略掉，或者融入到测试的工作中去。
在我们的团队，一直都是要把这部分工作单独提取出来，用1至2天的时间，单独拿出来做走查。
前面我有提到过，我们会要求前端工程师把视觉设计进行百分百的还原，其实不仅仅是视觉设计，交互设计也是一样的。
我们会让交互设计师走查所有的流程、界面信息展示、反馈、以及界面使用逻辑、控件使用逻辑等是否符合之前提交的设计方案。
同时，视觉设计师也会对视觉设计效果做同样地走查工作，考察每一个细节实现的效果，包括色彩、阴影、位置等等。视觉设计师都是像素眼，大家可以考察一下自己团队中的设计师是否是这样。
我们之前遇到过很多开发的同事，他们在阅读交互设计文档、UI KIT 、坐标标注说明的时候，并不认真或者默认有些信息就给忽略掉，以至于实现出来的效果有很多都是自己编的，因此也在走查阶段加班很多来重新填补细节或者修正错误。
因此我也建议各位研发工程师，在做具体的实现时候，也要在界面设计的细节上多投入点时间和精力，以保证完全实现设计师的设计效果。这也是工程师需要不断提升自己去学习的地方。
好啦，如果走查完毕，全都修改过来了，或者因为项目时间过于紧张的情况，只实现了90%以上——只要产品经理或者团队领导考虑大局这样决定，那么设计师也要做妥协——那么就可以投入到具体的产品测试中去了。
设计师和前端工程师的合作也要稍微松一口气。
我讲了这个流程以后，大家是否明白了开发程序员是如何根据一张 UI 设计师做成 APP 的界面了吗？这后面还有很多跟后台工程师对接的部分，以保证应用内有东西可以去进行展示——当然了，如果是单纯的一款没有后台的应用，也有可能。
现在行业的发展速度非常快，因此设计师和工程师在个人技能、使用的工具以及个人技法上也在不断的进行优化。互联网整体的工作流程也在不断的发生着天翻地覆的变化，因此我们的设计师每年输出的东西，都会有些变化，研发工程师要求拿到的物料也每年都会有所不同。这就要求，这个行业里面的每一个角色，包括产品经理、设计师们、研发人员和测试人员，包括运营都要不断的去学习——一方面要学习自己的节能领域的东西，还要不断的去了解别人的领域的东西。
我是国内最早一批移动互联网产品经理和设计师，在知乎里有130多万人关注。知群是高端职业教育平台，学生包括国内外各大高校在校生、苹果、谷歌、微软、阿里、腾讯、字节、小米等的在职员工。现在还有各大公司P8、P9、P10的专家和高校教授在知群分享经验。
现在有免费的5天学习机会，帮助你了解阿里、腾讯的工作方法论，更好的入门或者提升。在这里了解详情和报名：
应该是你能接触到的最有干货的免费课程，机会有限。
}body {background:url(bg.jpg) top center no-repeat; background-size:cover;}
这样的话背景图片就会填充整个屏幕了
不过要说明的是，这是一个CSS3的属性，在很多浏览器里面都是不被支持的，你所希望的效果，目前来看，只有这个属性可以做到，否则就只能用一个足够大的图片做背景的方法来实现了。
另外 background-size:cover;还可以替换成 background-size:contain;使用cover的意思是把背景图片充满整个容器，而不考虑是不是可以看到完整的图片；使用contain的意思是在容器里完整显示图片，而不考虑容器是否被填满。
我是一名学习各种编程技术的学生，并且遇到过伪代码和流程图。我知道这两个都是为了在实际编程之前仔细考虑问题，但是我对此有一些疑问。
我真的不记得上一次看到编码流程图了。类和数据流图，用例图，是的。但不是流程图。也许它们在游戏开发中更为普遍。
@ RobertHarvey，FSM图（本质上是流程图）在硬件设计中经常使用
流程图和伪代码通常具有相同的表达水平，但线性化程度不同。伪代码是线性的（即带有指令的行序列），流程图不是。因此，流程图是较高的抽象级别，在编写伪代码之前或用于文档时使用。
在我看来，流程图比伪代码有两个强大的优势：首先，它们是图形的。许多非技术人员都非常担心结构化文本，而对图形化描述则不那么担心，因此流程图对他们来说会更好。其次，流程图在表达元思考方面要好得多，例如显示与分支相对的执行主线。
流程图也是确保每个决策点都为不太常见的路径和最常见的路径定义动作的好方法。这有助于确保您在拒绝批准或取消订单时知道该怎么办！在极端情况下，通常会有更多的错误，因为人们在测试发现它们时会忘记做这些错误或在质量检查期间匆忙地执行它们。
老实说，我不使用伪代码。通常，仅编写代码会更快，因此，当我完成代码后，它就是实际的代码。在某些情况下，伪代码可能会有所帮助，但通常您正在处理非常复杂的内容，而只是试图破坏方法或某些内容的结构。在这些情况下，我会在IDE中使用注释来布局结构，直到正确为止。然后，我进入并在注释中编写实际代码。这可以帮助我做一些事情：
代码通常会发生很大的变化，以至于流程图除了更大，更全系统范围的体系结构设计或文档之外，对流程图没有帮助。在那种情况下，我将只在白板上画一张图，以了解事情的要点或向团队中的其他人展示。除非您确实需要流程图来帮助您理解，否则您实际上并不需要他们“正确”执行软件。如今，有许多的从代码本身以及类图和其他代码生成流程图（）。您需要做一个非常准确的流程图的唯一实时时间是，您无法立即保留整个体系结构以及事物如何在您的脑海中运转，并且需要通过可视化方式进行交流。
通常，我在个人项目上工作时不会写流程图（因为项目规模不大），并且大多数输入，输出和过程都很清晰。
但是随着您将开始处理具有不同输入源的复杂大型项目，平面文件，数据库，手动界面等流程图非常方便。
我建议您编写伪代码和UML语法，因为这些工具将帮助您提出更好的类，方法等。有时，在编写伪代码时，您会发现解决程序的不同且更有效的方法。
伪代码是为了向那些至少了解代码基础的人快速表达一个想法。流程图为其他人理解相同的事物绘制了漂亮的图画。
流程图通常用于文档目的，因为许多人使用该文档，并且流程图对于非程序员而言比伪代码更易于遵循。在您自己进行的项目中，坚持使用伪代码很好，因为伪代码更加有用，而且创建起来也容易得多，因为您只需要文本编辑器。
流程图是一种高度抽象的概念，它们使您可以计划应该如何进行，例如
他们不需要依靠类和方法来设计程序，而伪代码则提供了较低的抽象级别（尽管它确实取决于）
这样便可以根据您使用的语言将伪代码转换为实际程序。
对于游戏，我建议先使用流程图，然后设计类和方法，编写伪代码，最后将其转换为程序
我会考虑您正在编写的代码的性质。如果是：
在前两种情况下，伪代码变得比大图片图越来越难阅读。另一方面，大部分是线性的代码使图表变得无聊得令人厌烦，这实际上使该过程变得更加难以理解，因为它炸了多少。
对于第三种情况，流程图更擅长表示跨越系统边界并代表整个过程的过程。
可以编写Java时为什么还要编写伪代码？我发现Java，良好的IDE和Javadoc是解决编程问题的最简单方法-至少是面向对象的。（并且，街机游戏应该是OO。）为此，我们从头开始设计语言。它简单明了。（也许对于许多目的来说太简单了，但是，这是我所见过的最好的东西。）Javadoc中的超文本以及通过IDE在代码本身中的超文本构成了比您甚至都无法理解的“图表”一张大纸。Java代码与任何伪代码一样简单，而且更加严格。并且一旦您对它进行了“图解”和“伪”编码，该程序就会真正运行！
InputStreamReader（System.in））；现在显然更容易了 但实际上，您调用的任何库都可能会，而不是像您可以想象的那样简洁的伪代码
同样使用Java或任何语言，您会遇到编译错误。没有一个带有伪代码。您可以专注于设计而不会分心。伪代码的注释可以更简短，因为伪代码在头脑中更清晰。您不仅可以只考虑一种语言，而且您可能会看到啊，我将使用另一种语言。编写起来更快捷，更省力（无需编译-甚至非常流利的编译错误），因此更少的编写时间使重新设计变得更加容易。
@barlop：它对我有用，但可能不适用于每个人。我在类中遗漏了很多代码（例如“ BufferedReader”），直到需要它或需要知道是否可以使它工作为止。即使拥有了它，它也很好地隐藏在我不需要考虑整体设计的类中。编译器错误很容易修复，可以避免重大的设计缺陷，例如在无法获得正确类实例的地方使用错误的类。我承认，我已经以这种方式“设计”了只能用Java编写的软件，但是OP 正在使用Java。
假设您要打开一个文件，您看到openfile（“ c：\ blah \ file”）的伪代码比Java短吗？还是那个打印“ dfdfd”比java做的短？我还没有完成伪代码和多个类的页面。部分原因是因为我年龄还没有编写大型程序b）部分原因是我认为我不会，我想我会写一些伪代码然后将其实现。任何其他伪代码（如果有）将是更高级别的。我可能会列出所有类和方法，包括构造函数。所以我知道什么类是什么，我可以得到它的一个实例..
所以我不会处于使用错误类的情况，但是无论如何，如果是我的程序，我会在笔记中写下什么类是什么..类是相当高级的。如果我不记得它，我会做个说明。伪代码是关于什么意思的全部内容，因此，如果您打算创建类等等的实例并编写了bleh，那么这只是一种书写上的错字，但这并不妨碍您的设计。（如果您是为自己写的，因为“ cos，您就知道您的意思，并且像是在使用blah）。
如果您对if语句感到非常困惑，并且试图理解这一点，则可以使用流程图。或者，如果您想了解循环，请查看计数器的效果。如果您正在学习，它会有所帮助。
感觉有点限制性，因为您必须在框中输入简短的声明。而且，如果您的程序是非常线性的，并且循环和ifs都很琐碎，那么我认为它没有用。
伪代码在设计程序时很有用，而不必分散语法正确性的注意力，并且不会引起某些语言的冗长困扰。编写起来更快，这也使得重新设计代码变得更加容易。而且，您可以按照自己的想法进行简明扼要的编写，令人愉悦的编写，花费更少的心思才能投入使用（无需或几乎不用调试），并且可以更加专注于全局和设计。
它们也可以用来与他人交流。
