Считается ли разработка приложений CLI «отсталой»? [закрыто]

38

Я адвокат с большим опытом программирования.

Я разработал несколько CLI, неинтерактивных приложений, которые решают некоторые ежедневные повторяющиеся задачи или устраняют человеческие ошибки из более сложных, хотя и не повседневных задач. Эти инструменты теперь являются частью нашего ящика для инструментов.

Я считаю, что приложения CLI великолепны, потому что вы можете включить их в автоматизированный рабочий процесс.

Кроме того, философия Unix, заключающаяся в том, чтобы делать одну вещь, но делать это хорошо, и позволять выводу процесса быть вкладом другого, является отличным способом построения набора инструментов, которые могли бы объединиться в стратегическое преимущество.

Мой начальник недавно прокомментировал, что разработка инструментов CLI является «отсталой» или представляет собой «регресс».

Я сказал ему, что не согласен, потому что большинство существующих сейчас инструментов CLI - это не устаревшие, а живые проекты с постоянно обновляемыми версиями.

Считается ли такое развитие событий «задом наперед» на рынке?

Это выглядит плохо на резюме?

Я также рассмотрел все решения, будь то веб или настольный компьютер, должны иметь командную строку, неинтерактивные параметры. Некоторые люди считают это пустой тратой ресурсов программирования.

Является ли эта цель достойной цели в программном проекте?

Я также считаю, что для веб-приложений или приложений для настольных компьютеров наличие альтернативного интерфейса CLI - отличный способ продемонстрировать, что бизнес-логика полностью отделена от графического интерфейса пользователя.

Тулаинс Кордова
источник
32
Ваш босс имеет техническое образование? Звучит так, будто он следит за философией "Я не вижу много, поэтому не так уж много". Что может быть проблематично. Спросите его, думает ли он, что люди, разрабатывающие Oracle, тоже отстали.
Иоахим Зауэр
13
Мне нравится, как все делается в мире Linux. Большинство «основных» приложений имеют как CLI, так и GUI-интерфейсы - это освобождает, потому что вы можете писать сценарии, когда вам нужно, и щелкать мышью, когда вам это не нужно. Я не понимаю, почему вам нужно выбирать одно против другого. Для написания CLI не требуется много работы.
MrFox
6
Ваш босс, очевидно, никогда не пытался написать самый простой сценарий
toasted_flakes
1
@MrFox Я согласен с вами, приложения должны иметь оба интерфейса.
Тулаинс Кордова
4
Мне нравится это , но , к сожалению, также иногда это ;)
Вим

Ответы:

21

Возможность работать с CLI вряд ли я бы посчитал задом наперед. Он отлично смотрится в резюме, особенно если вы можете добавить его в свое резюме с помощью фразы типа «Используется (Powershell / Bash) для создания набора средств автоматизации для отправки SMS-сообщений, когда база данных не работает».

Когда я отвечаю за наем людей, мне нужны рабочие знания CLI.

Джонатан Аркелл
источник
49

Это в основном сводится к «использовать правильный инструмент для работы».

Если вам нужно взаимодействовать с пользователем, вам понадобится какой-то графический интерфейс. У нас есть десятилетия исследований и опыта, показывающие, что они делают вычисления намного более интуитивными и продуктивными. Вот почему графические интерфейсы неумолимо завоевывают мир с 1984 года: они просто лучше взаимодействуют с людьми.

Но если вы автоматизируете программу с помощью скриптов, ваша программа не взаимодействует с людьми; это взаимодействует со сценарием. И лучший интерфейс для этого - текстовый, по понятным причинам.

Разработка программ CLI для пользователей, с которыми они могут работать напрямую , считается отсталой и на то есть веские причины. Но если это не то, что вы делаете, если вы пишете инструменты для повышения производительности автоматизации, то вы не делаете ничего плохого, предоставляя им CLI.

