# Сборка мусора — профессиональный навык

## Сопровождение после того, как код стал дешёвым

amaaov · 8 сентября 2026 года

В 1960 году Джон Маккарти описал систему Lisp, работавшую на IBM 704 и столкнувшуюся с необычной задачей управления памятью. Программы продолжали запрашивать новые участки, хотя некоторые из уже размещённых в памяти структур становились недоступны. Предложенная им процедура начинала с доступных регистров, проходила по ведущим от них цепочкам и возвращала всё остальное в список свободной памяти; изящество, происхождение, затраченные усилия и смысл не участвовали в решении, для которого имело значение лишь одно: способна ли выполняемая программа по-прежнему обратиться к объекту. [Рекурсивные функции символьных выражений и их машинное вычисление, часть I](https://doi.org/10.1145/367177.367199)

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

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

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

## Обязанность после публикации

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

В эссе [«LLM как вероятностная среда»](https://amkisko.github.io/posts/20251111160000_llms_probabilistic_medium.html) сгенерированный черновик был назван правдоподобным до того, как он становится истинным, а полезная работа человека помещалась на пути этого черновика к репозиторию или заказчику. В прежнем рассуждении речь шла о создании заготовки; рассматриваемая здесь обязанность возникает тогда, когда кто-либо просит другого человека или общую систему принять её на себя.

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

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

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

[Манифест совместной, параллельной и экстремальной разработки программного обеспечения и продуктов для людей](20260608120000_manifesto_collaborative_concurrent_extreme_ru.html) когда-то предлагал принять «слоп как сырьё». Эта формула относится к открыто признанной промежуточной стадии, на которой кто-то согласился доработать материал, прежде чем поместить его в структуру, которой должны доверять другие.

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

## Степени зависимости

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

Открытый блокнот может объявить себя экспериментом, сохранённым для изучения без обещания поддержки; тогда основная обязанность состоит в правдивом описании контекста, указании лицензии и происхождения, а также в элементарной защите секретов и разумном обращении с хранилищем. Исследовательский материал может потребовать более точного сохранения: [принципы цитирования программного обеспечения](https://doi.org/10.7717/peerj-cs.86) требуют постоянного идентификатора и указания конкретной версии, поскольку программа способна быть самостоятельным результатом исследования, а [руководство по передаче программ в репозиторий](https://zenodo.org/records/1327310/files/SoftwareDepositGuidance.pdf?download=1) распространяет это рассуждение на небольшие скрипты оболочки и R. Ни размер, ни внешняя привлекательность не определяют, принадлежит ли код научной документации, а ограниченная по объёму работа может быть завершённой. Эссе [«Существование»](20260827165000_existence.html) подходит к той же границе со стороны участника: переданный на хранение файл может оставаться доступным, не делая своего автора ответственным за всё, что впоследствии будет из него выведено; публичное описание должно ясно обозначать этот предел.

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

Это различие существенно для спора вокруг эссе Codeberg [«Защищая наше общее пространство FLOSS от LLM»](https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html), где автономные или требовательные к ресурсам сгенерированные проекты названы угрозой общему пространству, которое обслуживают добровольцы, но небольшим экспериментальным побочным проектам, потребляющим мало ресурсов, обещана вероятная терпимость. Сопутствующая документация указывает конкретные пределы: по умолчанию для репозиториев Git отводится 750 МиБ, а ещё 1,5 ГиБ предназначены для пакетов, выпусков, вложений и хранилища больших файлов; непрерывная интеграция требует значительных ресурсов; большие двоичные файлы сохраняют свою стоимость в истории репозитория. [Ограничения хранилища](https://blog.codeberg.org/new-storage-limits-on-codeberg-what-you-need-to-know.html), [руководство по непрерывной интеграции](https://docs.codeberg.org/ci/), [руководство по большим файлам](https://docs.codeberg.org/git/using-lfs/)

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

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

## Прежняя проблема сопровождения

Нынешний спор возвращает нас к вопросам, которые были сформулированы уже в 2022 году. Третьего февраля Национальный институт стандартов и технологий США опубликовал версию 1.1 своей [системы безопасной разработки программного обеспечения](https://doi.org/10.6028/NIST.SP.800-218), охватывающей подготовку, целостность выпуска, реагирование на уязвимости и устранение первопричин на всём протяжении разработки и сопровождения программ. Третьего мая NIST опубликовал [меры контроля программного обеспечения с открытым исходным кодом](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-22), в которых происхождение, целостность, поддержка и сопровождение рассматривались как важные свойства, зачастую плохо поддающиеся установлению. Общедоступная исследовательская версия ChatGPT появилась 30 ноября. [Представляем ChatGPT](https://openai.com/index/chatgpt/)

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

Один эмпирический взгляд на прежнюю проблему даёт исследование 265 325 запросов на включение изменений в десяти известных проектах с открытым исходным кодом, опубликованное в 2022 году. Исследователи обнаружили 4450 предложений, оставленных их авторами без продолжения, и связали такой исход с особенностями участника, рецензирования, нагрузки и проекта; хотя работа не измеряет сгенерированный код и не представляет все проекты, она показывает, что принятие предложенных изменений давно зависит от участия людей после отправки. [О напрасно потраченных вкладах](https://doi.org/10.1145/3530785)

Эссе [«Когда чтение обходится дороже письма»](https://amkisko.github.io/posts/20260313103000_when_reading_costs_more_than_writing.html) описывает ту же перестановку на уровне одной рецензии, когда проверка сгенерированного сообщения коммита потребовала больше времени, чем его ручная замена. Небольшое качественное исследование, опубликованное в 2024 году, отступает от этой сцены: интервью с десятью сопровождающими из девяти широко используемых проектов описывают труд по сопровождению как исчерпаемый ресурс, а устойчивость проекта связывают с инфраструктурой человеческих отношений. Такая выборка не позволяет судить о распространённости явления во всём открытом программном обеспечении, но показывает, почему репозиторий нельзя понять как код в сочетании с трекером задач; рабочее устройство включает также внимание, отношения, разрешение конфликтов, передачу ответственности и отдых. [Исследование труда по сопровождению и человеческой инфраструктуры, 2024 год](https://arxiv.org/abs/2408.06723)

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

## Соразмерность перед публикацией

Требование как можно тщательнее оптимизировать программу до публикации исходит из разумного стремления к порядку, однако у оптимизации нет универсального максимума. Время выполнения, память, энергия, объём кода, доступность, безопасность, удобство сопровождения, время рецензента и скорость получения обратной связи могут противоречить друг другу, а [модель качества программного продукта ISO](https://www.iso.org/standard/78176.html) содержит девять широких характеристик, между которыми слово *эффективный* само по себе не позволяет сделать выбор. [Спецификации интенсивности выбросов программного обеспечения](https://sci.greensoftware.foundation/) также требуются энергия при эксплуатации, углеродная интенсивность энергосети, выбросы, воплощённые в оборудовании, и функциональная единица, прежде чем она сможет выразить один из видов эффективности; более быстрый запрос мало говорит об общем расходе ресурсов, если меняется число запросов.

Знаменитое рассуждение Дональда Кнута об оптимизации обычно сокращают до такой степени, что практическое указание исчезает. В полном контексте он осуждал расход времени на некритические части программ и призывал измерениями находить те критические части, где улучшение оправданно. [Структурное программирование с операторами go to](https://dl.acm.org/doi/10.1145/356635.356640) Открытой разработке, однако, присуща и встречная традиция ранних выпусков, поскольку пользователи обнаруживают требования, которых не выявляет закрытая доработка. Анализ проектов SourceForge, проведённый в 2013 году, обнаружил криволинейную связь между частотой выпусков и последующей долей загрузок: до известного предела учащение помогало, но затем могло повредить; историческая выборка и показатель загрузок не устанавливают универсального графика, однако объясняют, почему и подготовке, и частоте выпусков нужны условия остановки. [Выпускать раньше, выпускать чаще?](https://openreview.net/forum?id=cBWCD2kJP6)

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

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

В 2024 году команда Plain описала небольшой пример такой практики на собственной платформе поддержки. Для распространённых задач клиентов она создавала отдельные приложения, использующие программный интерфейс компании; эта работа обнаруживала пробелы в самом интерфейсе, документации и опыте разработчика, оставляя примеры кода, которыми можно было поделиться. Такое продуктивное повторение превращает дополнительную программу в инструмент, делающий описание продукта полнее. Свидетельство остаётся узким: Plain также сообщала, что клиенты находили связанные с масштабом проблемы, которых не показало внутреннее использование. [Как Plain использует собственный продукт](https://www.plain.com/blog/dogfooding-at-plain)

Повторная разработка способна уничтожить свидетельства, накопленные в первой реализации. В своём предостережении против полной переписи Джоэл Спольски замечает, что внешне неловкий код может хранить исправления ошибок, обнаруженных лишь в ходе реального использования, поэтому вместе со старой реализацией можно отбросить с трудом добытое знание. Вторая программа приобретает ценность, когда команда записывает эти открытия, сравнивает поведение в фактической работе и осознанно выводит дубликат из эксплуатации. Такой проход через использование и передачу не даёт замене превратиться в ещё одно недокументированное утверждение в общей куче. [То, чего никогда не следует делать, часть I](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/)

Наведение порядка внутри развёрнутой программы отличается по смыслу от классификации общедоступного материала. Предварительное исследование двадцати трёх настольных Java-приложений с открытым исходным кодом показало, что методы, классифицированные как неиспользуемые, обычно сохранялись долго, редко вновь вводились в работу и зачастую не использовались уже в момент добавления. Выбор проектов, средства анализа и трактовка рефлексии ограничивают вывод, однако различие остаётся полезным: код, который не участвует в развёрнутой реализации, способен затруднить понимание, тогда как не обновляемый материал, честно помещённый в архив, может продолжать служить свидетельством. [Исследование неиспользуемых методов в настольных Java-приложениях с открытым исходным кодом](https://link.springer.com/article/10.1007/s10664-023-10303-0)

## Прекращение поддержки и сохранение

Издатель программы может продолжать сопровождение, передать проект другому владельцу, объявить о прекращении поддержки или поместить материалы в архив, причём каждый выбор выражается обычными техническими средствами. [GitHub](https://docs.github.com/en/repositories/archiving-a-github-repository/archiving-repositories) способен перевести архивный репозиторий в режим только для чтения и рекомендует перед этим закрыть незавершённую работу, а также обновить описание или README. [npm](https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions/) позволяет прикрепить предупреждение о прекращении поддержки к устанавливаемому пакету и описывает передачу проекта, от которого зависят другие, новому владельцу. Apache Software Foundation переносит проекты, разработка которых прекратилась, в свой [Attic](https://attic.apache.org/), сохраняя материалы и сообщая об их состоянии.

В принятой [спецификации маркеров состояния проекта](https://packaging.python.org/en/latest/specifications/project-status-markers/) для реестров пакетов Python теперь имеется более точный словарь, определяющий состояния `active`, `archived`, `deprecated` и `quarantined`. Проект без явного маркера считается активным; архивные проекты отклоняют новые загрузки, сохраняя прежние дистрибутивы; проекты с прекращённой поддержкой могут направить установщик к замене; карантин предназначен для небезопасных материалов. Состояние доступно машине, поскольку объявление на странице репозитория может никогда не попасться человеку, вводящему команду установки. В системе зависимостей отсутствие маркера оставляет проект в активном состоянии, поэтому о прекращении поддержки следует сообщать там, где возникает зависимость.

Сохранение представляет собой ещё один ответственный исход. [Software Heritage](https://www.softwareheritage.org/mission/) стремится собирать и хранить общедоступный исходный код как научное, техническое и культурное знание, тем самым предостерегая от оценки ценности только по нынешней активности. Сборщик памяти способен освободить недоступный объект, поскольку знает граф и момент; историческую ценность невозможно определить по столь же фиксированному набору исходных ссылок.

Работу Мэри Дуглас часто сводят к представлению о грязи как о материи не на своём месте, хотя позднейшие исследователи отмечают сомнительность ранней атрибуции этой формулы. Такая неопределённость уместна в рассуждении о сопровождении, тогда как основной тезис остаётся реляционным: беспорядок возникает внутри системы классификации. Прототип может занимать надлежащее место в архиве и оказаться опасно неуместным, если его рекламируют как поддерживаемую библиотеку безопасности. [Размещая материю не на своём месте](https://www.tandfonline.com/doi/full/10.1080/13264826.2013.785579)

«Мышление в сломанном мире» Стивена Джексона продолжает это рассуждение, помещая техническое творчество в ремонт и сопровождение. [Переосмысляя ремонт](https://doi.org/10.7551/mitpress/9780262525374.003.0011) Ремонтирующий сталкивается с зависимостями, передачей дел, неформальным знанием, неравномерно распределёнными тяготами и случаями, в которых восстановление требует преобразования; такая работа принадлежит созданию общих технических устройств, поскольку каждый новый предмет появляется среди систем, уже подверженных отказам и изменениям.

## Человек, который отвечает

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

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

Сообщение придаёт обязанности адрес. Рассказ автора может объяснить намерение, поведение результата показывает опыт пользователя, а смысл складывается в отношениях между людьми, соглашениями и последствиями. Эссе [«Обязанность перед ответом»](20260816205000_duty_before_answer.html) помещает эту обязанность в момент, когда человек решает, готов ли он отвечать за набор изменений; сопровождение сохраняет её в последующих выпусках, вопросах, передаче проекта, прекращении поддержки и архивировании.

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

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

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