Що робити, коли фрилансер здає зламаний код

Що робити, коли фрилансер здає зламаний код

Зламаний код — це не те саме, що звичайний баг, і саме тому фраза «зламаний код фрилансер» так часто описує ситуацію, коли проблема вже вийшла за межі дрібного виправлення. Звичайний баг з’являється у функції, яка здебільшого працює; зламаний код може зупинити реліз, заблокувати вхід у систему або зробити файл непридатним уже в перший день. Ця різниця важлива, бо ваш наступний крок має відповідати масштабу шкоди, а не настрою.

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

Що вважається «зламаним кодом», а що — звичайним багом?

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

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

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

Що перевірити насамперед, перш ніж писати фрилансеру?

Відтворіть проблему один раз, перш ніж писати. Два рази — ще краще. Використайте той самий браузер, той самий пристрій і той самий акаунт, якщо це можливо. Запишіть, що саме ви натиснули, що сталося і де з’явилася помилка. Фраза «не працює» надто загальна, щоб комусь допомогти.

Потім зафіксуйте середовище. Запишіть назву й версію браузера, операційну систему, URL сервера, а також чи використовували ви staging або production. Код, що працює в Chrome на ноутбуці, може зламатися в Safari на телефоні, і ця різниця може зекономити багато зайвого листування.

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

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

Як повідомити про зламаний код, не перетворивши це на суперечку?

Перший меседж має бути коротким, фактичним і з датою. Якщо вам потрібно знати, як повідомити фрилансеру про баг у коді, то добра структура така: 1) що саме зламалося, 2) де це сталося, 3) чого ви очікували, 4) що вам потрібно далі. Цього достатньо, щоб почати розмову про виправлення без звинувачень.

Приклад: «На staging-сайті контактна форма повертає помилку 500 після надсилання. Я очікував, що форма відправить повідомлення і покаже підтвердження. Я додав скриншот і лог консолі. Будь ласка, підтвердьте причину та надішліть виправлення або скориговану збірку».

Таке формулювання не залишає місця для театру. Воно також допомагає уникнути пастки, коли ви звинувачуєте фрилансера в намірі, який усе одно не можете довести. Тримайте речення про наслідок конкретним: «клієнти не можуть оформити замовлення», «адмінпанель зависає» або «експортований файл порожній». Ці деталі важливіші за емоції.

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

Які докази варто надіслати, щоб фрилансер виправив проблему швидше?

Надішліть кроки відтворення в правильному порядку, а не в форматі історії. Крок 1: увійти в систему. Крок 2: відкрити дашборд. Крок 3: натиснути Export. Крок 4: завантаження не спрацьовує. Такий список дає змогу фрилансеру точно повторити ваш шлях.

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

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

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

Коли варто просити виправлення, відкат або повернення коштів?

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

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

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

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

Що робити, якщо фрилансер каже, що в нього код працює?

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

Попросіть точне середовище, яке використовував фрилансер. Запросіть номери версій, кроки встановлення та будь-які ручні дії, які він виконував після клонування або завантаження. Якщо вам кажуть «локально працювало», вам потрібен локальний рецепт, а не запевнення. У цьому й суть.

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

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

Коли зламаний код стає проблемою передачі або власності?

Зламаний код стає проблемою передачі, коли файли надходять без кроків, потрібних для запуску. Сюди входять відсутні інструкції зі встановлення, відсутні дані доступу, відсутні файли середовища та відсутні інструкції з деплою. Код може бути на місці; володіння — ні.

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

У такому разі проблема не лише в «виправити цей баг». Питання звучить так: «Чи зможе моя команда взагалі прийняти цю роботу?» Якщо ні, то поставка неповна, навіть якщо всі файли виглядають охайно. Саме тут правила правила сайту 24freelance.pro. freelance можуть стати корисною точкою відліку для того, як слід поводитися з роботою, файлами та комунікацією.

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

Як запобігти такій самій проблемі з поставкою наступного разу?

Напишіть критерії приймання ще до початку роботи. Не абзац. Список. «Вхід у систему працює з коректними даними». «Експорт створює CSV із 3 колонками». «Форма відправляє лист і показує повідомлення про успіх». Такі рядки роблять зламаний код помітнішим, бо ціль стає видимою.

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

Визначте «готово» одним реченням, яке включає файли, доступи та підтвердження. Наприклад: «Готово означає, що код запускається на нашому staging-сервері, README містить кроки налаштування, а тестовий акаунт підтверджує основний сценарій». Це не врятує від поганої роботи, але зробить її видимою раніше.

Для складних завдань просіть коротку нотатку передачі. Навіть 5 пунктів можуть зекономити вам час потім: середовище, залежності, відомі обмеження, тестові дані та хто відповідає за наступний крок. Невелике прохання — великий зиск.

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