Мейсон Уилер
источник
6
+1 Ну, некоторые инструменты предоставляют информацию пользователям, например: «Все ли резервные копии базы данных актуальны, если нет, скажите, какие из них старые?». Они печатают ответ на STDOUT. Но, очевидно, его можно поставить на crontab для отправки SMS, если ответ НЕТ. Я думаю, что даже если приложение имеет графический интерфейс, оно должно иметь режим CLI с параметрами. Я сам являюсь поклонником графического интерфейса, в конце концов, я пользователь Mac. Многие важные для бизнеса приложения, особенно разработанные собственными силами, никогда не рассматривают CLI.
Тулаинс Кордова
23
Хотя я на 99% согласен, я также обнаружил, что, как технический пользователь, иногда я предпочитаю CLI GUI. Причина в том, что многие графические интерфейсы требуют, чтобы я перемещался, указывал, нажимал, проходил по меню, искал правильный флажок и т. Д. Однако в CLI все, что мне нужно сделать, это перевести английский в моей голове на «Computerish» на командная строка, и программа делает то, что я хочу за меньшее время. Таким образом, в то время как GUI намного проще для обычных пользователей, иногда опытные пользователи предпочитают CLI.
Фил
15
«Разработка программ CLI для пользователей к работе с непосредственно рассматривается назад, и с полным основанием» гм, нет, это не так просто, поэтому почему любой достаточно продвинутый конец GUI приложение на встраивание некоторые скриптовый движок с его собственным CLI
JK.
11
@MasonWheeler: Я думаю, что вы упускаете точку зрения JK. Когда GUI усложняется, технически подкованные пользователи часто предпочитают использовать механизм сценариев CLI даже для одноразовой задачи . Что, безусловно, означает «пользователи, работающие с [этим] напрямую».
Руах
8
-1 о «разработке программ CLI для пользователей, с которыми они могут работать напрямую, считается отсталым, и на то есть веские причины», это полностью зависит от приложения. Много раз, как пользователь, мне нужно работать с программой для запуска на машине, у которой даже нет графического интерфейса или монитора. Я уверен, что, черт возьми, нужен CLI тогда!
Вим
35

« Искусство программирования на Unix» Эрика Рэймонда - каноническая работа для аргумента, который вы выдвигаете. Я не буду пытаться сжать его превосходную книгу в пару параграфов. Тем не менее, имейте в виду, что аргумент в основном относится к программистам, администраторам, автоматизирующим задачи с помощью сценариев, или опытным пользователям высокотехнологичного программного обеспечения, такого как САПР.

Даже с очень техническими пользователями, вы должны учитывать, какие шляпы они носят в то время. Например, я пишу встроенное программное обеспечение для сетевого оборудования для жизни. Все наши продукты имеют как CLI, так и GUI, но разработчики почти всегда предпочитают CLI из-за его гибкости, возможности написания сценариев, доступности, скорости и т. Д.

Однако та же самая группа разработчиков в подавляющем большинстве предпочитает графический интерфейс в нашем программном обеспечении для контроля версий, хотя его интерфейс командной строки является более мощным, поддерживается и документируется так же, как и графический интерфейс. Разница в том, что мы являемся конечными пользователями программного обеспечения для контроля версий, а не администраторами или разработчиками.

Поэтому тщательно продумайте, какие роли играют ваши пользователи при использовании ваших утилит, и соответствующим образом спланируйте пользовательский интерфейс. Если ваш начальник упоминает об этом, скорее всего, вам нужно как минимум улучшить документацию и / или обучение по CLI. Если вы постоянно говорите людям, что функция доступна в интерфейсе командной строки только тогда, когда они ожидают ее для графического интерфейса пользователя, вам, вероятно, нужно переосмыслить свои приоритеты разработки, лучше учитывая потребности своих пользователей.

Карл Билефельдт
источник
16

Это не просто Unix, который управляется программами командной строки. Microsoft тоже движется в этом направлении.

Microsoft уже давно продвигает PowerShell. Все их текущее серверное программное обеспечение (Exchange, SharePoint, Server 2012, System Center и т. Д.) Может полностью контролироваться через командную строку PowerShell. А PowerShell опирается на небольшие функции, которые хорошо выполняют одну задачу и передают данные в следующую (хотя она передает объекты вместо простого текста).

