Створення відеогри на асемблері, модуль для обробки зображень, вірус із кодом, що мутує. Як ІТ-спеціалісти розв’язують складні завдання
У роботі будь-якого програміста серед буденних завдань може з’явитись «задача із зірочкою». Пошуки її розв’язання вимагають багато часу та зусиль, проте підвищують кваліфікацію і зрештою стають приводом для гордості. Добре, коли є де шукати розв’язку: можна спитати на DOU або гуглити — варіанти точно знайдуться. Але так було не завжди. Наприклад, у
Редакція DOU попросила ІТ-спеціалістів поділитися розповідями про складні та цікаві завдання, які доводилось розв’язувати.
Ілюстрації Уляни Патоки
Посунути EditBox на формі
Іван Маламен, DevOps Team Lead в Allianz Gruppe, 15 років в ІТ
Це було давно, на той момент я вже був ознайомлений з чудовим світом C# .NET і навіть устиг про нього забути. Я мав швидко виправити критичний (на думку Product Owner) баг перед релізом для іншої команди. А все тому, що лише я був онлайн о 3:00 ночі (хоча в офісі у Пало-Альто була 17:00) і, на жаль, мав досвід з WinForms. Завдання здалося простим — посунути EditBox на формі. У підсумку це вилилося в кілька годин роботи.
Це був великий додаток з купою залежностей і нетривіальним білд-процесом:
- велика частина залежностей не була описана в документації;
- частина залежностей була для певних версій, які треба було знайти і підв’язати;
- як виявилося, існували певні змінні середовища, які потрібно було визначити перед запуском білду (і вони теж не були прописані в документації).
Що робив
Загалом бракувало хорошої документації та довелося багато копатися в білд-скриптах. І в підсумку написати власний, який зарефакторив усі інші. Я читав мануал, написаний іншою командою, гуглив, шукав на Stack Overflow, щоб виправити помилки білду. Підійшов до питання просто: зосередився і почав копати глибше. Мені подобається не так процес пошуку рішення, як момент усвідомлення, що воно знайдене і залишилося його правильно упакувати та протестувати.
Уся підготовка, встановлення студії та пререквізитів, білд-процес і прогін базових юніт-тестів забрали близько двох годин. Сам фікс — дві хвилини. У результаті за роботу отримав додатковий вихідний і респект від замовника.
Порада
Не варто соромитися і боятися запитати у більш досвідчених колег. На Stack Overflow є далеко не всі рішення ;)
Computer Vision і Deep Learning у керуванні шинами для великих транспортних компаній
Олег Лещинський, Software Engineer в INFINIDAT, 12 років в ІТ
З
Наш продукт — система керування шинами для великих транспортних компаній. Головна особливість — технологія ідентифікації та безконтактного вимірювання тиску, зношеності та температури шин на колесах транспортного засобу, що рухається через пункт вимірювання.
Іншими словами, на в’їзді або виїзді з місця стоянки або завантаження/розвантаження (де швидкість руху не буде перевищувати 30 км/год) було встановлено два бокси з камерами та сенсором температури. Під час проїзду кадри з колесами та покази температурного сенсора зберігалися (1) та оброблялися (2).
Результати обробки надсилалися на сервери системи, де на основі інформації про моделі транспортних засобів та встановлених шин рахувалися тиск і зношеність (3). Далі система надсилала повідомлення власниками транспорту про результати вимірювання, коли виникала потреба, та оновлювала масив даних BI. Клієнт мав власний інтерфейс до системи для отримання повідомлень і надання реальних даних заради поліпшення точності та коректності результатів. (4)
Тепер щодо стека технологій і труднощів. (1) Для захоплення кадрів використовували індустріальні камери. Ми переглянули кілька брендів, але зупинилися на Basler GigE через нескладний C++ API та гарантію, що обрана модель буде в продажу та матиме підтримку не менше як 5 років. Оскільки об’єкти зйомки рухалися, час експозиції не мав перевищувати дві мілісекунди. Тому як спалах ми використали дешеву китайську копію потужного стробоскопа, сигнал від якого через комутатор з таймером використовувався для синхронізації камер. Кожна камера видавала 200 МБ/c кадрів без компресії з частотою 60 кадрів на секунду.
Про обробку в реальному часі на обраній конфігурації навіть не йшлося, тому через буфер у пам’яті захоплені кадри записувалися на кілька HDD для подальшої роботи. У результаті ми стикнулися з проблемою затримок під час алокації та вивільнення пам’яті, при комунікації з іншими компонентами та потоками. Доступність імплементації C++11 з моделлю пам’яті для багатопоточності спростила реалізацію цього компонента. Швидкість Redis і ZeroMQ дала змогу зменшити затримки в комунікації.
(2) Подальша обробка була заснована на нейронних мережах та інших інструментах Machine Learning та Computer Vision і написана на Python. Навіть компоненти, що з початку розробили в MATLAB, зрештою переписали на Python. За кілька ітерацій архітектура трансформувалася у топологію компонентів, що спілкувалися один з одним через List та SortedSet у Redis. Водночас кожен компонент мав просту внутрішню структуру: заблокуватись на отриманні елемента з Ingress, після отримання виконати операцію, записати результат в Egress.
На той момент я не знав, що теорія з
У результаті обробки сотні мегабайтів перетворювалися у сто байтів вимірювань, що можна було без проблем надсилати. Трохи складності додавало те, що ми перебували в Ізраїлі, а системи встановлювали в Бразилії та Канаді на стоянках вантажівок, де нічого було.
(3) Тому бекенд і бекофіс були зроблені на Tornado (сервер від Facebook) і PostgreSQL. Основний час пішов на правильну дефініцію моделі даних (багато нормалізованих таблиць) і написання всіх процедур та запитів, PL/pgSQL і SQL. Через розмір моделі даних я вирішив відмовитися від готового ORM та написав мінімальну власну реалізацію.
(4) Фронтенд (як для наших інструментів, так і для інтерфейсу клієнтів) мав кілька перетворень. Перші версії були на Backbone, частину віддали на аутсорс (згодом довелося викинути, тому що обрали швидко й за низьку ціну). Остаточний варіант був на React з власним керуванням стану сесії та комунікацією з бекендом (здається, Redux ще не було або я про нього не знав).
Складним проєкт був тому, що у
Цю проблему було цікаво розв’язувати, оскільки перша реакція оточення: «Це неможливо на нинішньому рівні технологій за реальні гроші». Навіть коли система давала результат, знаходилися ті, хто заперечував побачене на власні очі.
Що робив
І гуглив, і запитував, і код читав, щоб зрозуміти, чому результат не відповідає очікуванням.
Читав статті з фізики гумових шин. Заглядав у документацію на медичні системи, щоб зрозуміти, як правильно обробляти великі масиви зображень. Читав підручники з алгоритмів (базові та Computer Vision), щоб не загубитися в складних машинах станів і робити оптимізації на основі separable kernels. Читав код systemd, щоб з’ясувати, як керувати виділенням часу CPU на різні потоки.
Було в кого й спитати: усі в компанії незалежно від позиції були інженерами (прикладна математика, медичне устаткування, механіка, аерокосмічні технології), тому розв’язували проблеми разом. Якщо внутрішньої експертизи бракувало, зверталися до знайомих з інших компаній, що могли дати пораду (як, наприклад, одразу зробити калібрацію всього, а не окремо калібрацію камер з лінзами, а потім стереопари. Це схоже на махлювання, але результат дає кращий).
У результаті і технологію, і систему на її основі ми побудували (див. патент). Як це часто буває зі стартапами, у якийсь момент гроші скінчилися. Потенційні інвестори трохи зачекали й отримали технологію на ліквідаційному розпродажу (тепер належить Goodyear).
Моя робота як Senior Software Engineer — розв’язувати проблеми за допомогою комп’ютерів. Для проблем, які відомо, як розв’язувати, є інженери рівня Junior-Middle.
Порада
Пам’ятайте, що не всі проблеми можливо розв’язати. Трапляється, що складно сформульована проблема зводиться до «перевищити швидкість світла ось на цій ділянці простору» або «повернутися у часі на кілька секунд».
Якщо рішення в проблеми є, але ви його не можете знайти, не забувайте, що дорослі дядьки з окулярами та бородою десятки років пишуть книжки про теорії масового обслуговування, розподілені системи, теорії алгоритмів, математичну статистику та інше. Здебільшого відповідь можна знайти там.
Ну й піти поспати. Можливо, ви вже знайшли вирішення, але дізнаєтеся про це, коли прокинетеся.
Вірус, що мутував свій код
Валентин Колесников, Java/Spring Developer в Astound Commerce, 23 роки в ІТ
Це було восени
Раніше цією проблемою займалися прості розшифровувачі. Існувало багато інструкцій, які потрібно було емулювати, щоб розв’язати проблему. І це було цікаво.
Що робив
Я написав емулятор. Інакше було ніяк. Довелося розбиратися в інструкції процесора і проводити тестування. Детектор написали й додали в оновлення антивірусних баз. Для цього знадобилося три тижні.
Порада
Пробуйте різні варіанти. Організуйте тестування алгоритму.
Налаштування ваг без DLL-бібліотеки
Ігор Кравченко, С# Developer, 3 роки досвіду в ІТ
Одного разу мені довелося реалізувати записування товарів і цін у магазинні ваги Bizerba. Ці ваги вважаються одними з найкращих. Але виробник не реалізував до них жодної нормальної
В інтернеті я знайшов бібліотеку від постачальника обладнання. Але проблема була в тому, що під час надсилання даних ця бібліотека десь займала UI-потік, що блокувало інтерфейс мого додатку. Тому вирішив піти найнуднішим шляхом і розглянути офіційний посібник з програмування ваг. Цей «посібник» був схожий на таблицю з командами, де було незрозуміло, у якій послідовності їх викликати. Щоб викликати команду, потрібно було надіслати вагам масив байтів. Та в цьому не було труднощів, бо раніше я вже з’єднував Bluetooth-принтери з андроїдом, де теж доводилось надсилати масив байтів принтеру.
Проблема з вагами полягала в тому, що не було результату, хоч, здавалося, я робив усе правильно. Виявилося, треба надсилати команди в певній послідовності, чого не описали в посібнику.
Що робив
Я вирішив «прослухати» запити, які надсилає готова бібліотека. Бо все-таки вона записувала дані у ваги, хоч і проривалась в UI-потік. Я встановив аналізатор трафіку, подивився, яка там послідовність байтів, і зробив так само у своєму коді. Це спрацювало! До речі, мій колега, який уже додавав два інших принтери до цього застосунку, сказав, що такого жахливого виробника ваг ще не бачив. Хоча він вважається крутим. Потім мені довелось налаштовувати етикетку на вагах, щоб подивитись, чи друкується правильна ціна. І ще кілька годин я витратив на те, щоб зрозуміти, як це зробити.
У результаті мені все вдалося, але це зайняло приблизно тиждень.
Порада
Деколи потрібно на певний час відкласти завдання і зайнятись чимось іншим. Після цього думки структуруються і рішення може з’явитися саме собою.
Дописування чужої програми, яка перевіряє стан апаратного порту
Сергій Факас, Information Security Officer в Oro Inc., 30 рік в ІТ
Це був 1993 рік. Моя перша робота після інституту в цікавій конторі у відділі з начальником-полковником. Це були часи MS DOS і PC зі спеціальною платою, яка вміє читати телеграфну передачу. Мені треба було дописати програму, яка перевіряла стан апаратного порту. Якщо в ньому щось було, вона вичитувала дані з плати, показувала їх на екрані та писала у файл. Програма була не моя, написана на Borland Pascal з використанням сторонньої бібліотеки з «рюшечками» (здається, Turbo Utilities). Автор звільнився, а програма час від часу висла. При чому в MS DOS «висла» означало, що треба робити хард-ресет усього компа. Це також означало, що жодні логи не пишуться і матеріальних слідів причини зависання не було. Дебагінг не допомагав, бо зависання не було регулярним і не виникало на певному шматку програми.
Що робив
Тільки хардкор, тільки аналіз коду. Довго мучився, але знайшов причину — красива стороння бібліотека серед іншого показувала на екрані годинник у верхньому куточку. Щоб читати значення годинника з ОС автор бібліотеки поставив обробник на функцію переривання 21H. Це всі функції MS DOS. Але програма з обробника однієї функції переривання 21H писала на диск за допомогою іншої функції того ж переривання 21H. Це було заборонено і призводило до нерентабельності DOS. Можна назвати цей кернел панікою по-сучасному, але без будь-якого дампу :) — MS DOS просто припиняла роботу.
Видалення годинника виправило ситуацію. Бібліотеку я прокляв і написав свій годинничок, але вже на обробнику переривання BIOS 15H. З того часу, до речі, не люблю «рюшечки» заради «рюшечок» і сторонні бібліотеки без нормальної структури.
Завдання здавалося складним, бо це був 1993 рік. А ще тому, що я доробляв чужу програму, яка працювала нестабільно. MS DOS не мала інструментів, щоб виявити причину нестабільності, через свою архітектуру та однозадачність. Гуглу не було. Спитати особливо не мав у кого.
Програму пофіксив, написав ще одну для того ж «заліза».
Порада
Думайте. Відступіть на крок і подивіться на загальну проблему. Аналізуйте від самих основ — що на вході, чому, що треба отримати. Якщо працюєте в команді — зберіть усі факти, будуйте на них гіпотези й перевіряйте їх фактами та тестуванням.
Розробка рушія для продовжень ігор серії «Козаки»
Андрій Фролов, R&D Technical Lead у Skylum Software, 20 років досвіду в ІТ
У 2002 році під час розробки рушія для продовжень ігор серії «Козаки» постало завдання оптимального зберігання та водночас швидкого відтворення безлічі спрайтів юнітів за допомогою відеокарти. Юніти — набір кадрів у вигляді растрових файлів. Їх потрібно було розмістити в текстурах для подальшого використання в GPU. А ще скласти двовимірну сітку з трикутників для виведення на екран.
Основний виклик — дотримати балансу між мінімальною кількістю трикутників і максимальною щільністю упакування спрайтів на текстуру. Це було частиною одного з моїх перших завдань, для виконання якого мене взяли на роботу в GSC. Тож я не міг його провалити.
Що робив
У той час не було поняття «гуглити» в нинішньому розумінні, інформації було мало. Максимум, на що можна було розраховувати, — деякі тематичні форуми та домашні сторінки ентузіастів. Ну й нечисленні тематичні книжкові видання. Я вирішив використовувати «обхід» кордону спрайту юніта зв’язковим контуром, після чого зменшувати кількість точок у контурі за допомогою послідовних «послаблень» і «натягувань» на зразок гумової стрічки. У точках перегину контуру робився відступ назовні, після чого точки контуру віддалялися на ділянках, близьких до прямої. Пізніше я дізнався, що схожий підхід нерідко застосовують у методах оптимізації.
Далі постало питання, як це тріангулювати. За порадами колеги звернувся до ідеї тріангуляції Делоне. Винайшов метод обходу за допомогою лівої/правої руки, освоїв тріангуляцію Делоне, використаний метод заливки ділянок за допомогою контуру як фронту за аналогією з хвильовим алгоритмом. Це згодом часто застосовувалося в інших цікавих додатках.
У результаті вдалося побудувати систему з доброю щільністю упакування трикутників. Цей метод був схожий на «запікання» lightmaps, про який я теж незабаром дізнався.
Юніти, що лежали на текстурах, були розбиті на трикутники і перемішані для більш щільного пакування.
Я працював разом з Андрієм Шпагіним, головним програмістом «Козаків», і поділяв його підхід: шукати вирішення проблем «своїм розумом», часто навіть там, де можна застосувати готові рішення. Але готових рішень у той час було не так багато, знайти їх було складно, а вирішувати складні завдання — основна радість програміста.
Порада
Для конкурентоздатності на ринку треба максимально використовувати готові рішення, але лише в тому разі, якщо ідеї, що лежать в їхній основі, є зрозумілими. І бути готовим зробити все самостійно. Що більше в голові є сутностей, оформлених досвідом, то простіше підсвідомості скласти з них пазл. Це і стане розв’язком проблеми. Варто вивчати те, що є, намагатися придумати нове і застосувати різні підходи. І крутити питанням у різні боки, і в підсумку рішення прийде одного разу вранці, тільки встигай записувати :)
Розробка модуля для обробки зображень дистанційного зондування Землі
Олександр Маковейчук, MATLAB Developer в Abto Software, 29 років в ІТ
Це було на початку 2000 року. Завдання — розробити модуль для обробки зображень дистанційного зондування Землі. Обробка відбувалася на цифрових сигнальних процесорах (DSP) фірми Texas Instruments. Частина алгоритмів використовувала швидке перетворення Фур’є, одновимірне, але перехід до двовимірного є простим — достатньо зробити два проходи, по рядках і стовпцях відповідно. Щоб вкластися у вимоги зі швидкодії, було запропоновано реалізувати FFT на асемблері.
Завдання було складним, оскільки я НІКОЛИ не програмував DSP. Треба було з нуля розбиратися в архітектурі процесора і вчити асемблер.
Що робив
Класичний спосіб: якщо нічого не допомагає, читайте документацію. Ну й пошук в інтернеті — здебільшого на спеціалізованих форумах.
Маючи математичну підготовку (за освітою фізик-теоретик), з розумінням FFT і імплементації на С особливих проблем не виникло. TI Code Composer Studio давало змогу дивитися результат перекладу з С на асемблер. Витискалося максимум з того, що давала автоматична оптимізація. Далі йшла ручна оптимізація коду (перехід до цілочисельної арифметики, заміна ділення зсувами тощо). Проблема була в тому, щоб підвищити швидкодію приблизно на 20 відсотків.
Завдання було виконане, усе працювало як треба, і ми успішно здали виріб замовнику. Але надалі я позиціонувався більше як розробник алгоритмів, а не Embedded Developer. Хоча розуміння того, як воно працює під капотом, — неоціненне. Це був гарний досвід!
Порада
Якщо ви зайшли у глухий кут — озирніться навколо! Можливо, розв’язок не там, де ви шукали, а на сусідній поличці. І ще — немає непотрібного досвіду і непотрібних знань. Усе можна використати, усе колись обов’язково знадобиться.
Семантичний розбір питання і генерація відповіді на базі формальної граматики
Дмитро Мірошник, Lead QA Automation Engineer у Mensch, 15 років в ІТ
Завдання полягало в написанні дипломної роботи на тему «Семантичний розбір питання і генерація відповіді на базі формальної граматики». Тему придумав сам, як, власне, і її реалізацію.
Це було у 2004 році, я закінчував
Складність завдання полягала в тому, що таких алгоритмів на той момент не існувало. Вони почали масово з’являтися 2006 року, відповідно почитати та імплементувати готову теорію або скористатися вже готовим фреймворком було неможливо. Рішення, які існували на той момент, вміли вишукувати ключові слова в реченні й на базі одного або кількох будували відповідь. Вона складалася зі слів із введеної користувачем фрази, що приводило до безлічі кумедних ситуацій. Деякі з них були навіть на Bash.org. У цьому полягав весь кайф завдання! Написати алгоритм, який не тільки буде реагувати на ключові слова, а намагатися зрозуміти сенс введеного речення.
Що робив
Шукати рішення було ніде, публікацій на цю тему не існувало. Довелося вигадувати самому. Дівчина допомогла з формалізацією граматики: накидала речення, я намагався їх пов’язувати в граматику. Якщо щось не працювало, доводилося переробляти граматику :)
Граматика — це набір лексем. Типу такого:
<Пропозиція> :: = <питальне речення> | <Стверджувальне речення>
<Питальне речення> :: = <питальне речення тип 1> | <Питальне речення тип 2> | ...
<Питальне речення тип 1> :: = do <суб’єкт> <дію> <об’єкт>
<Питальне речення тип 2> :: = do <суб’єкт> <дію> <дію> ing
<Питальне речення тип 3> :: = do <суб’єкт> <дію> <інфінітив>
Завдання — продумати максимальну кількість різних лексичних форм. Якщо під одну лексему підходило кілька різних за змістом речень — значить, базові лексичні форми не атомарні й треба визначати інші лексеми та перебудовувати граматику.
Рішення було на стику семантики та інтерпретаторів. Інтерпретатор використовує граматику мови, щоб розкласти текст програми на структурні складові (цикл, привласнення, умова тощо) і потім виконати їх, тобто намагається «зрозуміти» програму. Я використав схожу методику. Замінив граматику мови програмування на англійську, описав суті та взаємозв’язок між ними (питання, твердження, об’єкт, суб’єкт). Відтак написав інтерпретатор отриманої мови, у БД прописав приклади об’єктів, суб’єктів і їхні характеристики — профіт! Для
У результаті отримав п’ятірку :) І жодного серйозного запитання від комісії — ніхто нічого не зрозумів :))
Мені подобаються складні завдання. Вирішення однотипних завдань призводить до використання усталених нейронних зв’язків. Як у відомому анекдоті: «Одна звивина, та й та — слід від каски». Рішення з неочевидним алгоритмом, для якого не можна взяти готове зі Stack Overflow, та й узагалі вихід із зони комфорту сприяють генеруванню мозком нових нейронних зв’язків. Почуваєшся «більш живим», чи що. Останні кілька років я серйозно захопився яхтингом і зауважив, що під час походу думається набагато простіше і швидше. Адже довкола — абсолютно інші обставини, для яких немає напрацьованих патернів поведінки.
Порада
Розслабитися, відволіктися від завдання. Погуляти, пограти у футбол/теніс, поспати. Почати інше, не пов’язане з першим, завдання. А за добу чи дві повернутися до вихідних умов і подивитися, як можна просунутися у вирішенні.
Фішка в тому, що у мозку є два режими роботи. Назвемо їх «сконцентрований» і «розсіяний». Перший режим вмикається, коли людина активно думає над завданням. Наприклад, сидить і пише код. Тоді працюють близько розташовані нейрони та усталені нейронні зв’язки. Цей метод — хороший, якщо алгоритм завдання зрозумілий і треба написати рішення. Модель за моделлю, контролер за контролером... Усе просто і зрозуміло. Але що, як напрацьованого рішення немає?
У цьому разі в «сконцентрованому» режимі мозок почне ходити по колу, намагаючись застосувати напрацьовані патерни. Це призведе до втоми та нервового виснаження. «Розсіяний» режим — більш хитра штука. Він вмикається, коли людина НЕ думає над завданням свідомо. Пам’ятаєте відому історію про таблицю хімічних елементів, яка Менделєєву наснилася? Ось це воно і є! У схожому режимі мозок використовує нейрони, які не перебувають безпосередньо в напрацьованих зв’язках і утворює нові зв’язки. Іншими словами, якщо розв’язання задачі лежить у сфері не напрацьованих людиною рішень, у «розсіяному» режимі шанс його знайти набагато вищий. Часто це буде узагальнене рішення без конкретики. Тільки вказівка, куди копати. Головне — схопити це рішення «за хвіст» і доточити у «сконцентрованому» режимі. Коли вже ясно, які патерни і в якій послідовності застосувати. Ну й не забуваємо найпростіший спосіб: порадитися з колегою. Навіть якщо його відповідь буде неправильною або неточною, у ній може міститися ключовий натяк. І його буде достатньо, щоб зрушити все з мертвої точки.
Цікавих усім завдань і успішних рішень! ;)
Створення відеоігор на асемблері для ПК-01 у 90-х роках
Андрій Роговський, Senior DevOps Engineer, понад 15 років досвіду в ІТ
Завдання полягало у створенні відеоігор на асемблері для ПК-01. Надворі
Спочатку вирішити задачу не виходило. І не тільки через слабке «залізо», а й через відсутність системної документації від заводу-виготовлювача.
Що робив
Інтернет я знав тільки з книжок, в яких описувалась його міць. Шукав інформацію, де тільки міг — переважно у міських бібліотеках.
Я прочитав багато наукових праць, мені сподобалося, як там структуровано інформацію. З цього я теж склав структуру, за якою йшов: фреймворк розробки -> ігрові бібліотеки -> ігровий рушій -> ігрові ресурси -> тестування на друзях по двору -> комерційна реалізація на радіобазарі.
Із завданням я впорався. Результат кількох років роботи: від цього до цього. Потім зрозумів, що батьки купили мені комп’ютер не тієї моделі. Геймдев тих років був переважно на ZX Spectrum. Прибуток від гри міг бути набагато більшим :)
Вважаю, що жодних програмістських челенджів давно немає, вони залишилися в минулому. Якщо виникає помилка — шукаєш схожі. Якщо не знаходиш — відсилаєш опис бага з відтворенням. Чекаєш виправлення від розробника. Або фіксиш сам і надсилаєш пулреквест.
Порада
Подивитися на завдання під іншим кутом. Цілком можливо, воно не є критичним і його можна залишити на потім.
Тестування на основі відозапису зі скрінкастами програми
Анастасія Сергієнко, QA Lead SPD-Ukraine, 6 років в ІТ
Якось чотири роки тому мені надіслали тестове завдання — відеозапис — скрінкасти програми, яку потрібно було потестити. Моя робота полягала в тому, щоб знайти баги у відеозаписі, зарепортити їх і відіслати.
Завдання було складним, тому що я не могла зробити припущення і перевірити це самостійно. Якщо мені здавалося, що якась дія користувача працює не так, як належить, це не вдавалося перевірити в інших умовах. Я навіть не знала, що це за умови, в яких програма працює: яка це вісь, яке розширення екрана.
У мене не було доступу до логів або специфікації, а якість відео місцями не дозволяла навіть кнопку назвати правильно.
Було зрозуміло, що це завдання неможливо виконати ідеально. Ні придумати сценарії, ні порівняти поведінку в різних місцях — я могла тільки йти за рукою користувача.
Що робила
Я розібрала відео на скріншоти, проаналізувала кожен з них, вибрала сумнівні й зарепортила все за спадною імовірною значущістю. Таким чином зробила свою книжку з картинками-головоломками, де треба знайти предмет.
Тест я не пройшла. Сьогодні вже не пам’ятаю чому. Може, мені й не сказали. Напевно, книжка з картинками — не ідеальний спосіб для пошуку багів, особливо динамічних. Але виконувати завдання було весело саме через обмеження.
Нині за таке тестове я не взялася б. Кому потрібні одруки й помилки верстки, прості error-меседжі або випадні списки, що не випадають? Найцікавіші помилки — неочевидні, помилки в логіці, інтеграціях. Їх і шукати складно, і шкоди, якщо не знайти, від них багато.
Напевно, рівень викликів з того часу зріс. Складні завдання мені подобаються, поки я розумію, як їх вирішувати. Коли упираюся в багатоденний ступор, сумую і до завдання повертатися не хочу.
Порада
Колись прочитала про метод «йода-таймера» і тепер використовую його, коли треба вирішити щось зубодробильне. Елізер Юдковський сказав про цей метод так: «Ти просто не розумієш людську натуру. Люди не будуть старатись навіть п’ять хвилин перед тим, як здатися, нехай навіть на кону буде доля всього людства. Використовуй другу спробу». Метод полягає в тому, щоб ставити таймер на п’ять хвилин і всі п’ять хвилин чесно думати над проблемою. Іноді мені здається, що це не спрацює, бо «я ж уже два дні над нею думаю». Але щоразу з’ясовується: якщо не відволікатися на ниття і жаління себе, а сісти й подумати, то за п’ять хвилин можна придумати купу варіантів. І — найголовніше — вийти зі ступору.
Підписуйтеся на наш Telegram-канал «Редакція DOU», щоб залишатися в курсі найважливішого. Тут ми розміщуємо редакційні запити, проводимо опитування, а також публікуємо найцікавіші статті.
