面向CLI的程序员的工作流程与面向GUI的工作流程有何不同？

我已经听到很多关于在GUI应用程序中减少编程工作并使用更多命令行工具（尤其是在更高效地完成工作方面）的好处的信息。但是，由于我不了解如果我更多地依赖命令行工具，那么我的工作流程会有什么不同，所以我无法轻易评估个人是否有足够的回报来投入时间和精力来学习新的工具集并进行更改我的工作流程。

马上：

• 我使用Visual Studio，Eclipse等使用C / C ++ / D / C＃/ Java / Python等语言编写了一些辅助项目，并通过设置构建设置并按F5进行构建/运行来运行它们。

• 我正在开发一个工作中的Web程序，因此涉及使用Django设置服务器，连接到数据库等，几乎所有这些操作都在SciTE文本编辑器中进行。

• 对于启动常规程序，我使用Launchy ...仍然没有终端。:)

• 对于复制文件和其他操作，我在图形文件管理器（Windows资源管理器，Nautilus）中使用常规查找/移动。

• 调试：我使用Visual Studio或Windows调试工具（如果我在Windows上）。我在Linux上没有做太多调试，但是对于已经完成的事情，我使用了Eclipse（对于Windows上的Java也是如此）。

• 工作：连接到构建系统并建立项目，我只使用已集成到Eclipse中的工具供我使用-不需要终端或任何东西（尽管我当然欢迎使用终端，确实想）

在CLI中执行这些操作是什么感觉？哪些零件效率更高/更低？从转变为主要使用CLI来获得最大的优势，需要更改工作流程的哪些方面？换句话说... 如果您将我神奇地转变为命令行专家，那么我的新编码工作流程将与当前以GUI为中心的工作方式有何不同？

我认为这不再是真的。CLI具有一个特殊的优势-如果您事先知道要查找的内容，则键入它的速度将比在菜单中导航到它的速度快。这意味着，如果您要明确地向几乎没有上下文的程序发出命令，那么它通常会更快。但是，有两个问题。

首先，GUI程序可以为您推断上下文。例如，Visual Studio的“转到定义”功能和Intellisense。您如何在CLI中复制这些功能？

其次，GUI程序可以向您显示更多信息。例如，Visual Studio Parallel Profiler，它是随时间推移跨多个内核的CPU使用率的图表。您如何在CLI中显示它？只是没有意义。一旦将您的数据更好地表达为文本以外的其他形式，CLI就会立即丢失。另一个简单的例子是断点。在Visual Studio中，单击要折断的行的边距。您将在CLI中做什么，尝试查找文件和行号并输入该命令？那将花费您相对的十年。甚至还没有包括一些新的GUI创新，例如Debugger Canvas。

如果您想花一遍又一遍地推动Debug，GUI可能会变慢，但是一旦用例变得更加复杂，CLI就无法跟上。

我认为最大的区别不在于个人任务，而在于两件事：

首先，自动化。CLI具有固有的脚本编写能力，通常在Windows上较难。我听说使用PowerShell可以使事情有所改善，但是我还没有使用过。

第二，UNIX的“关注点分离”哲学。我可以编写一个基于readline的小型界面，并使用emacs Mx shell在emacs GUI中使用它。这样可以更轻松地利用其他工具和现有功能。

对于调试gdb效果很好，但我通常更喜欢VS调试器。它可能是微软做过的最好的软件。

对于构建和运行事物：制造。或重击。无论在哪里

用于开发：emacs（最近从vi转换，哦，真可惜！）。如果通过ssh进行工作，则为vi。

我真的不习惯Eclipse。我认为这是一个“思想形态”问题：它不适合我的情况。

对我而言，从Visual Studio切换到CLI工作流涉及记忆许多* nix命令。每当我弄乱SVN签到时，也会有些头痛。

但是对我来说，工作流程的最大不同是，我对操作系统的工作方式有了更好的了解。使用GUI工作流，只需单击按钮并等待程序响应即可。在命令行世界中，我觉得我是在直接告诉计算机做某事。

换句话说，GUI工作流程是计算机与您进行通信，而CLI工作流程似乎更像是您直接与计算机进行通信。

一个并不比另一个更好，但是从完全基于GUI的环境切换到终端绝对是一个旅程。

这是来自生活在两个世界中的程序员的更多观察结果。我不会重复其他答案中已经提出的观点：

基于CLI的开发倾向于使用各种程序，每个程序执行一项功能。基于GUI的开发倾向于使用1个大程序（IDE），该程序执行许多不同的功能。这一差异产生了以下几种后果：

因为IDE旨在成为您始终工作的“家”，所以它们可能使用专有的（也许是二进制的）格式来保存您的数据。兼容性不是大问题，因为他们不希望您在同一项目中使用2个不同的IDE。另一方面，CLI工具通常只适用于纯文本文件。

通过基于CLI的开发，您可以更轻松地逐步切换工具或将新工具集成到工作流中。选择一个IDE要么全有要么全无，而切换IDE则更痛苦。

使用CLI构建脚本而不是IDE的内置“构建”菜单，使您更有可能离开代码几年，回到原来的代码，而不必大惊小怪。通过基于GUI的开发，到那时您可能正在运行完全不同的IDE。也许您编写代码时使用的代码甚至无法在当前的操作系统上运行。

在IDE中，构建自己的工具意味着学习（可能很大）插件API，并且可能使用特定的语言。使用CLI时，制作自定义工具不需要任何特殊的操作。

另一方面，IDE的优势在于它是“集成的”。因此，您可以在编辑器窗口中单击以设置调试器断点，依此类推。

