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

Question

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

例如。

W：\\ todo AddTask“与John会面，re：登录同行评审”“John的办公室”“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

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

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

Answer 4

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

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

Answer 5

我认为这取决于您正在开发的应用程序类型。 设计命令行可让您快速了解Alan Cooper在“囚犯正在运行庇护 ”中所称的“实施模型”。 结果是用户界面不直观且难以使用。

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

Answer 6

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

这将使您的应用程序更适合脚本编写以及限制前期Bikeshedding的数量，以便您可以更快地获得实际的解决方案。

Answer 7

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

我不认为这样做是一个很好的用户界面的障碍 - 你还有时间添加一个并且make是可用的等等。

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

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

Answer 8

@jcarrascal

我不明白为什么这会让GUI“坏”？
我的想法是，它会迫使你去思考“商业”逻辑究竟需要完成什么，而不必担心过于漂亮的东西。 一旦你知道它应该/可以做什么，你就可以以最有意义的方式构建你的界面。

附注：不要开始单独的主题，但是对于问题的答案/评论的首选方法是什么？ 我考虑过这个，并编辑问题本身。

Answer 9

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

我同意你应该确保GUI易于使用和直观易用的观点，所以甚至可以同时开发两者......一点点命令行功能，然后是GUI包装器以确保你正在做事情直观。

如果你真的同时实现两者，结果是一个可以自动使用的应用程序，我认为这对高级用户来说非常强大。

Answer 10

有点取决于你的程序目标，但是我不时这样做 - 编写代码更快，更容易调试，更容易编写快速和脏的测试用例。 只要我正确地构建我的代码，我就可以在没有太多工作的情况下返回并在以后使用GUI。

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

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

Answer 11

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

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

Answer 12

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

Answer 13

John Gruber有一篇关于为不是为一个程序设计的程序添加GUI的概念： Ronco Spray-On Usability

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

Answer 14

一个更好的方法可能是将逻辑开发为具有良好定义的API的lib，并且在开发阶段，没有接口（或硬编码接口），那么您可以稍后调用CLI或GUI

Answer 15

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

设计：

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

性能：

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

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

Answer 16

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

\n

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

- 大量编辑 -

花了一些时间在我目前的项目上后，我觉得好像我已经完成了我之前的答案。 我认为最好首先执行命令行，然后在其上包装一个gui。 如果你需要的话，我想你可以在之后成为一个伟大的gui。 首先执行命令行，首先获取所有参数，这样在执行UI / UX时就不会出现任何意外（直到需求发生变化）。

Answer 17

@Maudite

命令行应用程序将检查前面的参数并且GUI不会 - 但他们仍将检查相同的参数并将它们输入到一些通用工作器函数中。

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

Answer 18

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

这也使您的程序更容易参与SOA环境。

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

Answer 19

除了Stu所说的，拥有共享库还允许您从Web应用程序中使用它。 甚至是IDE插件。

Answer 20

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

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

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

现在你要打一个GUI，你做什么？ 解析长时间运行的命令行工具的输出？ 在该输出中扫描WARNING和ERROR以打开一个对话框？

充其量，大多数UI以这种方式构建，只要命令运行就会抛出一个脉动繁忙的条，然后在命令退出时显示成功或失败对话框。 遗憾的是，这就是许多UNIX GUI程序被抛在一起的方式，这使得它成为一种糟糕的用户体验。

这里的大多数回复者都说你应该将程序的实际功能抽象到库中，然后同时编写命令行界面和GUI。 您的所有业务逻辑都应该在您的库中，并且UI（是的，命令行是UI）应该只执行业务逻辑和UI之间的接口。

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

Answer 21

这正是我关于编码的最重要的实现之一，我希望更多的人会采取这种方法。

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

什么时候这是个好主意？

当您想确保您的域实现独立于GUI框架时。 要围绕框架没有代码到框架

什么时候这是个坏主意？

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