Редактор або IDE? Чергова спроба аналізу

Хотілося б в черговий раз підняти цю досить спірну тему.

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

У статті я постараюся виправити це упущення і розставити ще трохи крапок над «е».

Запрошую всіх взяти участь у пошуках ідеального інструменту.


Про моєму досвіді
Програмувати я починав ще в ДОС. на Turbo Pascal-є. Причому, чомусь, IDE ми тоді використовували тільки для налагодження, і то досить рідко. Для писання коду воліли використовувати якийсь безіменний edit.exe без всякої підсвічування синтаксису в зв'язці з Volkov Commander. І цього вистачало. Цим же способом я пізніше займався ассемблером і, частково, C++.

Продовжуючи вивчати C++ я перейшов на Windows і, відповідно, Visual Studio — куди ж без нього. Застав версії, якщо не помиляюся, з 5 до 7. Після простенького редактора це було щось — кодогенерация автодоповнення викликали захват. Правда, у всьому цьому створеному добре розібратися було практично неможливо, але це здавалося неважливим.

Через деякий час я пересів на Linux і зайнявся веб-розробкою на php. Тут паралельно вивчав vim і для розробки використовував ZendStudio. У якийсь момент почав використовувати тільки Vim для всього — перетворив його, згідно з численними керівництвами в маленьку ide. В ньому ж написав свою першу велосипедну CMS на php.

Зауважу, що до цього програмування не було основним видом моєї діяльності. Так, я і писав різні дрібні утилітки, робив теми для WordPress, але основним родом діяльності було адміністрування.

Як тільки я зайнявся розробкою професійно — можливостей vim мені перестало вистачати. Був спочатку eclipse, потім netbeans, зараз — phpstorm.

Останні пів-року героїчно намагаюся освоїти emacs, в т. ч. в якості основної робочої середовища.

Так що у мене є з чим порівнювати і, сподіваюся, моя думка буде достатньо обґрунтованим і агрументированным.

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

Почну, мабуть, з одного з безперечних переваг редактора — його багатих можливостей по роботі з текстом і можливості все робити, не відриваючи рук від клавіатури. Середовища в більшості своїй так не вміють. Тільки ось чи потрібні такі можливості при написанні коду? При написанні статті або листи, думаю, зручно одним натисканням клавіші поміняти місцями 2 слова або пересунути абзац вверх сторінки. Але в тексті програми це, в більшості випадків безглуздо і вимагає рефакторінгу. А платити за це доводиться або пальцедробительными сполученнями клавіш emacs, або не менш мозгодробительными командами в vim. А адже це все потрібно поминати! Те, що просто вирішується одним рухом миші, на зразок переміщення вікна або зміни їх розмірів, перетворюється в цілий квест. Та навіть виділити текст простіше мишкою — точніше, швидше, і треба рахувати скільки там слів до нужнго місця в тексті. Ні, програмісту теж може бути корисні ці функції, але справа в тому, що його часові витрати на власне редагування коду незначні, так що вигоди у часі не буде практично жодної. А ось значне ускладнення інструменту — очевидна.

Програміст 80% свого часу витрачає на розуміння написаного коду і переміщення по ньому. Причому переміщенню саме по коду, а не за текстом! І тут йому редактор не може допомогти абсолютно нічим. Список параметрів методу у спливаючій підказці не покаже, перейти до визначення методу не дозволить, синтаксис не проконтролює. А IDE, навіть найпростіші, з цим справляються просто і елегантно. Нещодавно Я витратив хвилин 10 на пошук визначення одного методу в проекті за допомогою silversearcher з emacs. Виявилося, клас був визначений в іншому модулі і т. п. 10 хвилин, замість одного кліка мишкою! Я в emacs, звичайно, недостатньо досвідчений, тому нехай буде 5 хвилин, навіть хвилина. Але все одно вражає співвідношення.

