您认为首先进行命令行开发怎么样？

Question

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

例如。

W:\ todo AddTask“与约翰会面，回复：登录同行评审》《约翰办公室》《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 每次都调用命令行程序。我同意那会非常令人讨厌。我本来打算（参见第一个附录）将所有这些都保存在一个可执行文件中，因为它是一个很小的示例，但我认为我的措辞不一定排除共享库。

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

Answer 1

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

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

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

Answer 2

将共享功能放入库中，然后为其编写命令行和 GUI 前端。这样你的图层转换就不会依赖于命令行。

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

Answer 3

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

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

Answer 4

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

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

Answer 5

我认为这取决于您正在开发什么类型的应用程序。为命令行进行设计可以让您快速实现 Alan Cooper 在书中所说的“实现模型” 囚犯们正在管理收容所. 。结果是用户界面不直观且难以使用。

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

Answer 6

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

这将使您的应用程序更适合脚本编写并限制前期费用 自行车停放 这样您就可以更快地找到实际的解决方案。

Answer 7

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

我不认为这种工作方式是良好 UI 的障碍 - 你仍然有时间添加一个并使之可用等。

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

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

Answer 8

@jcarrascal

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

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

Answer 9

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

我确实同意这样的观点，即您应该确保 GUI 易于使用且直观，因此同时开发两者可能是明智的......一个小的命令行功能，后跟一个 GUI 包装器，以确保您直观地做事。

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

Answer 10

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

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

Answer 11

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

Answer 12

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

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

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

Answer 13

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

Answer 14

我不会这样做有几个原因。

设计：

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

表现：

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

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

Answer 15

John Gruber 有一篇很好的文章，介绍了将 GUI 添加到并非专门设计的程序中的概念： Ronco 喷涂可用性

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

Answer 16

@莫迪特

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

还是一样的目标。我不认为命令行版本会影响 GUI 版本的质量。

Answer 17

编写一个作为 Web 服务公开的程序。然后使用 GUI 和命令行来调用相同的 Web 服务。这种方法还允许您制作 Web-GUI，并向外联网合作伙伴提供 SaaS 功能，和/或更好地保护业务逻辑。

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

对于网络服务，不要太过分。执行 yaml 或 xml-rpc。把事情简单化。

Answer 18

除了什么 斯图 也就是说，拥有共享库将允许您从 Web 应用程序中使用它。或者甚至来自 IDE 插件。

Answer 19

有几个原因可以解释为什么这样做不是一个好主意。其中很多已经提到了，所以我只坚持一个具体的观点。

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

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

现在你想在上面添加一个 GUI，你会做什么？解析长时间运行的命令行工具的输出？扫描该输出中的警告和错误以弹出对话框？

最好的情况是，大多数以这种方式构建的 UI 都会在命令运行期间显示一个脉动的忙碌条，然后在命令退出时向您显示成功或失败对话框。遗憾的是，这就是许多 UNIX GUI 程序组合在一起的方式，导致用户体验很糟糕。

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

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

Answer 20

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

如果您不关心 GUI，那就不用担心。如果最终结果是 gui，请先制作 gui，然后再制作命令行版本。或者你可以同时进行这两项工作。

--大量修改--

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

Answer 21

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

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

什么时候这是个好主意？

当您想要确保您的域实现独立于 GUI 框架时。你想要编码 大约 框架不 进入 框架

什么时候这是一个坏主意？

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