Большинство графических интерфейсов для этих программ являются просто интерфейсом для команд PowerShell, многие даже сообщают вам, какие команды он будет выполнять, чтобы упростить выполнение сценариев. Все, что вы можете сделать из графического интерфейса, вы можете сделать из PowerShell. Обратное неверно - есть довольно много функций, которые доступны только в PowerShell.

Так что, если * nix всегда делал это, и Microsoft движется в этом направлении ... мне не кажется слишком отсталым!

Грант
источник
5
Просто добавить к этому: Microsoft отталкивая от графического интерфейса пользователя на серверах в большом пути. Они хотят, чтобы все работали с Server Core - без графического интерфейса, точка. Если вы можете написать сценарий для набора задач на одном компьютере, вы можете написать его для всего предприятия - удачи вам с GUI. Джеффри Сновер (ведущий архитектор Windows) дал хорошее интервью на эту тему.
Alroc
4
«Окна» идут не так; Windows Server есть. Сервер предназначен для работы в качестве автоматизированной системы с минимальным человеческим взаимодействием, так что это имеет смысл. Но вы никогда не увидите, чтобы это произошло на частях ОС, обращенных к пользователю.
Мейсон Уилер
3
Кроме того, Mac OS X перешла с чистого графического интерфейса на архитектуру * nix с сильным акцентом на сценарии командной строки. Поэтому я бы сказал, что и Microsoft, и Apple стремятся к расширению CLI.
Брэндон
1
+1 Я должен был объяснить людям уровня C, как «Windows» возвращалась к тексту. Это имеет смысл - каждое действие можно записать, протестировать и развернуть на тысячах серверов, а не входить в каждый ящик и пытаться точно повторить 200 щелчков мыши. ОП должен использовать свои навыки как сценарий / автоматизацию, а не как CLI. IIRC Windows предлагает поддержку PowerShell начиная с XP. Замечательно устанавливать предварительные требования одним скриптом вместо большого количества нажатий.
JQA
Вы правы, но имейте в виду, что для масс (глупых) пользователей компьютеров GUI будет единственной вещью, которую они знают и видят ... это особенно верно, если учесть тот факт, что GUI старше многих из них ...
Раду Мурзеа
4

Я бы точно не сказал, что это плохо. Хорошая вещь о программах CLI состоит в том, что при их реализации вы можете иметь очень ограниченную область действия. Например, если я хочу написать catклон или «программу для печати содержимого файла на экран», это очень выполнимо с CLI.

Однако, что если вы не используете CLI, то у вас будет базовая программа с графическим интерфейсом, отображающая некоторый текст. Но тогда вам также придется связать себя, открыв диалоговое окно файла и подключив его ... но тогда кто-то также захочет изменить текст и сохранить его в другом месте ...

Сфера ползучести смешна с приложениями GUI. Это очень легко избежать, хотя с приложениями CLI. «Вы хотите отредактировать файл и затем сохранить его? cat foo > ed > bar» С приложениями CLI тривиально объединить его с другими инструментами для ваших пользователей (а не для вас, разработчика).

Теперь, как говорится, программы CLI начинают рассматриваться как «задом наперед». Это связано с тем, что в наши дни большая часть разработки приложений происходит на рынках, где пользователи, комбинирующие ваш инструмент с другими инструментами, практически невозможны. Я не буду вдаваться в подробности здесь, но я написал в блоге сообщение о том, как «торговые площадки применяют менталитет без хозяина», что является полной противоположностью хорошо спроектированному приложению CLI (делать что-то и делать это хорошо). )

Earlz
источник
4

GUI и CLI оба имеют свое место. Графический интерфейс отлично подходит для того, чтобы позволить пользователю быстро выполнять определенные стандартные операции. CLI предназначен для тех случаев, когда вы хотите делать то, что GUI не позволяет вам делать. CLI обычно более мощный и сложный в использовании.

Хороший инструмент CLI позволяет пользователю делать вещи , человек , который написал инструмент никогда не задумывался. Одним из примеров является UNIX команда «найти». Эта команда:

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

