Як факапить веб-розробнику

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

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

На щастя, технічний менеджер врятував мене, розповівши про нічний бек-ап бази даних компанії, і ми швидко усунули велику частину проблеми. Але до цього моменту я був весь на нервах. Будучи веб-розробником, ви будете помилятися – часто, а іноді і дуже сильно – незалежно від того, новачок ви або ветеран (наприклад, подивіться на цей недавній факап з сервісом веб-хостингу Amazon S3, в якому помилка призвела до зупинки таких величезних сервісів , як Trello і Quora).

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

Момент факапу: OMG AKS & A1LSKD !!!!.

  1. Ви облажались, причому конкретно. Код, над яким ви сиділи тижнями, а може, і місяцями, пройшовши через незліченні піци і еспресо, раптово сипле помилками. І не тільки не працює цей шматок, а й разом з ним пристойний шматок вашого веб-сайту, проекту і т.д. Хріново. Перш ніж засмучуватися, зробіть глибокий вдих і пам’ятайте, що 1) великі невдачі відбуваються регулярно у всій галузі і 2) малоймовірно, що ви втратите через це роботу. Я не знаю нікого, кого б звільнили за те, що він щось зламав в проекті. (В найгіршому випадку, попит на розробників великий, і ви швидко знайдете собі нову роботу). Досвідчені команди звикли до того, що завжди щось ламатиметься – і якщо вони ще не звикли до цього, то скоро звикнуть. Як лідер і член команди те, як ви реагуєте на помилку, може впливати на решту вашого колективу. Якщо ви зможете зберігати спокій і розуміти, що помилки це те, що можна виправити, члени вашої команди будуть відчувати себе більш комфортно і працювати більш ефективно. 

Занурюємося в проблему – розбираємося в зламаному коді

Перш за все: проаналізуйте і діагностуйте проблему. На жаль, це найскладніша частина. У телесеріалі «Містер Робот» є чудова фраза, персонажа Рамі Малека Елліота Алдерсона, інженера з кібербезпеки: «Більшість програмістів думають, що відладка програмного забезпечення – це виправлення помилок, але це нісенітниця. Насправді відладка – це пошук помилки, це про розуміння того, чому вона виникла, і про те, що її поява не було випадковістю».У моєму випадку я знав, чому я зламав сайт: я завантажив код, який спершу не протестував. Але найчастіше ви поняття не маєте, хто або що викликало помилку. Ваш інстинкт буде підказувати продебажити код і різні файли, переходячи від файлу до файлу, щоб з’ясувати: «Добре, тут викликана ця функцію. Де ця функція? “Цей процес може бути стомлюючим, трудомістким і хаотичним, в той час як суть помилки може бути усього лише дві пропущені букви.

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

Проговоріть це.

Як дізнатися, до яких помилок і поведінки схильні члени вашої команди? Комунікація. Коли ви налажали, поговоріть зі своєю командою і починайте брати ситуацію під контроль. Можливо, хтось може легко вирішити проблему або зізнається в тому, що є її винуватцем, або, як у моєму випадку, заспокоїть вас, сказавши: «О, не переживай, це можна виправити». Відкриті бесіди можуть вилікувати незліченні офісні недуги – навіть такі проблеми, як факапи в програмуванні, які ви, можливо, інстинктивно захочете залишити при собі. Одна з компаній, що надають найбільшу підтримку, в питаннях факапів – це сайт електронної комерції Etsy. Команда інженерів компанії веде блог Code as Craft, в якому регулярно ділиться досвідом, отриманим в цій області, а також регулярно проводить серію виступів, присвячених тенденціям в технологіях і програмуванні. Я думаю, що поряд з, можливо, Google, вони одні з найпалкіших прихильників написання високоякісного коду. Незважаючи на прагнення до великих висот або, можливо, через них, розробники Etsy час від часу роблять помилки. Але замість того, щоб засмучуватись, члени команди відкрито говорять про те, де вони облажалися, в блозі чи в електронному листі, адресованому всій компанії. Це не публічний осуд один одного, а, скоріше, можливість досліджувати факапи, які трапляються, з думкою, що це допоможе іншим не допустити їх. Розробники повинні прагнути до такого способу мислення. Наслідувати приклад Etsy і думати про програмування як про ремесло означає підходити до нього з тієї ж обережністю і вдумливістю, як і будь-який інший ремісник – дивитися на більш широку картину і обговорювати зі своїми колегами інструменти, методи і способи стати краще. . Відкриті бесіди можуть вилікувати незліченні офісні недуги – навіть такі проблеми, як факапи в програмуванні, які ви, можливо, інстинктивно захочете залишити при собі. Деякі компанії досягають цього за допомогою код рев’ю, коли програмісти показують свій код, а інша частина команди вносить пропозиції щодо його покращення. Код рев’ю може допомогти колегам краще зрозуміти мислення один одного і разом навчитися краще діагностувати проблеми. Залучення людей – чи то колег по роботі, колег з вашого коледжу або спільноти школи програмування або друзів з галузі – може дати вам зворотний зв’язок і попередити вас про помилки, які роблять інші. Це також дає можливість обмінюватися інформацією про процеси і підходи, які допомагають командам розробників залишатися сфокусованими та скрупульозними.

