您如何看待首先为命令行开发？答案

【问题标题】：What do you think of developing for the command line first?您如何看待首先为命令行开发？
【发布时间】：2010-09-06 08:20:26
【问题描述】：

您对先开发命令行，然后通过简单地调用命令行方法添加 GUI 有何看法？

例如。

W:\ todo AddTask "与 John 会面，re: login peer review" "John's office" "2008-08-22" "14:00"

加载todo.exe 并调用一个名为AddTask 的函数，该函数进行一些验证并将会议放入数据库中。

最终你为此添加了一个屏幕：

================================================== ========== 事件：[与约翰会面，回复：登录同行评审] 地点：[约翰的办公室] 日期：[星期五。 2008 年 8 月 22 日] 时间：[下午 2:00] [清除] [提交] ================================================== ==========

当你点击提交时，它会调用相同的 AddTask 函数。

是否考虑过：

编码的好方法
仅供新手使用
太可怕了！。

附录：

我注意到这里的趋势是“由 GUI 和 CLI 可执行文件调用的共享库”。除了二进制文件本身的大小之外，是否有一些令人信服的理由必须将它们分开？

为什么不以不同的方式调用同一个可执行文件：

"todo /G" 当您想要完整的图形界面时
"todo /I" 用于交互式提示内 todo.exe（脚本等）
当你只想做一件事并完成它时，普通的旧 "todo <function>"。

附录 2：

有人提到“按照 [我] 描述事物的方式，您 [将] 需要在每次 GUI 需要执行某些操作时生成一个可执行文件。”

再说一次，这不是我的本意。当我提到示例 GUI 调用“相同的AddTask 函数”时，我并不是指 GUI 每次都调用命令行程序。我同意那将是非常讨厌的。我原本打算（见第一个附录）将所有这些都保存在一个可执行文件中，因为它只是一个小例子，但我认为我的措辞不一定排除共享库。

另外，我要感谢大家的意见。这件事一直在我脑海中浮现，我很欣赏你的经验。

【问题讨论】：

在 Windows 中，您可以将可执行文件标记为控制台程序或 gui。您不能同时启用两者。
大部分是真的。但是 CLI 应用程序可以充当另一个 GUI 应用程序的包装器。如果 CLI 应用程序没有传递 /G 标志，则 GUI 应用程序根本不会创建窗口。有关类似示例，请参见 MsDev.com/.exe

标签： language-agnostic command-line

【解决方案1】：

这正是我对编码最重要的认识之一，我希望更多的人会采用这种方法。

只是一个小说明：GUI 不应该是命令行的包装器。相反，应该能够从 GUI 或命令行驱动程序的核心。至少在开始时只是基本操作。

什么时候是个好主意？

当您想确保您的域实现独立于 GUI 框架时。你想围绕框架而不是进入框架

什么时候这是个坏主意？

当你确定你的框架永远不会死时

【讨论】：

【解决方案2】：

命令行工具生成的事件少于 GUI 应用程序，并且通常在启动前检查所有参数。这将限制您的 gui，因为对于 gui，在程序运行时或之后请求参数可能更有意义。

如果您不关心 GUI，请不要担心。如果最终结果是 gui，请先制作 gui，然后再制作命令行版本。或者您可以同时处理这两个问题。

--大量编辑--

在我当前的项目上花了一些时间之后，我觉得我好像从之前的回答中走出来了。我认为最好先执行命令行，然后在其上包装 gui。如果你需要，我认为你可以在之后制作一个很棒的 gui。通过首先执行命令行，您首先获取所有参数，因此在执行 UI/UX 时不会有任何意外（直到需求发生变化）。

【讨论】：

【解决方案3】：

John Gruber 有一篇关于将 GUI 添加到并非专为某人设计的程序的概念的好帖子：Ronco Spray-On Usability

总结：它不起作用。如果从一开始就没有将可用性设计到应用程序中，那么以后添加它比任何人都愿意做的工作要多。

【讨论】：

【解决方案4】：

这样做不是一个好主意有几个原因。已经提到了很多，所以我只坚持一个具体点。

命令行工具通常根本不是交互式的，而 GUI 是。这是一个根本的区别。例如，这对于长时间运行的任务来说是很痛苦的。

