Чим робочий процес програміста, орієнтованого на CLI, відрізняється від орієнтованого на графічний інтерфейс?

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

Негайно:

• Я кодую деякі побічні проекти на таких мовах, як C / C ++ / D / C # / Java / Python, використовуючи Visual Studio, Eclipse тощо, і запускаю їх, встановлюючи налаштування збірки та натискаючи F5 для складання / запуску.

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

• Для запуску регулярних програм я використовую Launchy ... досі немає терміналу. :)

• Для копіювання файлів і т.п. я використовую звичайний пошук / переміщення у графічному файловому менеджері (Windows Explorer, Nautilus).

• Налагодження: я використовую або Visual Studio, або інструменти налагодження для Windows (якщо я в Windows). Я не робив багато налагоджень в Linux, але для тих, що я робив, я використовував Eclipse (також для Java в Windows).

• На роботі: щоб підключитися до системи збирання та створити проект, я просто використовую інструменти, інтегровані в Eclipse для мого використання - не потрібно терміналу чи нічого (хоча я, звичайно, бажаю використовувати термінал, якщо я дійсно хочу)

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

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

По-перше, програми GUI можуть зробити для вас контекст. Наприклад, функція Go To Definition та Intellisense програми Visual Studio. Як ви могли повторити ці функції в CLI?

По-друге, програми GUI можуть відображати вам набагато більше. Наприклад, Visual Studio Parallel Profiler, який представляє собою графік використання процесора в декількох ядрах протягом часу. Як ви могли це відобразити в CLI? Це просто не мало б сенсу. Як тільки ваші дані будуть краще виражені як щось інше, ніж текст, CLI миттєво втрачається. Ще один простий приклад - точки прориву. У Visual Studio ви клацаєте по межі рядка, який ви хочете розбити. Що ви збираєтеся робити в CLI, спробуйте знайти номер файла та рядка та введіть цю команду? Це займе у вас відносне десятиліття. Це навіть не враховує деякі новіші інновації графічного інтерфейсу, наприклад, Canvas Canvas.

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

Я думаю, що найбільша різниця полягає не в окремих завданнях, а в двох речах:

Перш за все, автоматизація. CLI - це вкрай важливий сценарій, який зазвичай складніше для Windows. Я чув, як покращувалися речі з PowerShell, але я не використовував це.

По-друге, філософія UNIX про "розділення проблем". Я можу написати невеликий інтерфейс на основі читальної лінії до чогось і за допомогою оболонки Emacs Mx використовувати його всередині графічного інтерфейсу emacs. Це спрощує використання інших інструментів та наявної функціональності.

Для налагодження gdb працює добре, але я зазвичай вважаю за краще відладчик VS. Це, мабуть, найкраща частина програмного забезпечення, яку Microsoft коли-небудь робив.

Для побудови та експлуатації речей: зробити. Або баш. Куди б не було.

Для розробки: emacs (нещодавнє перетворення з vi, о сором!). Vi, якщо ви робите роботу через ssh.

Я справді не можу звикнути до затемнення. Я думаю, що це проблема "форми духу": вона не відповідає моїй.

Для мене перехід на робочий процес CLI від Visual Studio передбачав запам'ятовування безлічі команд * nix. Він також включав деякі головні болі, коли я псував SVN-реєстрацію.

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

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

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

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

Розробка на базі CLI має тенденцію використовувати різноманітні програми, кожна з яких виконує 1 функцію. Розробка на основі GUI має тенденцію використовувати 1 велику програму (IDE), яка виконує десятки різних функцій. Ця одна різниця має кілька наслідків:

Оскільки IDE призначений бути вашим "домом", де ви постійно працюєте, вони можуть використовувати фірмовий (можливо, двійковий) формат для зберігання ваших даних. Сумісність не викликає особливих проблем, оскільки вони не очікують, що ви будете працювати в двох різних IDE в одному проекті. Інструменти CLI, з іншого боку, зазвичай працюють просто з текстовими файлами.

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

Використання сценарію збирання CLI, а не вбудованого меню "Build" IDE, робить більш імовірним, що ви можете піти від коду на кілька років, повернутися до нього та створити його без суєти. При розробці на основі графічного інтерфейсу, ймовірно, ви вже використовуєте зовсім інший IDE. Можливо, той, який ви використовували під час написання коду, навіть не працює у вашій поточній ОС.

У програмі IDE створення власних інструментів означає вивчення (можливо, великого) додатка API та, можливо, використання певної мови. Під час використання CLI нічого особливого не потрібно для виготовлення спеціальних інструментів.

З іншого боку, перевага IDE полягає в тому, що він, ну, "інтегрований". Таким чином, ви можете натиснути у вікні редактора, щоб встановити точки відключення налагоджувача тощо.

Ще один момент: ваш вибір також залежатиме від платформи розробки, ОС та мови, якою ви користуєтесь. На певних платформах розробка на основі IDE глибоко вкорінена в існуючій культурі розвитку. В інших переважає розвиток на основі CLI. Якщо ви використовуєте платформу, на якій переважає розробка на основі IDE, ймовірно, що інструменти CLI будуть погано розвинені та погано підтримуються. Зворотна також правда.

