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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Направление» имеет много общего с нашей точки зрения. Пользователь, довольный текущим путем к простым интерфейсам «один опыт для всех устройств», наверняка увидит 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 не сложно, и, конечно, его можно записать в сценарии. Однако ошибки могут быть болезненными.

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