您的命令行工具最多只能打印出某种进度信息 - 换行符、文本进度条、一堆输出……任何类型的错误都只能输出到控制台。

现在你想在上面添加一个 GUI，你会怎么做？解析长期运行的命令行工具的输出？扫描该输出中的 WARNING 和 ERROR 以弹出对话框？

充其量，大多数以这种方式构建的 UI 都会在命令运行时抛出一个脉动的忙碌条，然后在命令退出时显示成功或失败对话框。遗憾的是，许多 UNIX GUI 程序就是这样拼凑在一起的，这给用户带来了糟糕的体验。

这里的大多数回复都是正确的，您可能应该将程序的实际功能抽象到一个库中，然后同时为它编写一个命令行界面和 GUI。您的所有业务逻辑都应该在您的库中，并且任何一个 UI（是的，命令行就是一个 UI）应该只执行您的业务逻辑和 UI 之间的接口所需的任何操作。

命令行界面太差，无法确保您开发的库足够好，以便以后使用 GUI。您应该从一开始就开始，或者从 GUI 编程开始。将命令行界面添加到为 GUI 开发的库中很容易，但反过来就困难得多，这正是因为 GUI 需要的所有交互功能（报告、进度、错误对话框、i18n、... )

【讨论】：

【解决方案5】：

出于几个原因，我不会这样做。

设计：

GUI 和 CLI 是用于访问底层实现的两个不同接口。它们通常用于不同的目的（GUI 用于实时用户，CLI 通常通过脚本访问）并且通常具有不同的要求。将两者结合起来不是一个明智的选择，而且必然会给您带来麻烦。

性能：

按照您描述的方式，每次 GUI 需要执行某些操作时，您都需要生成一个可执行文件。这简直丑陋。

执行此操作的正确方法是将实现放入由 CLI 和 GUI 调用的库中。

【讨论】：

【解决方案6】：

除了Stu 所说的之外，拥有一个共享库还可以让您在 Web 应用程序中使用它。甚至来自 IDE 插件。

【讨论】：

【解决方案7】：

我会构建一个带有链接到它的命令行应用程序的库。之后，您可以创建一个链接到同一个库的 GUI。从 GUI 调用命令行会为每个命令生成外部进程，并且对操作系统的破坏性更大。

此外，借助库，您可以轻松地对功能进行单元测试。

但即使您的功能代码与命令行解释器是分开的，您也可以将源代码重新用于 GUI，而无需同时使用这两种代码来执行操作。

【讨论】：

【解决方案8】：

更好的方法可能是将逻辑开发为具有明确定义的 API 的库，并且在开发阶段没有接口（或硬编码接口），然后您可以稍后编写 CLI 或 GUI

【讨论】：

【解决方案9】：

有点取决于您对程序的目标，但是我不时这样做 - 编码更快，更容易调试，并且更容易编写快速而肮脏的测试用例。只要我正确地构建了我的代码，我就可以稍后返回并添加一个 GUI，而无需太多工作。

对于那些认为这种技术会导致可怕的、无法使用的 UI 的人：你是对的。编写命令行实用程序是设计 GUI 的一种糟糕方式。请注意，每个人都在考虑编写一个不是 CLUI 的 UI - 不要将其原型化为 CLUI。

但是，如果您正在编写本身不依赖于 UI 的新代码，那就去做吧。

【讨论】：

【解决方案10】：

做一个你公开为网络服务的程序。然后执行 gui 和命令行来调用相同的 web 服务。这种方法还允许您制作 web-gui，还可以将功能作为 SaaS 提供给外联网合作伙伴，和/或更好地保护业务逻辑。

这还允许您的程序更轻松地参与 SOA 环境。

对于网络服务，不要太过分。做 yaml 或 xml-rpc。保持简单。

【讨论】：

【解决方案11】：

如果您的开发正确，那么稍后在项目中切换到 GUI 应该相对容易。问题是要做到这一点有点困难。

【讨论】：

【解决方案12】：

我通常从一个类库和一个单独的、非常糟糕的基本 GUI 开始。由于命令行涉及解析命令行，我觉得我增加了很多不必要的开销。