Більшу частину мого дитинства не проводили за комп’ютером, оскільки у нас навіть на фермі був Інтернет. Я почав програмувати пізно в середній школі і весь час працював у графічних інтерфейсах. У коледжі я зустрів хлопця, який виріс на CLI і все робив так. Тому я вирішив налаштувати сервер Linux, а не слухати проф. Через кілька років приятель спостерігав, як я пишу якийсь вбудований код і не міг повірити, як я написав.

Я в основному використовую половину CLI, половину GUI. Є деякі речі, які в середовищі, що підтримує графічний інтерфейс, роблять набагато швидше та ефективніше. І те саме стосується CLI. Більшість моїх редагувань тексту проводиться у VIM, оскільки передові редактори CLI VIM / EMACS (тут немає будь-яких воєн) роблять маніпуляцію текстом найбільш ефективною. Такі речі, як вбудована налагодження за допомогою GDB, з іншого боку, такі ж болючі, як і редагування тексту без клавіатури. Впевнені, що його потужний і впевнений, що за достатньо часу ви знайдете інформацію, яку шукаєте, але приємне вікно графічного інтерфейсу з миттєвим доступом до будь-якого блоку пам'яті є безцінним, особливо при спробі порівняти його з іншим блоком пам'яті.

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

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

Мій робочий процес, нещодавно покращений менеджером плиткових вікон (dwm), складається з безлічі набраних текстів. Мій ноутбук зараз фактично придатний для використання без підключення миші (трекпад достатній для того, що залишилося від вказівки). Я тримаю багато програм відкритими та перемикаюсь за допомогою alt-tab. Я не витрачаю час на переміщення та зміну розміру вікон.

Більшу частину часу я використовую браузер, vim та купу терміналів. SSH дає мені велику гнучкість щодо того, де я працюю (фізично). Віддалені настільні комп'ютери можуть запропонувати кращий досвід, коли у нас є все 10Gigabit труби до мережі, але я не затримую дихання.

Я не навчився vim досить добре, щоб скористатися його складними особливостями, але я схиляюся в цьому напрямку - мені хочеться, щоб vim перейшов до правильної лінії # після того, як не вдалося зробити. (Технічно vim - це візуальний інтерфейс, хоча він працює в терміналі, але я керую ним за допомогою клавіатури, а не миші.)

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

(Мій інший великий вихованець з домашніми тваринами роздутий. Коли потрібна програма на 19 МБ, яка допоможе мені виконати те саме завдання, що і програма на 200 КБ, щось не так. XTree Gold для DOS підвищив мою продуктивність більше, ніж будь-який сучасний файловий менеджер. Windows 2.11 використовувався лише з плиткою windows. Turbo C був дивовижним IDE. Чому, схоже, мій Nook працює повільніше, ніж класичний Mac? Чому одне ядро ​​тепер займає більше дискового простору, ніж вся система, що використовувалася?)

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

Програмування в терміналі, можливо, не набагато краще, ніж у графічному редакторі, якщо ви не використовуєте SSH.

Я особисто знайшов оболонку unix набагато доступнішою, ніж типовий командний рядок Windows, і зараз я дуже занурений у неї в системі Linux з керуючим вікном менеджером і безліччю терміналів.

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

У мене були подібні дебати щодо команд клавіатури проти миші.

Те, як я працюю, на сьогоднішній день сприяє графічному інтерфейсу.

Типове використання:

• Три IDE для трьох різних платформ. Також вікно «Блокнот ++» для деяких сценаріїв. Просто я не зможу запам'ятати команди для всіх цих систем побудови. Проблема з CLI полягає в тому, що вам потрібно знати багато деталей, щоб просто працювати. Сучасні IDES зазвичай мають за замовчуванням деякі відповідні варіанти. Ви завжди можете придивитись ближче, коли настане час.
• SVN або Git інтегровані. Існує так багато варіантів програми, яка є допоміжною для програмування, і більшість часу я лише виконую версію чи оновлення.
• Мережеві речі: Пощастило мені, я також можу зробити всі налаштування мережі в нашому офісі. Більшість мережевих плат надають вам набір команд CLI, але якщо вам потрібен огляд стану, це брандмауер та маршрутизація. Для маршрутизації я можу майже проживати з командним рядком, але брандмауери ускладнюються, і якщо є одне, GUI - це добре, він відображає багато інформації.
• Як правило, багато переходить від одного до іншого. Контекстні комутатори простіші з візуальним контекстом.

Що стосується основної вигоди CLI, сценаріїв, я майже ніколи цього не роблю. Завдання, які ми повторюємо, - це лише додатки для роботи з cron, які ми зібрали разом у c # і не часто змінювали. У нас є способи запустити роботи в Linux, але в основному вони переносяться (збільшити), тому безладдя з файлами і подібними речами зводиться до мінімуму. І якщо щось стає волохатим, є і хороші IDE для Linux.