Экологичная разработка: как создавать цифровые продукты без лишнего мусора

Хороший цифровой продукт легко узнать. Он не тормозит, не путает пользователя, не сыпется при первом обновлении и не требует бубна для каждой мелочи. Плохой — тоже легко. Он тормозит, путает, сыпется и выглядит так, будто его делали люди, ненавидящие человечество.

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

Вот здесь и появляется тема экологичной разработки. И это не о природе, это чистоте цифровой среды. О том, чтобы не делать продукты, которые засоряют код, интерфейс, архитектуру, аналитику, админку, поддержку и психику всех участников процесса.

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

Что такое экологичная разработка

Если совсем коротко, экологичная разработка это создание цифровых продуктов без лишнего мусора.

Причём мусор в цифровой среде выглядит вовсе не только как лишние мегабайты скриптов, раздутый фронтенд или библиотека размером с небольшой город, которую притащили ради одной кнопки. Мусор бывает куда изобретательнее. Это бессмысленная сложность в архитектуре и запутанная логика в админке. Это странная структура контента, хрупкие кастомизации поверх чужого кода, зависимости, которые притащили «на всякий случай» и интерфейс, который получит премию за дизайн и матерные слова от пользователей. Это всё, что не помогает задаче, а размножает сущности и проблемы.

Экологичный проект уважает ресурсы. Он быстрее работает, дольше живет и не требует бесконечных вливаний на поддержку. Но главное — он уважает людей. Пользователя, который не хочет ждать. Редактора, который не должен разбираться в коде, чтобы добавить новость. Разработчика, который откроет этот код через год и не станет генерить лучи словесного поноса в направлении автора.

Это не благотворительность. Это прагматизм. Каждая единица сложности, которую вы не создали сегодня, — это деньги, которые вы не потратите завтра.

Откуда берутся тяжёлые, медленные и запутанные продукты

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

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

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

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

В сам бизнес заказчика вникают поверхностно. Общую тему поняли, пару слов из брифа вытащили, дальше начинается типовая сборка. Реальные пользователи, сценарии, владелец, контент, реальная поддержка и цена изменений — whu cares. И клиент получает не решение для своего бизнеса, а типовую планировку с косметическим ремонтом.

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

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

Почему хорошие парни делают плохие вещи

О чем думает обычный разработчик, беря проект? Сколько запросить. На чём делать. Сколько это займёт. Какие инструменты подойдут. Что можно взять готовое. Как быстро собрать нужный функционал. Чем закрыть видимую часть ТЗ. Где можно ускориться. Где уже есть знакомое решение. Все эти вопросы нормальные. Проблема не в них.

Проблема в том, что если на этом мышление заканчивается, проект почти гарантированно начинает разрастаться в плохом смысле. Потому что разработчик в этот момент отвечает в основном на вопрос как сделать. А вопросы нужно ли это в таком виде, кому это реально нужно, как это будет жить через год, что здесь станет точкой хрупкости и что можно было бы решить проще… если все это задать разработчику — можно буквально услышать скрип диалапного модема в его голове.

Именно так и появляется неэкологичная разработка. Не обязательно из злого умысла. Чаще из профессиональной инерции. Когда проект воспринимается как объём работ, а не как система с будущим.

О чём разработчик должен думать на самом деле

Экологичное мышление начинается с привычки задавать себе неудобные вопросы до того, как неудобным станет весь проект.

Как это все увидят пользователи? Не сегменты аудитории в презентации и не абстрактные портреты ЦА, а живые люди, которые зайдут, потыкаются, не найдут нужную кнопку и уйдут туда, где кнопка прямо под пальцем.

Сколько этот продукт должен прожить? Что в нём устареет первым. Где у него точки старения. Что должно меняться легко, а что, наоборот, нельзя давать трогать неумелыми руками.

Кто будет сидеть в админке?. Эти люди вообще поймут, как всё это менять, или после запуска сайт станет священным объектом, к которому страшно прикасаться.

И главный вопрос: что в этом ТЗ можно упростить. Не бездумно урезать, а именно упростить. Убрать дубли. Объединить сущности. Снять лишнюю техническую цену там, где она не оплачена смыслом.

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

Именно эти вопросы позволяют увидеть проект не как набор экранов и функций, а как живую систему. У неё будет срок жизни, старение, поддержка, чужие руки в админке, обновления, новые требования и очень мало терпения к чужой самоуверенной импровизации. Экологичная разработка начинается там, где разработчик помнит об этом заранее, а не узнаёт постфактум.

Как выглядит экологичная разработка на практике

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

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

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

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

Это не вопрос инструментов. Это вопрос их соразмерности задаче. Если для простой галочки вы подключаете атомный реактор — вы производите мусор. Упакованный в красивую обертку радиоактивный мусор.

Как делать экологичные цифровые проекты

Экологичный проект начинается не с выбора стека. Он начинается с дисциплины.

Сначала вы понимаете задачу. Кто, зачем и как будет это использовать. Потом отделяете обязательное от лишнего. Потом проектируете архитектуру целиком, а не кусками. И только потом выбираете инструменты.

Никакого секрета нет, есть набор скучных принципов, которые рынок игнорирует, потому что они не приносят быстрых денег.

• Не добавляйте сущности без причины.
• Не смешивайте разное, потому что «так быстрее сейчас».
• Не стройте на хаках, которые не переживут завтра.
• Не рисуйте интерфейсы для красоты, забыв про производительность.
• Не забывайте про тех, кто будет этим пользоваться после вас.

Главный вопрос, который должен задаваться каждый раз когда загорается лампочка идеи в голове: это решение действительно нужно или оно просто увеличивает сложность?

Поборемся за цифровую экологию

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

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

Всё остальное обычно оказывается производством цифрового мусора. Иногда дорогого. Иногда красивого. Иногда даже модного. Но мусора.