作为奖励，这提供了一种类似于 MVC 的方法，因为所有“真实”代码都在类库中。当然，在后期，将库与真正的 GUI 一起重构为一个 EXE 也是一种选择。

【讨论】：

【解决方案13】：

我在不需要显式 UI 的情况下首先编写后端功能的技术（尤其是当 UI 不是我的工作时，例如，我正在设计一个仍处于设计阶段的 Web 应用程序）是编写单元测试。

这样，我什至不需要编写控制台应用程序来模拟我的后端代码的输出——这一切都在测试中，而且与您的控制台应用程序不同，我不必将测试代码扔掉因为它们以后仍然有用。

【讨论】：

【解决方案14】：

@Maudite

命令行应用程序会预先检查参数，而 GUI 不会 - 但他们仍会检查相同参数并将它们输入到一些通用工作函数中。

还是同一个目标。我没有看到影响 GUI 质量的命令行版本。

【讨论】：

【解决方案15】：

我正是在我编写的一个工具上做到了这一点，而且效果很好。最终结果是一个可编写脚本的工具，也可以通过 GUI 使用。

我同意您应该确保 GUI 易于使用且直观的观点，因此甚至同时开发两者可能是明智之举......一个小的命令行功能，然后是一个 GUI 包装器，以确保你是在直觉地做事。

如果你真的要平等地实现两者，那么结果就是可以以自动化方式使用的应用程序，我认为这对于高级用户来说非常强大。

【讨论】：

【解决方案16】：

我认为这取决于您正在开发的应用程序类型。为命令行进行设计可以让您快速了解 Alan Cooper 在The Inmates are Running the Asylum 中所说的“实施模型”。结果是用户界面不直观且难以使用。

37signals 还提倡在Getting Real 中首先设计您的用户界面。请记住，出于所有意图和目的，在大多数应用程序中，用户界面就是程序。后端代码只是为了支持它。

【讨论】：

【解决方案17】：

@jcarrascal

我不明白为什么这会让 GUI “变坏”？
我的想法是，它会迫使您考虑“业务”逻辑实际上需要完成什么，而不必过多担心事情是否漂亮。一旦你知道它应该/可以做什么，你就可以以任何最有意义的方式围绕它构建你的界面。

旁注：不是要开始一个单独的主题，而是解决您的问题的答案/cmets 的首选方式是什么？我考虑了这一点，并编辑了问题本身。

【讨论】：

【解决方案18】：

如果您打算保留应用程序的命令行版本，那么我认为这样做没有问题 - 这不会浪费时间。您最终仍会为命令行编写应用程序的主要功能，因此您将完成大量工作。

我不认为以这种方式工作会阻碍良好的 UI - 您仍然有时间添加一个并使其可用等。

我想这种工作方式只有在您打算让您的完成的应用程序同时具有命令行和 GUI 变体时才真正有效。模拟 UI 并将您的功能构建到其中然后美化 UI 很容易。

同意 Stu：您的基本功能应该位于从命令行和 GUI 代码调用的库中。在运行时从 UI 调用可执行文件是不必要的开销。

【讨论】：

【解决方案19】：

最好先从命令行开始，以确保功能正确。如果您的主要用户不能（或不会）使用命令行，那么您可以在您的工作之上添加一个 GUI。

这将使您的应用更适合编写脚本并限制预先Bikeshedding 的数量，因此您可以更快地获得实际解决方案。

【讨论】：

【解决方案20】：

几年前，Joel 写了一篇文章，将这种（“unix 风格”）开发与 GUI 优先（“Windows 风格”）方法进行了对比。他称之为Biculturalism。

我认为在 Windows 上将您的逻辑包装到 .NET 程序集中（如果还没有的话）将变得很正常，然后您可以从 GUI 和 PowerShell 提供程序访问这些程序集。这样您就可以两全其美。

【讨论】：

【解决方案21】：

将共享功能放入库中，然后为其编写命令行和 GUI 前端。这样一来，您的图层转换就不会绑定到命令行。

（此外，这种方式增加了另一个安全问题：GUI 不应该首先确保它是被调用的正确的 todo.exe 吗？）

【讨论】：