CLI应用程序的开发是否被视为“落后”？[关闭]

我是一名DBA初学者，在编程方面有很多经验。

我开发了几个CLI非交互应用程序，这些应用程序可以解决一些日常重复性任务，或者可以消除更复杂的人为错误，尽管不是日常任务。这些工具现在已成为我们工具箱的一部分。

我发现CLI应用程序很棒，因为您可以将它们包括在自动化的工作流程中。

同样，Unix的哲学是做一件事情但做得好，让一个进程的输出成为另一个进程的输入，这是构建一套工具的一种好方法，而不是巩固其战略优势。

我的老板最近评论说，开发CLI工具是“向后的”，或者构成“回归”。

我告诉他我不同意，因为现在存在的大多数CLI工具不是旧版，而是实时发布具有改进版本的实时项目。

这种发展是否被市场认为是“落后”的？

在简历上看起来不好吗？

我还考虑了所有解决方案，无论是Web还是台式机，都应具有命令行，非交互式选项。有人认为这是浪费编程资源。

这个目标在软件项目中是否值得实现？

我还认为，对于Web或桌面应用程序，具有备用CLI界面是证明业务逻辑与GUI完全脱钩的好方法。

具备使用CLI的能力几乎不会倒退。在履历表上看起来很棒，尤其是如果您可以在履历表上使用诸如“用过的（Powershell / Bash）来构建一套自动化工具来在数据库关闭时发送SMS消息”这样的短语时，将其旋转。

当我负责招聘人员时，我会寻找与CLI有关的工作知识。

基本上可以归结为“使用正确的工具完成工作”。

如果必须与用户交互，则需要某种GUI。我们已经有数十年的研究和经验表明，它们使计算更加直观和高效。这就是GUI自1984年以来就席卷全球的原因：它们在与人互动方面做得更好。

但是，如果要使用脚本使程序自动化，则程序不会与人互动。它与脚本进行交互。最好的界面是基于文本的界面，出于直观上显而易见的原因。

供用户直接使用的CLI程序的开发被认为是落后的，这是有充分理由的。但是，如果这不是您正在做的事情，或者您在编写自动化生产力工具，那么给它们提供CLI并不会做错任何事情。

埃里克·雷蒙德（Eric Raymond）的Unix编程艺术（The Art of Unix Programming）是您所提出论点的规范著作。我不会尝试将他的出色著作浓缩成两段。但是，请记住，论点主要适用于程序员，使用脚本自动执行任务的管理员或高级技术软件（如CAD）的高级用户。

即使是技术含量高的用户，您也必须考虑他们当时戴着哪些帽子。例如，我为网络设备编写嵌入式软件。我们的产品都具有CLI和GUI，但是由于其灵活性，可编写脚本性，可用性，速度等优势，开发人员几乎普遍都喜欢CLI。

但是，即使开发人员的CLI与GUI一样强大，并且支持和记录的文档也完全相同，因此，同一批开发人员绝对喜欢我们版本控制软件中的GUI。不同之处在于我们是版本控制软件的最终用户，而不是管理员或开发人员。

因此，请仔细考虑用户在使用实用程序时所扮演的角色，并相应地计划用户界面。如果您的老板提起它，则您至少有必要改善CLI的文档和/或培训。如果您经常告诉人们某个功能仅在他们期望GUI可用时才在CLI上可用，则您可能需要重新考虑开发优先级，从而更好地考虑用户的需求。

命令行程序驱动的不仅仅是Unix。微软也正朝着这个方向发展。

微软一直在推动PowerShell一段时间。可以通过PowerShell命令行完全控制其当前所有服务器软件（Exchange，SharePoint，Server 2012，System Center等）。而且PowerShell依靠小的功能可以很好地完成一件事情，然后将数据传递到下一个函数（尽管它传递对象而不是文本）。

这些程序的大多数GUI只是PowerShell命令的前端，许多GUI甚至告诉您将运行哪些命令以简化脚本编写。您可以从GUI进行的所有操作都可以从PowerShell中进行。反之则不成立-有很多仅在PowerShell中公开的功能。

因此，如果* nix一直做到这一点，而Microsoft正朝着这种方向发展...对我来说似乎并不倒退！

我绝对不会说这是一件坏事。CLI程序的好处是，在实施它们时，您的范围可能非常有限。例如，如果我想编写一个cat克隆或“一个将文件内容打印到屏幕上的程序”，那么使用CLI就是非常可行的。