І ось тут IDE показує свій, мабуть, єдиний, але дуже жирний плюс — це наявність синтаксичного аналізатора мови програмування. Середовище «розуміє» що вона редагує код. Редактор — ні. А це автодоповнення, і навігація, і підсвічування синтаксису, а, іноді, і семантичних помилок. Здається, надмірність, приємна дрібниця, пустощі. Але воно, перетворюється в необхідність після того, як розмір проекту переважає певна межа. А з урахуванням об'ємних сучасних фреймворків — це межа настає практично відразу.

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

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

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

Хтось може заперечити, що в сучасних редакторах багато з цих функцій вже реалізовані і нічим не поступаються самим навороченним IDE. Не погоджуся. По-перше, повноцінних реалізацій немає. Не працюють вони, як повинні. По-друге, установка всього цього вже достатньо складне завдання. Та навіть конфігурація внутрішніх функцій редактора вже нетривіальна. Спробуйте, скажімо, включити нумерацію рядків у тому ж emacs! Плюс до всього, часто потрібний функціонал реалізується десятком плагінів незрозуміло як між собою взаємодіють. А часто ще й мають десяток версій і гілок, не завжди сумісних, дивно настраиваюхся і т. п. Можна, звичайно, витратити місяць, все налаштувати і встановити (що теж доля ентузіастів), але це лише наблизить редактор до рівня IDE. Приміром, повернемося до тих же проектів — я пробував і Project під vim і projectile під emacs і ще деякі плагіни. Якщо Project ще більш-менш відповідає моїм вимогам (хоча в останній версії мені взагалі не вдалося створити проект за багів), то projectile залишив виключно негативні враження.

І тим не менш, у редакторів є кілька областей застосування, де вони, як мінімум, складають гідну конкуренцію середовищ розробки.

По-перше, вони показують себе краще на дрібних проектах. Немає сенсу завантажувати IDE-комбайн для роботи з проектом в 10-20 файлів. Простіше в редакторі підправити 3-4 рядки.

По-друге, в деяких специфічних областях всі переваги IDE нівелюються. Наприклад, низькорівнева розробка для linux. Я цим не займався, але, судячи по структурі коду і перевагам розробників (близько 70% — emacs і клони, 25% — vim, 5% — якась екзотика начебто jed), IDE там робити нічого. Весь потрібний код, за яким відбувається робота, зібрано, як правило в одному-двох файлах, і не треба стрибати в межах всього проекту. Та й не сильно допоможе автодоповнення при виборі з десятка-двох функцій з майже однаковими назвами.

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

По-четверте, можливість роботи з мовами, для яких немає осудною IDE. Скажімо, з тим же ruby мені середовище не сильно допомогла. SublimeText-а виявилося достатньо. Хоча з великим ruby проектом я не працював, можливо, там би IDE себе показала.

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

Разом
Я не дуже люблю IDE, хоча так могло здатися з попереднім текстом. Вважаю їх досить монструозними, з купою непотрібних функцій, повільними і вимогливими до ресурсів. Так і кращі з них досить дорогі. Крім того, я вважаю, використання IDE розслабляє, і прив'язує до себе. У редакторів, відповідно, все навпаки. Плюс доступність і можливості тонкої доведення під себе. Принаймні vim та emacs. Зрештою, вони мені просто подобаються. Цю статтю, наприклад, я пишу в Emacs.

Але індустрія (і начальство) диктує свої вимоги. Якщо не використовувати IDE, продуктивність значно впаде. Але ніхто не дасть вам пів-години на пошук пропущеної коми в 10 тис рядках коду. Це все повинно виконуватися автоматично і автоматично ж виправлятися. Мені теж іноді подобається покопатися в коді без всяких інструментів — але на роботі це недозволена трата часу.

Після всіх своїх проб і помилок я зробив такий висновок — редактор використовувати для розробки, але з IDE, після певної межі він не зрівняється і використання редактора для чогось, за що вам платять — недозволена розкіш. Так, якщо використовувати правильні практики розробки, правильно проектувати/документувати код, слідувати стандартам — можна згладити вроджені вади редакторів. Але ми живемо далеко не в ідеальному світі, тому використання IDE — необхідність, незалежно від нашого бажання.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.