Depth Spectrum: Tool Operation <-> Whitebox Engineering

Привет, <username>!

Начинаю цикл статей про инженерную культуру. Сегодня хотелось бы разобрать концепцию спектра – глубины инженерного понимания и исследования технологий.

На одном полюсе – Tool Operation, на другом – Whitebox Engineering. Это не булевый флаг, хороший/плохой подход, а качественная шкала, в итоге помогающая найти грамотные решения и избежать множества проблем.

Но сначала опишем эти пределы и саму шкалу.

Tool Operation (TO)

Основа подхода в переборе проверенных решений и проверки поведения ^[1] программы.

Раньше – обращение к Stack Overflow и фреймворкам. Сегодня в основном к LLM.

Сложности в объяснении причин инцидентов и обосновании принятых решений.

Whitebox Engineering (WE)

Исследование внутренних механизмов системы

Помимо поиска решений, также понимание методов их достижения, принципов работы, исторических предпосылок, границ и последствий применения, построение и улучшение моделей системы.

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

Пример моей прошлой статьи: Как мемоизация влияет на производительность React-приложения ^[2].

Depth Spectrum

Как может выглядеть шкала глубины инженерного понимания?

Например поступает задача (промпт) – человекочитаемое описание и работа с ним.

Дальше идёт понимание сгенерированного кода и среды в которой он будет выполняться.

Спецификации языков, алгоритмы, структуры данных, принципы и паттерны, знание устройства компилятора и рантайма, операционные системы, управление памятью ^[3], архитектура процессора, уровни железа и физики.

И это не контрольный список знаний или последовательность изучения. А вариант одной из возможных плоскостей.

Смысл не в накоплении знаний как таковых. А в формировании картины мира, построении причинно-следственных связей, выявлении ограничений и данных для анализа.

С её помощью точнее прогнозировать, раньше обнаруживать уязвимые места, предвидеть последствия, и выбирать решения по их применимости и эффективности, а не распространённости или новизне.

Датский учёный Питер Наур в своих работах более подробно раскрывает программирование как построения внутренней модели системы, а не исключительно производства кода. На хабре есть статья с разбором его идей:

• Программирование как разработка теорий: почему senior-разработчики стали ценны как никогда? ^[4]

• Programming as Theory Building (1985) ^[5]

Уточнения и границы модели

В чистом виде Tool Operation или Whitebox Engineering не существуют. И вряд ли это фиксированная характеристика человека как IQ ^[6]. Например кто-то на 73% WE. Нужно учитывать разные области в разное время при разных условиях. Это скорее вектор, направление, по которому можно двигаться.

Где-то использовать готовое решение. Где-то больше погрузиться в реализацию. И помнить, что не существует идеальных абстракций, все они протекают ^[7], а ресурсы и профит ограничены.

Но и универсальной ценности для любого бизнеса здесь не будет. Это вообще другая тема для обсуждения и аргумент, который часто неверно ставят в абсолют.

Как пример: оптимизация React-приложения.

Покрываем код консоль логом компоненты React Profiler, заглядываем в Dev Tools. Уменьшаем количество рендера.

На этом можно остановиться и часто это разумно. Но что если результаты пользователей нестабильны и противоречивы?

Можно опробовать другие методы. Залить и продолжить измерения.

Или погрузиться в fiber, reconciliation, main thread, layout, transform vs top, влияние сторонних виджетов, выявить основные причины фризов и подобрать более полные и ситуативные решения.

Суть не в том, чтобы всё изучить, а видеть за рамками проблемы. Не снимать симптомы, а устранять причину.

Эта характеристика появилась только сейчас?

Быстрый рост IT во времена распространения интернета, мобильных телефонов, ковида привлёк много людей в отрасль. С появлением ИИ эта тенденция только усиливается. С каждым днём появляется всё больше приложений. Порог входа уменьшается. Но это само по себе не усиливает понимание устройства технологий как таковое.

Комбинация решений со Stack Overflow, не погружаясь в них, не сильно отличается от современного вайбкодинга. Хотя, справедливости ради надо уточнить, что использование агентов не характеризует глубину погружения.

Практика копирования кода без полного понимания его работы была и до повсеместного использования ИИ. How are websites used during development and what are the implications for the coding process? ^[8]

Просто сейчас эти различия всё труднее скрыть за одинаковыми должностями, инструментами и написанными строчками кода. Да и последствия всё существеннее.

Для каждой задачи есть подходящий метод решения. Было бы глупо говорить, что в любом вопросе whitebox подход предпочтительнее. Для создания прототипов, тулзов для собственного применения, возможно одноразовых скриптов – глубокое погружение может принести больше вреда, чем пользы. Но при создании сложных систем, с высокой ценой ошибки ^[9], неопределённости или последствии решений, как например: персональными данными, финансами, здравоохранением, над массовыми сервисами или в военной, космической отраслью – глубинный подход всё-таки применимее.

Зачем тогда нужна эта шкала?

Не для оценки объёма знаний конкретного человека или группы. Не призыв отказываться от готовых решений 🙂.

А сократить неопределённость.

Современные инструменты иногда очень хорошо и быстро находят решения, но инженерное понимание учит задавать правильные вопросы. Видеть границы имеющихся моделей и подбирать необходимую глубину анализа.

Использовать ИИ не как заменитель разработчиков, а как экзоскелет для мозга ^[10], который позволяет изучать исходники, строить модели, искать и анализировать большие объёмы информации, предлагать альтернативные подходы. Хотя, и в то же время позволяет получать готовые решения с минимальными усилиями. Поймать тот момент оптимизации, когда ощутив мощность инструмента, главное – вместе с водой не выплеснуть и ребёнка.

В исследовании, Anthropic выявили, что участники, использовавшие ИИ для объяснения концепций продемонстрировали более глубокое понимание материала, чем те, кто только делегировал ему выполнение задачи. How AI assistance impacts the formation of coding skills ^[11]

Исследование опубликованное в CAIS выявило связь между качеством ментальных моделей и результатом программных решений. Task Mental Model and Software Developers’ Performance: An Experimental Investigation – Balijepally, Nerur, Mahapatra, 2015 ^[12]

Что вы думаете?

Были ли в вашей практике примеры, когда глубокое понимание технологического стека позволяло находить решения за пределами готовых абстракций?

Или когда подобное погружение оказалось избыточным и не повлияло/ухудшило результат?