但是，如果您不使用CLI，那您将拥有一个带有GUI的基本程序，该程序显示一些文本。但是，然后您还必须打开文件对话框并进行连接..然后，某个人还希望能够修改文本并将其保存在其他位置。

范围爬行对于GUI应用程序来说是荒谬的。使用CLI应用程序非常容易避免。“您要编辑文件然后重新保存吗？cat foo > ed > bar”使用CLI应用程序，将您的用户（不是您，开发人员）与其他工​​具结合起来很简单。

话虽如此，CLI程序开始被视为“后退”。这是因为这些天很多应用程序开发都发生在市场上，在这些市场上用户几乎不可能将您的工具与其他工具结合在一起。我不会在这里进行讨论，但是我确实写了一篇有关“市场如何实施无主心态” 的博客文章，这与精心设计的CLI应用程序完全相反（要做一件事并做得很好） ）

GUI和CLI都有它们的位置。GUI非常适合允许用户快速执行某些固定操作。CLI适用于您要执行GUI不允许您执行的操作。CLI通常更强大，更难使用。

一个良好的 CLI工具允许用户做的事情是谁写的工具的人从来没有想过的。一个示例是UNIX“查找”命令。该命令：

find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;

在当前目录下查找文件（但限于5级），文件名以“ xyzzy”开头，并在3天前进行了修改，然后将其删除（注意：未经测试的代码）。这是一个相当简单的用法。您可以使用文件管理器来执行此类操作，但是会花费更长的时间并且容易出错。当然，功能更强大意味着CLI可以更容易被滥用，并给您自己造成问题！

优秀的开发人员可能会以这样的方式编写CLI工具：它也具有允许执行一组有限操作的GUI。用户可以从GUI开始，稍后再学习CLI的复杂性。

在CLI / GUI折衷方案上的良好读（长而有偏见（？））是在：

http://www.cryptonomicon.com/beginning.html

不，一点也不落后。

“方向”与我们的观点有很大关系。用户对当前通向简单的“一站式体验所有设备”界面的当前路径感到满意的用户肯定会把CLI视为倒退或回归。这与他们的总体期望不符。

根据他们的经验，程序员，管理员或高级用户很可能将其视为工具的逻辑演进。其中许多开始使用GUI工具。当他们想要或需要扩展时，他们会迅速找出存在CLI的原因，并且这种进展会与构建更多CLI工具的人们产生共鸣。

保罗·费里斯（Paul Ferris）就是这样：http : //www.linuxplanet.com/linuxplanet/opinions/1505/1

就我个人而言，语法的概念将两者区分开。当GUI中存在某种语法时，结果几乎永远不会好，并且灵活性和经过深思熟虑的CLI语法一样。当它与管道和重定向一起使用时，由于在计划的用例之外它不是很有用，因此GUI变得平坦。

我对此的个人偏爱是CLI工具，该工具提供--gui或--verbose选项，足以使GUI包装器以健壮的方式进行交互，包括状态栏和其他人们希望GUI使用的基本元素。

当然，这样做的代价实际上是两个程序，一个程序没有另一个程序就毫无用处，但是最大的好处是能够将一个或多个出色的CLI工具合并到自定义GUI中，而无需修改所述CLI工具。通常，这样做只是为了在特定的CLI上提供GUI选项，但是使用一个面向“过程”或“用例”的GUI驱动多个工具的想法可以提供类似于对该用例进行管道化，重定向和脚本化的结果，使其可以提供给那些不会定期执行这些操作以达到精通的目的，同时又不妨碍CLI用户的人。

我在SGI IRIX上遇到了这种方法，并且非常喜欢它。我发现自己根据需要使用了GUI或命令行，而好消息是确切知道了花哨的按钮实际上在做什么。

在有许多不同的操作环境的地方，GUI包装器可以有很大不同，而不会影响CLI工具。

我今天在Linux中通过磁盘/文件系统工具看到了这一点，其中GUI甚至可以为熟悉CLI的用户增加很多价值。

对于已知的文件系统/磁盘/设备，敲除CLI并不困难，当然可以编写脚本。错误可能会很痛苦。

在那些可能不为人所知的地方，或者执行的操作不够定期以至于无法保持稳定和无错误，运行GUI提供了一个易于验证的环境，可以将操作链接在一起，然后放心地运行，而无需脚本。