Когда-то в среде разработчиков на Drupal CMS была популярна идея «зелёной разработки».
Домассового гринвошинга было ещё лет 15, так что речь несовсем про экологию.
Это подход, при котором вместо установки десятков сторонних модулей (хотя в этом Drupal был ну очень хорош) и написания собственного кода, проект строился на базе уже имеющихся в ядре инструментов и проверенных, широко используемых решений.
Такой подход считался правильным не только с точки зрения производительности и безопасности, но и как способ сделать сайт легче, понятнее и проще в поддержке. Обновления ядра не стоили буквально ничего.
Он требовал вдумчивости, внимания к API и знания возможностей платформы, зато давал в ответ устойчивость и долговечность.
Сегодня, несмотря на смену технологий, этот принцип остаётся актуальным. Он проявляется, например, в отказе от зависимости на множество сторонних пакетов в пользу более простых, понятных решений. Особенно хорошо это видно в разработке на современных фреймворках и экосистемах.
Идея та же: если проблему можно решить на базе уже существующего API, без лишних зависимостей — это, как правило, и быстрее, и надёжнее.
С появлением нейросетей и их интеграции в рабочие процессы, этот подход получил новое обоснование. Модели вроде ChatGPT гораздо лучше справляются с генерацией и объяснением кода, если он опирается на известные, хорошо документированные API и стандартные структуры.
Стоит лишь использовать малоизвестную библиотеку с нестабильной документацией — и ИИ начинает фантазировать, выдавая неточные или устаревшие решения. Чем ближе код к «ядру» платформы, тем проще его понять, модифицировать и дополнить — как человеку, так и машине.
Вот опять я всуну свой пульт на Flutter: нужно было определить широковещательный IP-адрес в локальной сети. Чтобы это сделать, нужно было рассчитать маску подсети для Wake-on-Lan, проще говоря, включения телевизора по сети.
Казалось бы, можно просто найти библиотеку, но они все избыточны. В итоге я написал нужные функции с нуля. Это заняло 10 минут и дало результат, который точно соответствует задаче. Более того — нейросеть отлично помогла, потому что код простой, прямолинейный и не зависит от внешних факторов.
Аналогичным образом в мусорку полетели зависимости для кастомных модалок и шторок.
Нейросети в очередной раз подчёркивают важную мысль: библиотеки хороши тогда, когда они полностью закрывают задачу. Если же приходится обходить, дописывать или разбираться, почему не работает, — это сигнал, что стоит подумать, действительно ли нужна эта зависимость.
В таких случаях библиотека должна быть почти идеальной: хорошая архитектура, понятный интерфейс, живое сообщество, ясная документация и внятная поддержка. Иначе — лучше без неё.
В итоге идея зелёной разработки — это не про отказ от всего стороннего, а про осознанный выбор и уважение к инструменту, с которым работаешь. И если раньше это помогало делать сайты стабильнее, то сегодня это ещё и делает твою работу совместимой с ИИ-помощниками, проще для ревью, и готовой к масштабированию.
Когда-то в среде разработчиков на Drupal CMS была популярна идея «зелёной разработки».
Домассового гринвошинга было ещё лет 15, так что речь несовсем про экологию.
Это подход, при котором вместо установки десятков сторонних модулей (хотя в этом Drupal был ну очень хорош) и написания собственного кода, проект строился на базе уже имеющихся в ядре инструментов и проверенных, широко используемых решений.
Такой подход считался правильным не только с точки зрения производительности и безопасности, но и как способ сделать сайт легче, понятнее и проще в поддержке. Обновления ядра не стоили буквально ничего.
Он требовал вдумчивости, внимания к API и знания возможностей платформы, зато давал в ответ устойчивость и долговечность.
Сегодня, несмотря на смену технологий, этот принцип остаётся актуальным. Он проявляется, например, в отказе от зависимости на множество сторонних пакетов в пользу более простых, понятных решений. Особенно хорошо это видно в разработке на современных фреймворках и экосистемах.
Идея та же: если проблему можно решить на базе уже существующего API, без лишних зависимостей — это, как правило, и быстрее, и надёжнее.
С появлением нейросетей и их интеграции в рабочие процессы, этот подход получил новое обоснование. Модели вроде ChatGPT гораздо лучше справляются с генерацией и объяснением кода, если он опирается на известные, хорошо документированные API и стандартные структуры.
Стоит лишь использовать малоизвестную библиотеку с нестабильной документацией — и ИИ начинает фантазировать, выдавая неточные или устаревшие решения. Чем ближе код к «ядру» платформы, тем проще его понять, модифицировать и дополнить — как человеку, так и машине.
Вот опять я всуну свой пульт на Flutter: нужно было определить широковещательный IP-адрес в локальной сети. Чтобы это сделать, нужно было рассчитать маску подсети для Wake-on-Lan, проще говоря, включения телевизора по сети.
Казалось бы, можно просто найти библиотеку, но они все избыточны. В итоге я написал нужные функции с нуля. Это заняло 10 минут и дало результат, который точно соответствует задаче. Более того — нейросеть отлично помогла, потому что код простой, прямолинейный и не зависит от внешних факторов.
Аналогичным образом в мусорку полетели зависимости для кастомных модалок и шторок.
Нейросети в очередной раз подчёркивают важную мысль: библиотеки хороши тогда, когда они полностью закрывают задачу. Если же приходится обходить, дописывать или разбираться, почему не работает, — это сигнал, что стоит подумать, действительно ли нужна эта зависимость.
В таких случаях библиотека должна быть почти идеальной: хорошая архитектура, понятный интерфейс, живое сообщество, ясная документация и внятная поддержка. Иначе — лучше без неё.
В итоге идея зелёной разработки — это не про отказ от всего стороннего, а про осознанный выбор и уважение к инструменту, с которым работаешь. И если раньше это помогало делать сайты стабильнее, то сегодня это ещё и делает твою работу совместимой с ИИ-помощниками, проще для ревью, и готовой к масштабированию.
