在处理项目时，我经常遇到先处理UI还是先处理逻辑的两难境地。首先拥有UI可以很好地概述最终产品的外观，而首先拥有逻辑可以发现技术中的任何可能障碍。
然而，它并不总是那么清晰。。有时UI可能需要填充数据才能真正显示其含义，模拟数据可能比实现逻辑更困难。。你喜欢什么样的开发方法，为什么？哪个更高效？（我在iphone项目中越来越多地看到这个问题）
两者都没有。
无论如何，在项目开始时，你必须进行一些思考，决定你将采取的一般方法以及你将支持的操作。
如果做得相当好，您就会定义视图和底层逻辑之间的接口。从"模型-视图-控制器"方法中获得一些灵感。
您希望尽早了解逻辑代码需要执行哪些基本操作才能达到目的。通常这是一个简单的函数调用，但有时可能涉及更多。先把它弄清楚。
接下来，工作的复杂系统是基于工作的简单系统。
这意味着您将需要有一个基本的UI，用于首先测试基本的逻辑实现。一个简单的表单，带有一个显示消息的按钮，就足够基本了。然后，它可以增长，您可以实现一项功能，然后添加一个简单的UI来测试它。
由于逻辑和一小段逻辑的UI在概念上是相似的，因此可以更容易地逐个完成这两项工作，并且在实现和测试时可以很容易地跟踪两者。
最重要的部分是保持UI和逻辑的解耦，使它们通过一个公共接口进行对话。这将允许您在需要时进行快速编辑，并最终改善GUI的外观。
如果你不喜欢UI，你可以更好地废弃它。你所需要做的就是使用相同的界面，一个你知道如何做的界面，因为你写了它，并且已经实现了它。
如果在某个时候你意识到你犯了一个大错误，你仍然可以挽救部分代码，同样是因为UI和逻辑是解耦的，希望逻辑部分也足够模块化。
简言之：首先考虑，以小的增量完成UI和逻辑，并保持模块化。
在两者（逻辑和UI）之间迭代。来回地UI可能会随着您了解如何以及如何处理逻辑以及可能存在的任何约束而发生变化。逻辑可能会随着易于使用、响应迅速、外观美观的UI的功能、行为或性能要求的改变而改变。
我通常尽可能少地做每一个，直到我有一些勉强工作的模型。然后，我使用每个模型来测试我对正确的UI和/或逻辑的假设是对的还是错的。选择最有缺陷的，并开始迭代。
苹果建议先在纸上模仿用户界面。（手边有橡皮擦…）
如果可能，并行。
但就我个人而言，我主张逻辑至上。
我首先从基础知识开始，这意味着首先对逻辑进行编码并工作。这有两个原因：
- 如果我不能让逻辑正常工作，那么拥有一个漂亮的UI是无用的，也是浪费时间
- 当您处理逻辑方面时，很可能会更改UI，使UI过程更长、更昂贵
我通常先按顺序获取UI。原因是什么？当我制作不同设计的原型时，有时我对应用程序的想法会发生变化。如果是这样，那就没有后果了——没有代码可以重写。
然而，有时先了解基本原理，以确定应用程序是否可行是有帮助的。如果它不起作用，那么为什么要浪费时间制作接口呢？
我喜欢从用Vizio之类的东西来布置项目的不同部分开始。
我为我期望的不同观点制作方框，并在其中填充我期望包含的信息。
我为我期望的模型对象（逻辑）制作了另一组框。我用我希望他们能使用的信息填充它们，并在我认为必要的地方在模型和视图之间划清界限。
我对对象图（如果我计划使用CoreData）和数据库表（如果我要使用外部数据库）做同样的事情。
直观地列出所有内容有助于我判断是否缺少任何重要功能或项目组件之间的交互。如果我后来忘记了自己在做什么，这也给了我一些可以快速参考的东西。从那时起，我倾向于处理一个模型，直到它完成了足够的工作来填充视图的一部分，然后我处理一个视图，直到它可以与模型交互。
我还试图确定可以重复用于多种目的的视图或模型，这样我就可以减少我必须做的总工作量。
采取敏捷的方法，在迭代中处理少量的这两种方法。慢慢构建程序的每个功能部分，以免一次构建任何单片。