находит файлы в текущем каталоге (но не более 5 уровней), которые имеют имя, начинающееся с «xyzzy» и которые были изменены более 3 дней назад, а затем удаляют их (примечание: непроверенный код). И это в меру простое использование. Вы можете использовать файловый менеджер, чтобы делать такие вещи, но это займет больше времени и подвержено ошибкам. Конечно, быть более мощным означает, что CLI легче использовать и создавать проблемы для себя!

Хороший разработчик может написать инструмент CLI таким образом, чтобы он также имел графический интерфейс, позволяющий выполнять ограниченный набор операций. Пользователь может начать с графического интерфейса и узнать о сложностях CLI позже.

Хорошее (длинное и смещенное (?)) Чтение о компромиссе CLI / GUI находится по адресу:

http://www.cryptonomicon.com/beginning.html
rzzzwilson
источник
1
+1, особенно за ссылку на «В начале была командная линия»
Бен Ли
1

Нет, это совсем не наоборот.

«Направление» имеет много общего с нашей точки зрения. Пользователь, довольный текущим путем к простым интерфейсам «один опыт для всех устройств», наверняка увидит CLI как возврат или регресс. Это не соответствует их общим ожиданиям.

Программист, администратор или опытный пользователь могут видеть это как логическое развитие инструментов в соответствии с их опытом. Многие из них начинаются с использования инструментов GUI. Когда они хотят или нуждаются в масштабировании, они быстро выясняют, почему существует CLI, и этот прогресс резонирует с теми, кто создает больше инструментов CLI.

Есть это Пол Феррис: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Лично для меня идея синтаксиса различает два. Когда синтаксис несколько присутствует в графическом интерфейсе, результат почти никогда не бывает хорошим и столь же гибким, как и продуманный синтаксис CLI. Когда это связано с конвейерами и перенаправлением, графический интерфейс пользователя падает, потому что он не очень полезен вне запланированных вариантов использования.

Мое личное предпочтение в этом - инструменты CLI, которые предлагают опцию --gui или --verbose, достаточную для того, чтобы позволить оболочке GUI надежно взаимодействовать, включая строки состояния и другие основные элементы, которые люди ищут в GUI.

Конечно, стоимость этого по существу составляет две программы, одна из которых довольно бесполезна без другой, но главное преимущество заключается в возможности включения одного или нескольких замечательных инструментов CLI в пользовательский графический интерфейс без модификации указанных инструментов CLI. Чаще всего это делается только для того, чтобы предложить вариант графического интерфейса пользователя для конкретного интерфейса командной строки, но идея использования нескольких инструментов с помощью одного ориентированного на «процесс» или «сценарий использования» графического интерфейса пользователя может дать результаты, аналогичные конвейерной обработке, перенаправлению и созданию сценариев для этого варианта использования, сделать его доступным для людей, которые не будут выполнять эти операции достаточно регулярно, чтобы достичь мастерства, но при этом не будут мешать пользователям CLI.

Я сталкивался с таким подходом в SGI IRIX и он мне очень понравился. Я обнаружил, что использую графический интерфейс или командную строку по мере необходимости, и приятно было точно знать, что на самом деле делают причудливые кнопки.

Там, где есть много разных операционных сред, оболочки GUI могут значительно отличаться, не влияя также и на инструмент CLI.

Сегодня я вижу это в Linux с такими инструментами, как диск / файловая система, где GUI может принести большую пользу даже знакомым пользователям CLI.

В случае с известными файловыми системами / дисками / устройствами выбить CLI не сложно, и, конечно, его можно записать в сценарии. Однако ошибки могут быть болезненными.

В тех случаях, когда они могут быть неизвестны или, возможно, выполнение операций не выполняется достаточно регулярно, чтобы оставаться надежным и безошибочным, запуск графического интерфейса пользователя обеспечивает среду, которая может быть легко проверена, операции объединены в цепочку и затем выполнены с уверенностью, никаких сценариев не требуется.

user94936
источник