另一点：您的选择还取决于您使用的开发平台，操作系统和语言。在某些平台上，基于IDE的开发已深深扎根于流行的开发文化中。在其他情况下，基于CLI的开发非常普遍。如果使用的平台盛行基于IDE的开发，则CLI工​​具可能会开发不佳且支持不佳。反之亦然。

我的大部分童年都没有花在计算机上，因为我们甚至在农场上都没有互联网。我在高中后期开始编程，基本上一直都在使用GUI。在大学里，我遇到了一个在CLI上长大的家伙，并以这种方式做了所有事情。因此，我决定设置一个Linux服务器，而不是听教授的话。几年后，我的伙伴看着我写了一些嵌入式代码，简直不敢相信我的写法。

我基本上使用一半的CLI和一半的GUI。GUI捆绑环境在某些方面可以更快，更高效地完成工作。CLI也是如此。我的大部分文本编辑都是在VIM中完成的，因为高级CLI编辑器VIM / EMACS（请不要打招呼）使文本处理最有效。另一方面，使用GDB进行嵌入式调试之类的事情就像没有键盘编辑文本一样痛苦。确保其功能强大且有足够的时间，您会找到所需的信息，但是拥有一个可即时访问任何内存块的漂亮GUI窗口非常宝贵，尤其是在尝试将其与另一个内存块进行比较时。

无论如何，我真正想说的是，它不应该是GUI vs CLI，而应该是CLI的优势和GUI的优势。因为最后，如果您的IO比您的思考过程慢，那就有问题了。

“一夜之间变成了CLI专家吗？” 是的，有摩擦。设计良好的GUI往往比CLI更容易发现，并且对新手更宽容。

最近通过平铺窗口管理器（dwm）增强了我的工作流程，其中包含许多键入操作。现在，我的笔记本电脑实际上无需插入鼠标就可以使用（触控板足以应付剩下的指示）。我保持许多应用程序打开并使用alt-tab进行切换。我不会浪费时间移动和调整窗口大小。

大多数时候，我使用浏览器，vim和许多终端。SSH为我（实际）在哪里工作提供了很大的灵活性。当我们所有人都拥有10G管道时，远程桌面可能会提供更好的体验，但是我不会屏息。

我对vim的了解还不够充分，无法利用它的复杂功能，但我倾向于这个方向-我想让vim在制作失败后跳到正确的位置。（从技术上讲，vim是可视界面，即使它在终端中运行，但我使用键盘而不是鼠标来驱动它。）

真正的问题是接口设计不良。设计良好的界面很难创建，因此在任何一个阵营中都很少发生。但是，由于今天设计GUI的非ux-wizard超过了CLI，因此....

（我最大的烦恼是膨胀。当需要19MB程序来帮助我完成与200kB程序相同的任务时，出了点问题。用于DOS的XTree Gold比任何现代文件管理器都提高了我的生产率。Windows 2.11仅使用了平铺Windows。TurboC是一个很棒的IDE。为什么我的Nook似乎比Mac classic运行的慢？为什么现在仅内核占用的磁盘空间就比整个系统占用的磁盘空间还大？​​）

使用图形用户界面，您不得不反复与程序进行交互，以一次又一次地执行相同的操作。使用外壳，您可以更轻松地使事情自动化，并使程序通过管道一起工作–例如，可以用于将匹配结果输出到一组文件或网络数据包中的正则表达式。如前所述，它对于许多操作来说速度更快。

除非您使用SSH，否则在终端上进行编程可能不会比在图形编辑器中进行编程更好。

我个人发现，unix shell比典型的Windows命令行更易于使用，并且现在非常沉浸在具有平铺窗口管理器和大量终端的Linux系统上。

您所有的示例几乎都是一步一步的过程。在大多数GUI环境中，如果要移动与您当前所在的应用程序无关的文件，则可以从文件菜单中执行操作而无需离开该应用程序。没有意义去命令提示符。如果要复制文件并给它起一个不同的名称，则可以在命令行上一次完成所有操作。要将其放入批处理文件中，您至少需要知道如何执行此操作，但是如果需要，则可以从GUI执行该批处理文件。

关于键盘命令和鼠标，我也有类似的争论。

我的工作方式到目前为止都偏爱GUI。

典型用法：

• 用于三个不同平台的三个IDE。还有一些脚本的Notepad ++窗口。我根本无法记住所有这些构建系统的命令。CLI的问题在于，您需要了解许多详细信息才能使构建正常工作。默认情况下，现代IDES通常在其中具有一些适当的选项。当时间到来时，您始终可以仔细查看。
• 集成了SVN或Git。辅助编程的程序有很多选择，大多数时候我只是在进行提交或更新。
• 网络内容：幸运的是，我也可以在办公室进行所有网络设置。大多数网络板都会为您提供大量CLI命令，但是如果您需要一件事来概述状态，那就是防火​​墙和路由。对于路由，我只能使用命令行，但是防火墙变得很复杂，如果有一件事情，GUI擅长显示很多信息。
• 通常，从一件事到另一件事有很多转移。通过视觉上下文更容易进行上下文切换。

至于CLI和脚本编写的主要好处，我几乎从未这样做过。我们拥有的重复任务只是cron作业应用程序，我们已经在c＃中将它们放在一起，并且不经常更改。我们确实有办法使事情在Linux上运行，但主要是移植（提升）的功能，因此使文件混乱和此类事情的发生率降至最低。如果事情变得繁琐，那么也有适用于Linux的优秀IDE。