我们认为首先为命令行开发有什么想法？
对于首先开发命令行，然后通过简单地调用命令行方法在其上添加GUI，我们有什么看法？
例如。
W:\ todo AddTask "meeting with John, re: login peer review" "John's office" "2008-08-22" "14:00"
加载todo.exe并调用名为AddTask的函数，该函数进行一些验证并将会议扔到数据库中。
最终，我们为此添加了一个屏幕：
============================================================ Event: [meeting with John, re: login peer review] Location: [John's office] Date: [Fri. Aug. 22, 2008] Time: [ 2:00 PM] [Clear] [Submit] ============================================================
当我们单击提交时，它将调用相同的AddTask函数。
是否考虑：
- 编码的好方法
- 只为新手
- 太可怕了！
附录：
我在这里注意到"由GUI和CLI可执行文件调用的共享库"的趋势。除了二进制文件本身的大小之外，是否还有其他一些令人信服的理由为什么必须将它们分开？
为什么不以不同的方式调用同一可执行文件：
- 如果需要完整的图形界面，则使用" todo / G"
- " todo / I"在todo.exe中的交互式提示(脚本等)
- 当我们只想做一件事并用它完成时，它会显示普通的老式
" todo <function>"。
附录2：
提到"我描述事情的方式，我们每次需要GUI进行操作时都需要生成一个可执行文件。"
再次，这不是我的意图。当我提到示例GUI称为"相同的AddTask函数"时，我并不是说GUI每次都调用命令行程序。我同意那完全是令人讨厌的。我本来打算(请参阅第一个附录)将它们全部保存在一个可执行文件中，因为这只是一个很小的例子，但是我认为我的措辞不一定排除共享库。
另外，我还要感谢大家的投入。这是我不断想起的事情，我感谢经验。
解决方案
回答
将共享功能放入库中，然后为其编写命令行和GUI前端。这样，图层过渡就不会与命令行绑定。
(此外，这种方式还增加了另一个安全问题：GUI是否首先不必确保所调用的是正确的todo.exe？)
回答
Kinda取决于程序目标，但是，是的，我会不时这样做，这样可以更快地编写代码，更容易调试，并且更容易编写快速而肮脏的测试用例。只要我正确地构建代码结构，以后我就可以回头使用GUI，而无需进行过多工作。
对于那些暗示此技术将导致可怕的，无法使用的UI的人：我们是对的。编写命令行实用程序是设计GUI的一种糟糕方法。请注意，所有想编写不是CLUI的UI的人都不要将其原型化为CLUI。
但是，如果我们要编写的新代码本身并不依赖于UI，那么就去吧。
回答
Joel写了一篇文章，将这种(" unix样式")开发与GUI的第一种(" Windows样式")方法进行了对比。他称其为"双文化主义"。
我认为在Windows上，将逻辑包装到.NET程序集(如果尚未打包)将变得很正常，然后可以从GUI和PowerShell提供程序进行访问。这样一来，我们可以两全其美。
回答
最好先从命令行开始，以确保我们具有正确的功能。如果主要用户不能(或者不会)使用命令行，则可以在工作之上添加GUI。
这将使应用程序更适合脚本编写，并限制了前期Bikeshedding的数量，因此我们可以更快地找到实际的解决方案。
回答
如果我们打算保留应用程序的命令行版本，那么这样做不会出现问题，这不会浪费时间。我们仍将最终为命令行编写应用程序的主要功能，因此我们将完成大部分工作。
我认为以这种方式工作不会成为良好UI的障碍，我们仍然有时间添加一个UI并使其可用。
我猜想这种工作方式只有在我们打算让完成的应用程序同时具有命令行和GUI变体的情况下才会真正起作用。模拟用户界面并在其中构建功能，然后稍后美化用户界面非常容易。
同意Stu：基本功能应在从命令行和GUI代码调用的库中。在运行时从UI调用可执行文件是不必要的开销。
回答
@jcarrascal
我不明白为什么这会使GUI变得"糟糕"？
我的想法是，这将迫使我们考虑"业务"逻辑实际上需要完成的事情，而不必过多担心事物的美观。一旦知道了它应该/可以做什么，就可以以最有意义的任何方式围绕它构建界面。
旁注：不是要开始一个单独的主题，而是解决问题的答案/评论的首选方法是什么？我考虑了这两个问题，并编辑了问题本身。
回答
我认为这取决于我们开发的应用程序类型。通过命令行设计，我们可以快速了解Alan Cooper在《囚犯正在庇护》中所说的"实施模型"。结果是用户界面不直观且难以使用。
37signals还提倡在Getting Real中首先设计用户界面。请记住，出于所有意图和目的，在大多数应用程序中，用户界面都是程序。后端代码就可以支持它。
回答
我正是使用编写的一种工具完成了此任务，并且效果很好。最终结果是一个可编写脚本的工具，该工具也可以通过GUI使用。
我确实同意我们应该确保GUI易于使用和直观的观点，因此，甚至同时开发这两者可能是明智的。直观地
如果我们确实希望同时实现这两者，那么结果就是可以自动使用的应用程序，我认为这对于高级用户而言非常强大。
回答
命令行工具生成的事件少于GUI应用程序，并且通常在启动之前检查所有参数。这将限制gui，因为对于gui而言，在程序运行时或者之后请求参数可能更有意义。
如果我们不关心GUI，则不必担心。如果最终结果是gui，请先创建gui，然后再执行命令行版本。或者，我们可以同时工作。
-大量编辑-
花了一些时间在我当前的项目上之后，我感觉好像我从以前的回答中走了出来。我认为最好先执行命令行，然后在其上包装一个GUI。如果我们需要的话，我认为我们以后可以做一个不错的GUI。通过首先执行命令行，我们首先要降低所有参数，因此在执行UI / UX时不会感到意外(直到需求更改)。
回答
@Maudite
命令行应用程序将预先检查参数，而GUI不会，但是它们仍将检查相同的参数并将其输入到某些通用辅助函数中。
仍然是相同的目标。我看不到命令行版本会影响GUI的质量。
回答
首先，我不需要使用明确的UI即可对后端功能进行编程的技术(特别是在UI尚未完成时，例如，我正在设计仍处于设计阶段的Web应用程序)是编写单元测试。
这样，我什至无需编写控制台应用程序即可模拟后端代码的输出-全部在测试中，而且与控制台应用程序不同，我不必丢弃测试代码，因为它们仍然是以后有用。
回答
我通常从一个类库和一个单独的，非常糟糕的基本GUI开始。由于命令行涉及解析命令行，因此我感觉到我增加了很多不必要的开销。
作为奖励，这提供了一种类似于MVC的方法，因为所有"真实"代码都在类库中。当然，在以后的阶段，将库和真实的GUI一起重构到一个EXE中也是一种选择。
回答
如果我们正确地进行开发，那么稍后在项目中切换到GUI应该相对容易。问题在于，很难正确地做到这一点。
回答
John Gruber撰写了一篇很好的文章，内容涉及将GUI添加到非特定程序的概念：Ronco Spray-On可用性
摘要：它不起作用。如果从一开始就没有在应用程序中设计可用性，那么在以后添加它的工作量比任何人都愿意。
回答
做一个我们公开为网络服务的程序。然后执行gui和命令行以调用相同的Web服务。这种方法还使我们可以制作Web GUI，还可以将SaaS作为SaaS的功能提供给Extranet合作伙伴，和/或者更好地保护业务逻辑。
这也使程序可以更轻松地参与SOA环境。
对于网络服务，请不要太过分。做yaml或者xml-rpc。把事情简单化。
回答
更好的方法可能是使用定义良好的API将逻辑开发为一个库，并且在开发阶段不使用任何接口(或者硬编码接口)，则可以稍后修改CLI或者GUI
回答
我会用一个链接到它的命令行应用程序来构建一个库。之后，我们可以创建链接到相同库的GUI。从GUI调用命令行会产生每个命令的外部进程，并且对操作系统更具破坏性。
此外，使用库，我们可以轻松地对该功能进行单元测试。
但是，即使功能代码与命令行解释器是分开的，我们也可以仅将GUI的源代码重用，而无需一次执行两种操作。
回答
除了Stu所说的之外，拥有共享库也将使我们也可以从Web应用程序中使用它。甚至来自IDE插件。
回答
由于某些原因，我不会这样做。
设计：
GUI和CLI是用于访问基础实现的两个不同接口。它们通常用于不同的目的(GUI用于实时用户，CLI通常通过脚本访问)，并且通常可能具有不同的要求。将两者耦合在一起不是一个明智的选择，并且势必会给我们带来麻烦。
表现：
按照我们描述事物的方式，每次GUI需要执行某些操作时，都需要生成一个可执行文件。这真是丑陋。
正确的方法是将实现放入CLI和GUI都调用的库中。
回答
有多种原因导致这样做不是一个好主意。其中提到了很多，所以我只坚持一个特定的观点。
命令行工具通常根本不交互式，而GUI则完全不交互式。这是根本的区别。例如，这对于长时间运行的任务很痛苦。
命令行工具充其量只能输出某种进度信息换行符，文本进度条，一堆输出，...任何类型的错误只能输出到控制台。
现在，我们想在其上拍一个GUI，该怎么办？解析我们长期运行的命令行工具的输出？在该输出中扫描"警告"和"错误"以抛出一个对话框？
充其量，大多数UI都是以这种方式构建的，只要命令运行，它就会抛出一个脉动的忙碌状态栏，然后在命令退出时向我们显示成功或者失败对话框。可悲的是，这就是将许多UNIX GUI程序组合在一起的方式，这使其成为了糟糕的用户体验。
这里的大多数答复者都正确地说，我们应该将程序的实际功能抽象到一个库中，然后同时为其编写命令行界面和GUI。我们所有的业务逻辑都应该在库中，并且任何一个UI(是的，命令行是UI)都应该仅执行在业务逻辑和UI之间进行接口所需的任何操作。
命令行对于UI来说太差了，以至于不能确保我们开发的库足够好以供GUI使用。我们应该从一开始就开始，或者从GUI编程开始。向为GUI开发的库中添加命令行界面很容易，但是反之则困难得多，这正是因为GUI需要所有交互功能(报告，进度，错误对话框，i18n等)。 )
