Что вы думаете о разработке для командной строки в первую очередь?

Question

Каково ваше мнение о разработке сначала для командной строки, а затем о добавлении графического интерфейса после факта простым вызовом методов командной строки?

например.

W: \ todo AddTask "встреча с Джоном, повторная проверка входа в систему" "Офис Джона" "2008-08-22" "14:00"

загружает todo.exe и вызывает функцию с именем AddTask, которая выполняет некоторую проверку и выбрасывает собрание в базу данных.

В конце концов вы добавите на экран для этого:

============================================================

Event:    [meeting with John, re: login peer review]

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

============================================================

Когда вы нажимаете кнопку Отправить, он вызывает ту же функцию AddTask.

Считается ли это:

• хороший способ кодирования
• только для новичков
• ужасающий!.

Приложение:

Я заметил здесь тенденцию к «общей библиотеке, вызываемой как исполняемыми файлами GUI, так и CLI». Есть ли какая-то веская причина, по которой они должны быть разделены, кроме, возможно, размера самих двоичных файлов?

Почему бы просто не вызвать один и тот же исполняемый файл по-разному:

• "todo /G" когда вам нужен полноценный графический интерфейс
• "todo /I" для интерактивного приглашения в пределах todo.exe (сценарии и т. Д.)
• обычный старый "todo <function>" когда вы просто хотите сделать что-то и покончить с этим.

Приложение 2:

Было упомянуто, что «для того, чтобы [я] описывал вещи, вам [нужно было бы] создавать исполняемый файл каждый раз, когда графический интерфейс должен что-то делать».

Опять же, это не было моим намерением. Когда я упомянул, что пример GUI называется «та же самая функция AddTask», я не имел в виду, что GUI каждый раз вызывал программу командной строки. Я согласен, что это было бы совершенно противно. Я намеревался (см. Первое приложение), чтобы все это содержалось в одном исполняемом файле, поскольку это был крошечный пример, но я не думаю, что моя формулировка обязательно исключала использование общей библиотеки.

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

Answer 1

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

Кроме того, с помощью библиотеки вы можете легко выполнять модульные тесты на функциональность.

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

Answer 2

Поместите общую функциональность в библиотеку, затем напишите для нее командную строку и интерфейс GUI. Таким образом, переход слоя не привязан к командной строке.

(Кроме того, этот способ добавляет еще одну проблему безопасности: не должен ли сначала графический интерфейс пользователя убедиться, что вызывается именно ПРАВОЙ todo.exe?)

Answer 3

Джоэл несколько лет назад написал статью, в которой эту разработку (в стиле «unix») сравнивают с первым методом «GUI» (в стиле «Windows»). Он назвал это Бикультурализмом .

Я думаю, что в Windows станет нормальным (если он еще этого не сделал) обернуть свою логику в сборки .NET, к которым затем можно получить доступ как из графического интерфейса, так и из поставщика PowerShell. Таким образом, вы получите лучшее из обоих миров.

Answer 4

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

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

Answer 5

Я думаю, это зависит от того, какой тип приложения вы разрабатываете. Проектирование для командной строки позволяет вам быстро перейти к тому, что Алан Купер называет «Модель реализации» в Заключенные получают убежище . В результате пользовательский интерфейс не интуитивно понятен и сложен в использовании.

37signals также рекомендует сначала разработать пользовательский интерфейс в Getting Real . Помните, что в большинстве случаев пользовательский интерфейс является программой. Внутренний код только для поддержки.

Answer 6

@ jcarrascal

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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

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

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

Answer 10

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

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

Но, если вы пишете новый код, который сам по себе не зависит от пользовательского интерфейса , тогда сделайте это.