一般来说，是让所有功能部件先使UI工作-还是两者兼而有之更好？
Answers:
在许多业务用户和客户中都有一个普遍的概念，即当看起来完整时，它几乎是完整的。您可能知道，这与事实相去甚远。一个可以使它看起来不错，但是没有后端，并且一些用户认为使它看起来不错是工作的80％，而不是20％（或其他80％）。
无数的开发人员可以讲述这个恐怖的故事-使用其他工具的屏幕快照在Microsoft Word中完成页面的模型制作，并且客户说“那么，您已经完成了吗？”
您需要调整进度，以便完成所有部分。尝试先做所有后端，然后再做所有前端，将导致最终用户认为您什么都没做，并问为什么在没有东西可显示时您会得到报酬。另一方面，首先是前端，您将发现最终用户进行细微的更改并消耗了我们所有的时间。
“一个第一，另一个”的最坏情况是，当您到达另一部分时，您发现它根本不适合设计。
因此，建立两者。在前端显示进度，使后端与您所构建的对象一起工作。在很多情况下，交付增量构建并确保您满足客户的需求是一个好主意（这涉及敏捷）。展望过长用了“看得见的进展”会损害客户关系（这是双方的“万象做到早”和“没有什么是直到最后一刻完成”的情况下-它很难为客户端看到正在写的框架或单元测试或数据清理作为进度）。
乔尔在《冰山的秘密》（The Iceberg Secret，Revealed）中写道：
重要推论二。如果您向非程序员展示具有100％漂亮用户界面的屏幕，他们会认为该程序即将完成。
不是程序员的人只是看着屏幕，看到一些像素。而且，如果像素看起来像他们组成的程序能够执行某项操作，他们就会认为“哦，天哪，要使其真正发挥作用，会有多少困难？”
这里最大的风险是，如果您首先模拟用户界面，大概是为了与客户进行一些对话，那么每个人都会以为您已经完成了。然后，当您度过第二年的工作时间时，可以这么说，没人会真正看到您在做什么，他们会认为这没什么。
在博客文章“ 不要让演示看起来完成”中再次重申了这一点，它具有以下有用的图形：
请注意，这里的两个选项通常反映“完成ui”（然后期望您很快就可以完成）和“完成后端”（然后客户担心您错过了最后期限）。
事物看起来“完成”的方式应该与事物“完成”的方式匹配。
每个软件开发人员在其职业生涯中都经历过多次。但是台式机发布工具也给技术作家带来同样的麻烦-如果您向某人展示具有完美字体和格式的草稿，他们会认为完成起来比您想要的要多。我们需要在我们所处的位置和其他人所认为的我们之间的匹配。
本文还提出了关于用户界面的不同完成级别所获得的反馈类型的重点。如果您看似完整的内容，则比“此布局无效-选项卡太多”，您更有可能收到有关“可以更改字体”的反馈。
对于那些在Java Swing世界中与之抗争的人来说，有一种名为Napkin的外观和感觉，它可以使UI看起来不完整（即使是完整的）。
这里的关键是使它看起来不完整。完整的UI可以向许多业务用户发出信号，表明该应用程序已经完成（即使它只有几个静态页面，也没有背后的任何逻辑或内置于界面生成器中）。
进一步阅读（和文章链接）：
这取决于：您需要围绕最重要的功能进行紧密的反馈循环
如果您所做的工作的核心部分（风险和令人恐惧的部分）是某个内部引擎，则可以使核心部分（例如控制台）或通过单元测试工作。例如，协议解析器不需要UI即可知道其是否正常运行。
如果您的精彩事物涉及任何交互性（交互性，您需要不断地进行故障排除，丢弃和重新发现），那么UI优先方法至关重要。例如，我想构建一个应用程序以使人们与数据可视化进行交互。我需要弄清楚的最重要的事情是可视化是否有意义，因此在解决一个问题之前，我可能会放弃六种方法。在编写单个单元测试之前，我将先完成所有操作。
在这两者之间有一个模糊的灰色区域，您可以在其中决定如何最佳交互和验证代码的最佳组合（自动测试，实验UI）。我个人已经做到了极端，也做到了介于两者之间的一切，并且确定合适的位置是我必须决定的最困难的事情之一，并且100％取决于我要构建的事物的类型。
在敏捷环境中，您可能会听到有关“行走骨骼”或“薄垂直切片”的讨论。这样做的想法是，由于对用户而言重要的是有效的软件，因此您需要以一种有效的方式逐步构建软件。
在您提到的示例应用程序中，您将从窗口甚至一个选项卡开始，并使它们以某种方式从头到尾地工作。然后，随着时间的流逝，您将逐个添加功能，并因此逐个添加选项卡，从而使每个功能在构建时都可以使用。这是频繁的客户演示给您带来的一部分：一个展示新作品并立即获得反馈的机会。
简而言之，是的，如果您有UI，则UI工作绝对是功能工作单元的一部分。
从可行的小程序开始，然后迭代其功能以交付完整的软件。
我建议混合使用功能和UI（并尽快获得反馈或测试经验）。
顺便说一句，这不是大多数大型GUI软件的开发方式吗？以Firefox浏览器为例：从一个版本到另一个版本，功能和用户界面都得到了发展。
在我正在使用的大型（基于PHP Web的）应用程序中，我尝试首先获取适当的类和方法，这些类和方法返回伪值。这是为了建立其他开发人员可以用来实现UI的伪合同。
该方法的第二个优点是，即使在编写和交付所有代码之前，我们也可以随着UI需求的变化（并且总是变化）而磨练合同/界面。
我倾向于做的是从一个糟糕的UI开始：只是将变量数据转储到屏幕上。很长一段时间没有字体，没有对齐，实际上没有图形。只是“欢迎用户x”和称为“加载图片”的按钮等。这样做的好处是，您将发现后端中的某些内容是否损坏。
随着开发的进行，您可能会发现需要做的事情更多或更少。但是在某个阶段，您将确定后端即将完成。现在，您拥有一个包含所有所需附件的UI，并且您可以花费大量时间来做所有图形化工作。
但是要当心，这不是万无一失的。您需要先见之明才能看到某些问题。例如，您可能需要研究UI组件才能以明智的方式显示数据。
这取决于。您的要求定义得如何？UI面对多少系统？
根据我的经验，大多数客户直到看到前方的东西时才知道他们想要什么。因此，我通常会提供一些关键的UI方面的框架，或者提供大部分的UI（无效）。由于数据库设计和代码结构仍仅处于设计阶段，因此客户可以改变其主意，而不会受到太大影响，因为修改设计很容易。在项目中较早地更改设计，然后再进行更改，数量级更容易/更快。
敏捷声明您还应该首先处理最困难的项目和最重要的项目。快速失败。因此，一旦客户看到了UI，我便会专注于构建功能全面的小型组件，这些组件最重要且最难实现是首先实现，因此您会尽快知道是否遇到任何障碍。
然后，您便拥有了冲刺，并与客户在开发UI和功能方面的同时保持了持续的沟通。