Тонкое искусство дебага

Или то, что мы потеряли (ц) Чем дальше, тем больше вижу в индустрии людей, для которых «пойти и разобраться» титанический труд. Ручки из жопки, в глазу слезинка.

Дебаг — это отладка. Отладка — это «понять, почему оно вот там — вот так, чтобы сделать как надо». Применяется к любым системам вообще, потому что чем сложнее система, не важно из чего состоящая (техники, людей, процессов, явлений) — тем больше количественно шансов, что где-то внутри будет непознанная жопа, и вообще драконы заведутся.

Соответственно, чтобы такое делать, нужен набор навыков; прямо скажем отдельный скиллсет. Входят в него специфические навыки: аналитические, технические, логические, декомпозиция, понимание причинно-следственных, и далее и далее.

Мне кажется, на мой предвзятый взгляд, что просто поколение 90х-нулевых приобретало эти задатки на уровне бытового детско-юношеского любопытства. Любую техническую систему или хрень надо разобрать, попробовать починить, пару раз сломать в ненужных местах, собрать лучше чем было (пока по шапке не надавали), сделать выводы, пойти дальше.

Со схожим настроением я всегда смотрю на юношеские, пионерские увлечения детским хакингом (термин «скрипт-кидди» не просто так придумали). Всё, что можно поломать — будет подгрызено и испытано на прочность, кривыми руками и молочными зубами. Времени много, любопытства много, зубы руки чешутся.

Если к этому всему добавляются хоть сколько-нибудь работающие мозги, то скиллсет «разобраться и пересобрать» растёт ошеломляющими темпами.
То, что поначалу именуется «разобрать, починить изолентой и собрать из говна и палок» после 10+ лет опыта, если повезет, может отрасти в убедительный system design, навыки анализа данных, структурно-композиционную составляющую, инженерку & so on & so far.

Человек с развитыми навыками отладки на проекте — штука незаменимая, как раз для понимания «что у нас пошло не так» и, следом, «что тут вообще может пойти не так».

Второй вопрос можно вывезти на опыте, в принципе.
Первый — одним опытом не отделаешься.

• дебаг должен быть быстрым и точечным. Быстрым, чтобы вмешательство даже методом проб и ошибок давало локализацию проблем с минимальным временем нестабильности. Точечным — чтобы не сломать следом вдогонку то, что и так работало; а если да, столь же быстро локализовать проблемы и сузить сферу поиска
• дебаг должен быть научным. Не просто «гнём пока гнётся», а уметь выносить гипотезы, ставить моментальный эксперимент, и фиксировать ожидания к результатам
• дебаг должен быть осмысленным. Не просто знать «что пошло не так» (потому что если мы это знаем, то иди и чини), а знать, что вообще могло пойти не так в заданной системе, наблюдаемом явлении или инженерной отрасли. Это про опыт и насмотренность: непонятные проблемы тем и интересные, что их нужно понимать. Для этого нужна работающая понималка и багаж знаний
• дебаг должен быть аналитическим, что предполагает работу с данными, или хотя бы возможность эффективно разуть глаза, и посмотреть ими из черепа. Поиск отклонений, поиск аномалий, поиск и оценка взаимосвязей, поиск неучтенных факторов и важных (по факту) показателей

Параллель с хакингом (и его навыками) я привел совсем не случайно: из практических навыков это ближайшее, что у нас на практике есть, либо чему можно сравнительно быстро попробовать человека научить.

Только хакер, даже white-hat и пентестер, фокусируется на проблемы безопасности в первую очередь, а нам здесь интересны проблемы полезного действия для всей системы целиком.

Как я уже сказал ранее, даже не столько технические и инженерные системы придется рассматривать, а вообще любые: системы из процессов и людей ломаются не меньше, и их даже веселее отлаживать. Иногда это прям бизнесом называется: когда постоянная отладка = основной цикл работы, задача «найди здесь узкие места» = основная и несущая. Найдешь все проблемы — заработает твоя схема, все довольны, все танцуют.

Что я точно могу сказать:
— когда такие люди есть, и есть в количестве, работать с нештатными ситуациями сильно легче.

В чем основной вопрос, который беспокоит меня:
— я не знаю сейчас, как таких специалистов эффективно выращивать и учить.

Когда в технической или бизнесовой команде есть человек, умеющий в отладку аки боженька — вы сразу это прочувствуете и поймете. И будете использовать. На вопрос «что идет не так и как это исправить» будет одна конкретная точка входа.

Иногда это кризисный менеджер с огромным опытом. Иногда это бородатый инженер в прокуренном свитере на производстве. Иногда это Вася-красноглазик с кармой тестера, который будет сидеть ночами и дебажить продукт, после чего гордо с утра скажет «смотрите, вот тут жопа, я разобрался и починил». Пригодится такой боец.

Вот когда такого бойца нет — тогда тяжко. Когда совсем тяжко — надо или купить, или вырастить/воспитать.

А как учить, лично мне непонятно. Всё вышеизложенное вкинуть в голову человеку, понятное дело, я могу. Вот приживётся ли оно там, и сплавится ли в необходимые навыки: пока статистически не могу быть уверенным.

Есть хорошая мысль, что навыки воспитываются практикой. Вон там иди и дебажь. Мысль хороша, но не оч вписывается в реального мира процессы: если что-то сломали нужное и важное, то надо идти уже и делать, а не «учиться». Учиться прям на живой заднице системы = тоже можно, самый лучший опыт, конечно же. Но без гарантий. А бизнес любит гарантии и предсказуемость.

Тестовые стенды им собирать, что ли…

+ если пойти кого-то и купить, то можно найти человека, который просто на именно вашу задачу знает ответ. Так-то, конечно, сработает. Но нас (в смысле возможностей) интересует не купленный готовый ответ, а именно навык эти ответы в чистом поле самостоятельно находить.

Пока могу только с уверенностью заключить, что отладка и дебаг — это не только набор навыков и знаний, но и искусство.
Как в заголовке написал.

Если у вас возникает жгучее желание припахать под оперативные задачи описанного дебажного характера нейросетки, или просто ML, и сказать «ищи отклонения и аномалии» — всецело понимаю, и даже горячо поддерживаю. Anomaly detection так вообще отдельная успешная ML-сфера, которой десятки лет. Идея «давайте припашем робота за чем-то там следить» = прекрасный вариант и вообще ход мысли.

Но только в одном случае: если у вас уже есть некоторая структурная модель системы, которой реальность плюс-минус соответствует, вдогонку количественные метрики (или возможность их получить), и оценка рисков по ним. Тогда да. В случае же неприятном, «у нас какая-то хрень и мы даже (пока) не понимаем, куда копать» — ML-средства и нейросетки увы, не могут без подсказки. Тем более в проактивном режиме, самостоятельно.

Возможно, это исправится через несколько лет. Но пока так. Думать, и думать нестандартно — все равно пока придется человеку.