Великий фікс: відкрий свого внутрішнього розробника

Як тільки ви виявите помилку, швидше за все її можна швидко виправити. Але в ідеалі ви могли б уникнути ретельного проходження рядку за рядком в коді або обговорення проблеми з усією командою. Ви можете стрибнути на п’ять кроків вперед і здогадатися, де щось пішло не так. Тут доречна ще одна цитата містера Робота: «Баг ніколи не буває просто помилкою», – говорить Еліот. «Він є чимось більшим. Помилка мислення. Це робить вас тим, хто ви є». Якщо у вас є деякі знання про програму і, що більш важливо, про себе, фікс багів буде відбуватися набагато швидше. Хоча і те, і інше приходить з часом і досвідом, є коротші шляхи, які допоможуть вам досягти цього раніше. Коли ви друкуєте код, такі інструменти, як лінтери і компілятори, повідомляють вам, що ви допустили дуже просту помилку, наприклад, орфографічну або забули закриваючі або відкриваючі дужки. Це означає, що зазвичай, якщо баг дістався до продакшн середовщища, це не баг, а скоріше логічна помилка, яка виникає, коли ваші знання про те, як працює програма, невірні. «Баг ніколи не буває просто помилкою», – говорить Еліот. «Він є чимось більшим. Помилка мислення. Це робить вас тим, хто ви є ».

Знайдіть помилку в своєму мисленні. Дізнайтесь більше про себе.

Як інструктор з веб-розробки в General Assembly, я допомагаю студентам зрозуміти, що вони за розробники: які помилки вони здійснять, до яких типів помилок вони схильні і де вони здійснять помилки, думаючи про процес. Програмісти зазвичай діляться на тих, хто робить дурні помилки, і тих, хто допускає логічні помилки, але нюанси при цьому неймовірно складні. Один із способів почати розуміти свій стиль програмування – задати собі такі питання, як: чи схильні ви забувати знак рівності або неправильно оцінювати істинність змінних? Ви плутаєте порядок, в якому викликаються ваші функції? Вас збиває з пантелику асинхронний характер JavaScript? Або, можливо, ви відмінно вирішуєте всі задачі, але часто робите помилки набору. У всіх свій підхід, і тому всі роблять помилки зовсім по-різному. У GA ми даємо студентам домашні завдання, лабораторні роботи і проекти, розроблені спеціально так, щоб стати для них викликом. Для того, щоб кожен знав про різні типи проблем і знаходив закономірності в своїх роботах, ми часто виводимо помилки на екран, щоб весь клас міг їх побачити і проаналізувати. Ще один спосіб дізнатися про ваші типові помилки – вести журнал помилок, який деякі з моїх колег змушують своїх студентів вести на своїх курсах веб-розробки. Ведення журналу помилок змушує вас трохи більше думати про типи помилок, які ви робите. Якщо ви витрачаєте час на те, щоб записувати свої помилки, швидше за все, ви запам’ятаєте, що це те, що може повторитися в майбутньому. Як тільки ви дізнаєтеся, з якими проблемами ви, ймовірно, зіткнетеся, ви зможете використовувати ці знання для діагностики своїх майбутніх невдач. Пам’ятайте: помиляються навіть найдосвідченіші розробники. Але коли ви навчитеся справлятися зі своїми помилками з витонченістю і вдумливістю, а не з панікою, ви зможете запобігти майбутнім проблемам і отримати цінне уявлення про те, хто ви є. 

 

Всі статті
Контакти