Developer Experience VS Оптимальность и быстродействие кода
Как и обещал, до выхода нового сезона стараюсь развлекать вас своими мыслями в письменном виде.
Что такое Developer Experience? На «галере» удивленно поднимут глаза и скажут, что про такое не слышали. А серьезные HR-спецы не задумываясь ответят, что это удобство в использовании инструментов разработки — SDK, API, документации, библиотек, фреймворков. Всего из чего на 90% состоит любой современный проект, помимо кода, который написан под вашу бизнес-логику.
Это важный показатель. И чем проект, больше, тем он важнее. Ведь разработка новых фич это от силы 20% времени разработчика — все остальное время он читает тот код, который уже написан, поддерживает, обновляет, ищет узкие места, чинит баги.
Кто занимается DX?
Если вы и ваша команда не думаете о DX, то это не значит, что никто им не занимается. О вас думают ваши коллеги, которые придумали пакетный менеджер и ваш любимый фреймворк. Думают те, кто делает инструменты для программистов от Гитхаба, то редактора кода. Даже современные языки программирования, во многом, продукт нацеленный именно на DX. Вдумайтесь, ведь любой проект можно сделать и на Ассемблере, Фортране, C — но почему-то пишут на JS, Go и Питоне. У всех этих языков, кроме более удобного и человеко-читаемого синтаксиса, еще и бездонные пакетные менеджеры, куча утилит для сборки, компиляции, дебагинга.
Причем тут быстродействие кода?
Любой синтаксический сахар, динамические типы и бесконечные массивы нужно оплачивать быстродействием. Фреймворк, в котором легко разобраться и есть все нужное из коробки — тащит за собой слои абстракций, которые не нужны компилятору, а созданы для человека. Удобство затаскивания библиотек в проект создает гору лишнего кода, который вы не используете.
Я осмелюсь утверждать, что часто улучшение DX приводит к ухудшению быстродействия или оптимальности. И на уровне языка, и на уровне фраемворка, и, конечно, на уровне вашей конкретной команды и вашего конкретного проекта.
Хочется привести такой хрестоматийный пример — старые игры для Atari-Денди требовали максимальной оптимизации, чтобы помещаться в память. Настолько, что всякими хитрыми хаками экономился каждый байт, а все что можно было переиспользовать — переиспользовалась. Широко известно, например, что победные фанфары, когда Марио доходит до замка — это просто быстро проигранная мелодия из начала уровня. Причем тут DX? А вы представте боль, если в этот код нужно будет что-то добавить или изменить? Да просто прочитать.
Когда эти параметры сталкиваются в современном проекте?
Сейчас большинство приложений не требуют такого быстродействия, чтобы экономить считанные такты процессора или кеш процессорной памяти. Хотя, конечно, в хайлоаде и не такое случается. Но решение DX или оптимизация, то и дело, приходится принимать. И если этого не делает менеджер или тимлид, то это делает сам разработчик. Например, когда решает затащить библиотеку в проект или написать только нужную часть функциональности самому. Или когда выбирает формировать запрос через ORM или запилить SQL-процедуру и выполнять ее прямо в базе данных по триггеру.
Итог
Рамки этой заметки слишком малы, что бы я давал вам советы что выбрать и в какой ситуации. Да и не думаю, что тут есть решения на все случаи жизни. Мысль, которую я хотел бы донести — если вы управляете разработкой, проектом или продуктом, не забывайте, что любое архитектурное решение, это выбор в пользу DX или быстродействия/оптимальности. И хорошо, если такие решения будут приниматься командой и осознанно, а не спонтанно и ситуативно.
Бонус
В подкасте мы всегда пытаемся показать больше одной точки зрения. И в постах я хочу делать так же. Мы договорились с моим другом Артуром Геращенко, что он напишет на ту же самую тему в своем канале Уйти в IT!
Кроме темы и даты выхода мы ничего не обсуждали, так что я сам с удовольствием посмотрю что там получилось 🙂
