Привет, <username>!
Начинаю цикл статей про инженерную культуру. Сегодня хотелось бы разобрать концепцию спектра - глубины инженерного понимания и исследования технологий.
На одном полюсе - Tool Operation, на другом - Whitebox Engineering. Это не булевый флаг, хороший/плохой подход, а качественная шкала, в итоге помогающая найти грамотные решения и избежать множества проблем.
Но сначала опишем эти пределы и саму шкалу.
Tool Operation (TO)
Основа подхода в переборе проверенных решений и проверки поведения программы.
Раньше - обращение к Stack Overflow и фреймворкам. Сегодня в основном к LLM.
Сложности в объяснении причин инцидентов и обосновании принятых решений.
Whitebox Engineering (WE)
Исследование внутренних механизмов системы
Помимо поиска решений, также понимание методов их достижения, принципов работы, исторических предпосылок, границ и последствий применения, построение и улучшение моделей системы.
Есть интересная аналогия: при решении математической задачи найти несколько корней уравнения недостаточно. Нужно доказать, что других нет. Т.е. прохождение тестов не гарантирует правильность алгоритма. А надёжность, масштабируемость и поддерживаемость требуют отдельной проработки.
Пример моей прошлой статьи: Как мемоизация влияет на производительность React-приложения.
Краткое описание
В какое-то время существовало распространённое мнение, что в React компонентах нужно оборачивать всё в мемоизацию ради производительности. Проведя ресёрч: что реально происходит под капотом в React, какие накладные расходы, когда подобная оптимизация применима - можно также определить, когда от неё лучше отказаться.
Depth Spectrum
Как может выглядеть шкала глубины инженерного понимания?
Например поступает задача (промпт) - человекочитаемое описание и работа с ним.
Дальше идёт понимание сгенерированного кода и среды в которой он будет выполняться.
Спецификации языков, алгоритмы, структуры данных, принципы и паттерны, знание устройства компилятора и рантайма, операционные системы, управление памятью, архитектура процессора, уровни железа и физики.
И это не контрольный список знаний или последовательность изучения. А вариант одной из возможных плоскостей.
Смысл не в накоплении знаний как таковых. А в формировании картины мира, построении причинно-следственных связей, выявлении ограничений и данных для анализа.
С её помощью точнее прогнозировать, раньше обнаруживать уязвимые места, предвидеть последствия, и выбирать решения по их применимости и эффективности, а не распространённости или новизне.
Датский учёный Питер Наур в своих работах более подробно раскрывает программирование как построения внутренней модели системы, а не исключительно производства кода. На хабре есть статья с разбором его идей:
Программирование как разработка теорий: почему senior-разработчики стали ценны как никогда?
Programming as Theory Building (1985)
Уточнения и границы модели
В чистом виде Tool Operation или Whitebox Engineering не существуют. И вряд ли это фиксированная характеристика человека как IQ. Например кто-то на 73% WE. Нужно учитывать разные области в разное время при разных условиях. Это скорее вектор, направление, по которому можно двигаться.
Где-то использовать готовое решение. Где-то больше погрузиться в реализацию. И помнить, что не существует идеальных абстракций, все они протекают, а ресурсы и профит ограничены.
Но и универсальной ценности для любого бизнеса здесь не будет. Это вообще другая тема для обсуждения и аргумент, который часто неверно ставят в абсолют.
Как пример: оптимизация 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?
Просто сейчас эти различия всё труднее скрыть за одинаковыми должностями, инструментами и написанными строчками кода. Да и последствия всё существеннее.
Для каждой задачи есть подходящий метод решения. Было бы глупо говорить, что в любом вопросе whitebox подход предпочтительнее. Для создания прототипов, тулзов для собственного применения, возможно одноразовых скриптов - глубокое погружение может принести больше вреда, чем пользы. Но при создании сложных систем, с высокой ценой ошибки, неопределённости или последствии решений, как например: персональными данными, финансами, здравоохранением, над массовыми сервисами или в военной, космической отраслью - глубинный подход всё-таки применимее.
Зачем тогда нужна эта шкала?
Не для оценки объёма знаний конкретного человека или группы. Не призыв отказываться от готовых решений
Интересные статьи
Интересные статьи
