Як випливає з назви статті, я не маю формального досвіду розробки. Перш ніж я поринув у створення свого першого плагіна, максимум, на що я був здатний - це код на HTML і CSS.
Але! Я був дуже натхненний ідеєю створення плагіна для WordPress, тому вирішив перевірити, чи виправдані всі ці побоювання з приводу заміни штучним інтелектом молодших розробників.
Чи можу я дійсно використати штучний інтелект для створення плагіна? Прответ - "так".
Я використовував ChatGPT та Claude. Проте, хоч би якими корисними вони були, я не думаю, що штучний інтелект замінить молодших розробників найближчим часом. Весь проект досі вимагав значної роботи з мого боку. Не говорячи вже про сильне бажання підвищити рівень моєї гри в кодинг. Якби це було просте рішення plug-and-play, то стаття, яку ви зараз читаєте, не існувала б.
Почну з короткої розповіді про створений мною плагін. А потім розповім про помилки, яких я припустився у процесі, щоб ви могли їх уникнути у своїй практиці.
Коротка передісторія мого плагіна WordPress з використанням ChatGPT та та Claude
Плагін, який я вибрав для складання, призначений для того, щоб зробити текст на сторінках та постах WordPress більш інтерактивним. Я побудував початковий реліз із вісьма ефектами:
- Розмиття тексту.
- Зашифрований текст.
- Додати підказку до тексту.
- Збільшувати або зменшувати розмір тексту під час наведення курсору.
- Додайте ефект свічення до тексту.
- Виділення тексту кольором.
- Зробити текст, що плавно з'являється.
- Додати в текст аудіофрагмент, що відтворюється на кліку.
Я також створив область налаштувань, щоб користувачі могли встановлювати стандартні значення для більшості ефектів. Крім того, є розділ документації, в якому пояснюється, як все використовувати, журнал змін та вбудована контактна форма для допомоги або зворотного зв'язку.
Спочатку я намагався створити його, включаючи ефекти безпосередньо до редактора блоків. Незважаючи на деякий прогрес, зрештою я натрапив на стіну помилок, з якими не міг упоратися мій недолік навичок. Потім я вирішив перейти на підхід з короткими кодами, який був набагато більш здійсненний для новачка на зразок мене.
Тепер, коли у вас є загальне уявлення про те, що робить мій плагін, і трохи передісторії, давайте розглянемо помилки, яких я припустився при його створенні, і поговоримо про те, як їх уникнути.
Помилка №1: Не склав детальної схеми свого плагіна заздалегідь
Я був такий натхненний тим, що мені потрібно було перейти до етапу кодування та складання, що я поспішив пройти етап планування. Це призвело до великої кількості розчарувань, які можна було запобігти, і марнування часу.
Найбільший аспект цієї помилки в цілому полягав у тому, що я повністю знехтував областю налаштувань користувача і зосередився виключно на ефектах інтерфейсу. Коли я говорю повністюя маю на увазі, що я навіть не думав про це. Усі мої спонукання до цього були спонтанними та вкрай неповними.
Насправді це призвело до занадто великої кількості непотрібних правок. Після кожної редагування я помічав щось ще, що я змарнував. Наприклад, бачите нижче одну з ранніх ітерацій, яку я створив, де намагався втиснути всі ефекти на одну сторінку. Ймовірно, можна було б обійтися без цього, якби я мав лише чотири чи п'ять ефектів, але в мене їх було вісім. Плюс, якщо в якийсь момент я вирішу додати більше, спроба розмістити їх на одній сторінці вийде з-під контролю.
Якби я спланував це заздалегідь, я б із самого початку обрав макет із вкладками, який у результаті використав. Весь процес пройшов би набагато гладкіше.
Як зробити краще
Як тільки ви визначитеся з тим, що повинен робити ваш плагін на широкому рівні, знайдіть існуючі плагіни, які роблять те саме або мають деякі збіги. Встановіть їх на фіктивний сайт за допомогою TasteWP та використовуйте їх. Але не просто використовуйте їх як звичайний користувач, а так, як їх використав би дослідник UX. Робіть ретельні нотатки про те, як працюють різні речі, відповідаючи на запитання:
- Що вам подобається?
- Що б ви зробили по-іншому?
- Потім складіть докладний опис прототипу. Запитайте себе, як користувачі взаємодіятимуть з ним.
- Чи використовуватимуть вони шорткоди?
- Чи додаватимуть додаткові блоки до редактора блоків?
- Чи буде область налаштувань на бекенді?
Прикрийте всі свої тили
Розгляньте можливість використання каркасів для візуального відображення того, як користувачі будуть переміщатися вашим плагіном. Можете отримати безкоштовні каркаси на Figma.
Закінчивши викладене вище, використовуйте свій докладний опис і, можливо, створені вами каркаси, щоб дати ChatGPT першу підказку. Я рекомендую починати з малого та поступово нарощувати підказку. Так легше локалізувати і виправити будь-які помилки, що виникають.
Якби я робив все це знову, спочатку дав би GPT загальний огляд того, що хочу зробити. І також згадав інструменти та скрипти, які хочу використати. Потім почав би створювати лише перший ефект разом із відповідною областю для нього на бекенді. Протестував би його, щоби переконатися, що він працює. Якщо все добре, то додав би наступний ефект і таке інше.
Помилка №2: від початку ігнорувалися стандарти кодування WordPress
Ще одна велика помилка, яку я зробив, полягала в тому, що я не усвідомлював, наскільки велика прірва між простим створенням працюючого плагіна та створенням плагіна, гідного відправки до репозитарію WordPress. Можете бути здивовані, але перехід від нуля до функціонуючого плагіну набагато простіше і швидше, ніж перехід від функціонуючого плагіна до добре закодованого плагіна.
Якщо висловити це у реальних числах:
Мені знадобилося всього два-три дні, щоб створити працюючий плагін, але мені потрібно ще сім тижнів роботи, перш ніж я довів його до стану, коли зміг відправити його в WordPress репозиторій для розгляду.
Навіть якщо ваша кінцева мета не полягає в тому, щоб відправити свій плагін, і розробляєте його тільки для себе або веб-сайту клієнта, то все одно повинні слідувати кращим практикам кодування. Це гарантує, що плагін не призведе до поломки чогось на сайті та не створить непотрібне навантаження на ресурси сайту.
Як зробити краще
Обов'язково повідомте ChatGPT (або Claude) з самого початку, що будь-який код, що ним генерується, повинен відповідати стандартам кодування WordPress.
Якщо плануєте відправити свій плагін до репозиторію WordPress, то для вірності додайте, що будь-які відступи повинні бути зроблені за допомогою табуляції, А не прогалин. GPT має тенденцію за промовчанням використовувати прогалини, але це суперечить стандартам кодування.
Якщо не припините це в зародку з самого початку, то доведеться мати з цим справу пізніше, коли займатиметеся лістингом. Можливо, варто зробити це правильно із самого початку.
Помилка №3: Дозволив GPT постійно перегенерувати цілі файли коду
Одна з речей, яку спокуса зробити, якщо у вас дуже мало досвіду роботи з кодом, - попросити ChatGPT перегенерувати цілі файли коду при налагодженні. Я був винен у цьому, доки не зрозумів, що це ні до чого не призводить.
Це не обов'язково проблема, якщо ви маєте справу з відносно невеликим файлом JavaScript довжиною від 50 до 100 рядків. Однак, у міру того, як плагін стає складнішим, а основний файл PHP починає значно зростати, це стає дуже проблематичним.
По-перше, GPT потрібен деякий час, щоб згенерувати цей код. Наприклад, припустимо, що є помилка у файлі, що містить 800 рядків коду. Тепер уявіть, що реальна проблема виявлена лише в одному з цих 800 рядків. Чи має сенс сидіти перед монітором п'ять хвилин, спостерігаючи, як GPT регенерує 799 рядків, які йому не потрібні? Ні, не має.
І ось ще одна проблема:
У міру зростання довжини коду пам'ять ChatGPT погіршується. Що в кінцевому підсумку відбувається, якщо дозволяти йому регенерувати дуже довгі розділи коду, то це те, що він не тільки підправить проблемні рядки, які потрібно налагодити, але й випадково змінить інші рядки. Отже, можна виправити помилку, яку хотіли виправити, але отримати нову помилку(и). Якщо продовжувати робити це тим самим способом, можна залишитися в нескінченному циклі налагодження.
Як покращити цей крок
При налагодженні обов'язково включайте у підказки дуже конкретні інструкції для ChatGPT, щоб він залишався гранично зосередженим. Після кількох спроб і помилок я виявив, що добре працює наступне:
- Будь ласка, не перетворюй весь файл.
- Проаналізуй і виділи конкретні рядки коду, які, на твою думку, викликають проблему і покажи їх мені.
- Пояснить, що саме у цих рядках, на твою думку, може бути проблемою.
- Потім поясніть, як збираєтеся змінити рядки і який результат очікуєте отримати в результаті цих змін.
- Нарешті, будь ласка, надай мені оновлені рядки у фрагменті коду, щоб можна було їх скопіювати та вставити.
Помилка №4: Використання простого CSS замість BEM CSS
Якщо є один загальний висновок, який я засвоїв, використовуючи ChatGPT для створення плагіна, то це те, що ChatGPT любить давати максимально можливий мінімальний життєздатний код. Його робочий принцип — «якщо це працює, то це досить добре».
Щоб стати краще, ніж досить добре, Треба заявити про це привселюдно. Тому раніше наголошувалося, що слід із самого початку дотримуватися стандартів кодування WordPress. Однак це не єдина сфера, де потрібно висловитися. Також потрібно зробити це з будь-яким кодом CSS, що GPT генерує для вас.
Я не усвідомлював цього, доки не заглибився у свій процес. І лише тому, що Claude вказав мені на це при вирішенні іншої проблеми.
Я використовував CSS за промовчанням, який давав ChatGPT, і це працювало, але це був стандартний CSS, який можна отримати на вступному курсі CSS. Для ясності, стандартний CSS не є «неправильним», але це не те, що потрібно для створення плагіна WordPress.
Проблема з використанням стандартного CSS полягає в тому, що якщо використовується клас з ім'ям "body" або "sidebar", то можна перешкодити іншим елементам WordPress, які також використовують те саме ім'я класу (наприклад, елементи в темі або іншому плагіні). BEM є найкращим підходом, тому що він структурований таким чином, що імена класів є специфічними тільки для вашого плагіна. Таким чином, він запобігає будь-яким потенційним конфліктам коду.
Як це покращити
Тут особливо нема чого сказати. Все дуже просто. Як тільки досягнете точки, де GPT буде генерувати код CSS, дайте йому вказівку слідувати за методологією BEM (Блок, Елемент, Модифікатор). Рекомендую також, якщо потрібно буде переглянути свій CSS у будь-який момент у майбутньому, включити нагадування у підказку про те, що використовується BEM.
Помилка №5: Передбачалося, що існує лише один глобальний лінтер
З усіх помилок у цьому списку ця, мабуть, найганебніша. Здавалося, це був такий здоровий глузд, коли Claude звернув мою увагу на те, що причина відсутності прогресу в лінтингу мого JavaScript-файлу в тому, що використовувався той же лінтер, що і для PHP-файлу.
Найприкріше, що витративши кілька годин у листуванні, ChatGPT із цього приводу нічого не сказав. Він ясно бачив, що я використовую PHP-лінтер у файлі JavaScript, але з якоїсь причини не вважав за потрібне вказати на це. Натомість він просто нескінченно намагався змусити мене вставити квадратний кілочок у круглий отвір:
Так я нічого не досяг від GPT, то довелося запитати у Claude. А Claude одразу помітив проблему.
Що працює краще
Це ще одне просте питання: переконайтеся, що ви використовуєте правильний лінтер для кожного з файлів. Три, які зрештою використовувалися:
- PHP_CodeSnifferс WordPress-Coding-Standards для лінтингу PHP.
- ESLint для аналізу JavaScript (Детальніше).
- StyleLint для аналізу CSS (Детальніше).
Помилка №6: Глобальне розміщення скриптів у черзі
Пам'ятайте, що йшлося у розділі CSS про принцип роботи GPT: «якщо це працює, це досить добре»?
Це можна застосувати і тут.
Якщо не вказати ChatGPT інше, коли настане час ставити скрипти (або стилі) у чергу, він зробить це глобально. Саме це й сталося зі мною. На жаль, я не помітив цього, доки не скористався інструментом перевірки плагінів, наданим командою розробників WordPress. Озираючись назад, розумію, що слід використовувати його набагато раніше, ніж це зробив. Розповім про цю помилку трохи згодом.
Глобальне розміщення скриптів - це означає, що файли JavaScript та CSS завантажуватимуться на кожній сторінці будь-якого сайту WordPress, на якому встановлено плагін. Є деякі випадки, коли це дійсно потрібно. Тож це не жорстке правило «ніколи цього не робіть». Однак у багатьох випадках це еквівалентно використанню кувалди для забивання цвяха: ефективно, але невиправдано сильно та широко.
На практиці це нашкодить будь-якому сайту, який використовує плагін через надмірний розподіл ресурсів сайту марнотратним чином. В результаті сайт може зазнавати збільшення часу завантаження, що потім призводить до розчарування користувачів. Якщо це досить погано, це може навіть пошкодити рейтинг сайту в пошуковій системі.
Як зробити краще
Якщо скрипт дійсно не потрібно ставити в чергу глобально, правильний спосіб зробити це використовувати те, що називається «умовним завантаженням». Цей метод має на увазі завантаження скриптів лише там, де вони абсолютно необхідні. Наприклад, якщо плагін впливає лише на сторінки постів, потрібно переконатися, що скрипти завантажуються тільки на цих сторінках.
Можна досягти цього, використовуючи умовні теги WordPress. Наприклад, використовуйте is_single()щоб перевірити, чи відображається окремий пост WordPress, а потім поставте свій скрипт у чергу. Ось як це може виглядати:
function enqueue_my_plugin_scripts() {
if (is_single()) {
wp_enqueue_script('my-custom-script', plugin_dir_url(__FILE__) . 'js/my-custom-script.js', array('jquery'), null, true);
}
}
add_action('wp_enqueue_scripts', 'enqueue_my_plugin_scripts');
Наведений вище фрагмент перевіряє, чи завантажується сторінка одним постом, і лише потім ставить у чергу файл JavaScript. Такий підхід гарантує, що скрипти будуть завантажені лише за необхідності. Це робить плагін більш ефективним та знижує ймовірність конфліктів з іншими частинами WordPress.
Помилка №7: Я не зменшив розміру своїх скриптів
Мініфікація скриптів технічно необов'язкова. Насправді, це просто спосіб оптимізувати продуктивність плагіна. Тому це можна не відносити до справжньої помилки так само, як і інші пункти цього списку. Тим не менш це корисно, і це те, що було втрачено з поля зору у початковій збірці. Тільки коли я почав розбиратися із проблемою чергизації вище, наткнувся на неї та вирішив реалізувати.
Однак мініфікація - це те, що абсолютно точно можна зробити пізніше у процесі роботи. Після налагодження та лінтингу, як мені здається. Тому не включатиму сюди розділ «Що, на мою думку, працює краще». Натомість просто поділюся ресурсом, де можна мініфікувати свої JavaScript- та CSS-файли.
Помилка №8: Дочекалися кінця, щоб скористатися офіційною перевіркою плагінів
Якщо ви вирішили, що хочете відправити свій плагін до репозиторію WordPress для перевірки, потрібно буде заздалегідь виконати контрольний список дій. Одним із пунктів цього контрольного списку є встановлення та використання офіційного засоби перевірки плагінів від команди розробників:
Помилка полягає в тому, що я чекав, поки закінчу все, щоб зробити це, дивився на це як на формальність, а не як щось справді корисне. Вважав, що між лінтингом, налагодженням та тестуванням вийде чистий результат. Ну, скажімо, неправильно було так думати.
Помилка у моєму мисленні виникла через те, що різні інструменти перевіряють різні речі. Це схоже на помилку у припущенні, що є глобальний лінтер. Цей плагін перевіряє дуже конкретні речі, але ці речі не обов'язково будуть відображатись як червоні прапорці під час інших процесів, які я вже завершив.
На щастя, більшість того, що виявилося після того, як інструмент закінчив сканування, можна було легко виправити. Однак у коді був один слон, на якого не звернув уваги: скрипти із глобальною чергою!
Як краще це зробити
Як можна собі уявити, було б набагато корисніше, якби проблема із постановкою в чергу виявилася раніше. На цьому етапі вже були видалені всі файли тестування та лінтингу з каталогу плагінів та готував його до відправки. Щоб дати раду цьому, мені довелося повторити всі попередні кроки після виправлення коду.
Отже, востаннє – ось що, на мою думку, працює краще. Запускайте перевірку плагінів, коли або лінтуєте, або налагоджує. Таким чином, можна вирішити все, що виникне набагато раніше, і останній запуск дійсно буде формальністю.
Сподіваюся, що інформація про помилки була пізнавальною. Стаття написана в основному для того, щоб допомогти іншим, хто замислюється над створенням свого першого плагіна без будь-якого формального навчання.
Мартін Дубович
Джерело: wpshout.com
Коментарі до запису: 0