Чи вважається розробка додатків CLI “відсталою”? [зачинено]

Я є учасником DBA з великим досвідом програмування.

Я розробив декілька CLI, неінтерактивних додатків, які вирішують деякі щоденні завдання, що повторюються, або усувають помилку людини від більш складних, хоча і не таких щоденних завдань. Ці інструменти зараз є частиною нашої скриньки інструментів.

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

Крім того, філософія Unix робити одну річ, але робити це добре і дозволяти результату процесу бути вкладом іншого, - це чудовий спосіб побудови набору інструментів, ніж зміцнення в стратегічну перевагу.

Нещодавно мій начальник прокоментував, що розробка інструментів CLI є "відсталою", або є "регресією".

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

Чи вважається такий розвиток розвитку «зворотним» на ринку?

Це погано виглядає на резюме?

Я також розглядав усі рішення, будь то веб-чи настільні, повинні мати командний рядок, неінтерактивні параметри. Деякі люди вважають це марною витратою програмних ресурсів.

Чи гідна ця мета в проекті програмного забезпечення?

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

Мати можливість працювати з CLI - навряд чи те, що я б вважав заднім числом. Це чудово виглядає в резюме, особливо якщо ви можете накрутити його на резюме фразою на кшталт "Використовується (Powershell / Bash) для створення набору засобів автоматизації для надсилання SMS-повідомлень, коли База даних була вниз".

Коли я відповідаю за найм людей, то знаю, що працює в CLI, - це те, чого я шукаю.

Це в основному зводиться до "використання правильного інструменту для роботи".

Якщо вам доведеться взаємодіяти з користувачем, вам потрібен якийсь графічний інтерфейс. У нас десятиліття досліджень і досвіду показують, що вони роблять обчислення набагато інтуїтивнішими та продуктивнішими. Ось чому графічні інтерфейси невблаганно переймали світ ще з 1984 року: вони просто краще працюють для взаємодії з людьми.

Але якщо ви автоматизуєте програму зі скриптами, вона не взаємодіє з людьми; це взаємодія зі сценарієм. І найкращий інтерфейс для цього - це текстовий, з причин, які мають бути інтуїтивно зрозумілими.

Розробка програм CLI для користувачів, з якими безпосередньо працювати , вважається відсталою та з поважною причиною. Але якщо це не те, що ви робите, якщо ви пишете інструменти продуктивності для автоматизації, то ви нічого не робите, даючи їм CLI.

Ерік Реймонд «Мистецтво програмування Unix» є канонічним твором для аргументу, який ви висуваєте. Я не буду намагатися згуртувати його чудову книгу на пару абзаців. Однак майте на увазі, що аргумент стосується в основному програмістів, адміністраторів, що автоматизують завдання за допомогою сценаріїв, або тих, хто користується високотехнологічним програмним забезпеченням, таким як CAD.

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

Однак саме така група розробників переважно віддає перевагу GUI на нашому програмному забезпеченні для управління версіями, навіть якщо його CLI є більш потужним і підтримується та документально підтверджується так само, як і GUI. Різниця полягає в тому, що ми - кінцеві користувачі програмного забезпечення для управління версіями, а не адміністратори чи розробники.

Тому уважно подумайте, які ролі виконують ваші користувачі, коли вони користуються вашими утилітами, і сплануйте відповідний інтерфейс користувача відповідно. Якщо ваш начальник згадує про це, швидше за все, вам потрібно покращити документацію та / або пройти навчання в CLI як мінімум. Якщо ви постійно говорите людям, що функція доступна в CLI лише тоді, коли вони очікують її на GUI, вам, мабуть, потрібно переосмислити свої пріоритети розвитку, краще враховуючи потреби своїх користувачів.

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

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

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

Я сьогодні бачу це в Linux з такими речами, як інструменти диска / файлової системи, де графічний інтерфейс може додати багато цінності навіть знайомим користувачам CLI.

У випадку з відомими файловими системами / дисками / пристроями вибивання CLI не є складним, і це, звичайно, може бути написано. Помилки можуть бути болісними.

Якщо це може бути невідомо, або, можливо, виконання операцій не робиться достатньо регулярно, щоб залишатися надійними та помилками, запуск графічного інтерфейсу забезпечує середовище, яке можна легко перевірити, операції пов'язані між собою, а потім виконувати з упевненістю, не потрібні сценарії.