Системный подход к Agile: исследование совместимостей Java библиотек [лонг]

Java называют языком программирования. С формальной точки зрения это может быть и так. На практике картина более широкая: я считаю, что Java нужно рассматривать как целую программную систему для гибкой (Agile) разработки. В ней можно выделить четыре ключевых подсистемы, которые вместе образуют Java платформу : 1. Система ведения онтологии и моделирования бизнеса 2. Система верификации типов с правилами подстановки 3. Система среды исполнения динамического кода 4. Система модульной эволюции кодовой базы Пост утверждает, что настоящей гибкости, требуемой для реально модульных программ, поддающихся эволюции, так нужной энтерпрайзам, в Java практически нет; вместо неё царит хаос и тотальное смешение понятий на поле боя , где онтология, проектировка, реализация, рантайм да и сам разработчик ведут борьбу каждый за свои собственные принципы, в то время как главной жертвой является модульность. Для доказательства возьму конкретную тему совместимостей библиотек. Этот вопрос с технической стороны хорошо изучен, и разделяют три вида совместимостей: исходную, бинарную и поведенческую. Но будет полезным привести примеры еще раз, разбив не просто по этим трём категориям, а по зонам ответственности, для того, чтобы понять, какие трения возникают между самими подсистемы Явы. После обширного анализа будет представлено видение направления развития Явы как платформы, получившей новую среду скриптовых языков GraalVM . Основным тезисом служит заявление, что Агиль методология требует строгой трактовки, дисциплины и продуманных инструментов, чтобы свобода разработчика не превратилась в её свободный полёт в пучину хаоса.

https://habr.com/ru/articles/1010714/

#java #совместимость #верификация_программ #библиотеки #знания #экосистемы #agile #compatibility #binary_compatibility #агил

Аудитор: Человеко-Ориентированный Трекер Эволюции Библиотек

Java принято называть языком программирования, но по сути это целая программная система, включающая три уровня: формальную верификацию модели через теорию типов, среду выполнения с динамическим линковщиком JVM и ментальную модель, которую разработчик выстраивает вокруг библиотек. Когда автор меняет сигнатуру метода, страдает не только байт-код — рушится контракт и привычное представление о стабильности API. Существующие инструменты проверяют бинарную и исходную совместимость, но их ответ сводится к вопросу «упадёт или не упадёт». При этом они не объясняют суть изменений: например, если метод перенесли из подкласса в суперкласс, анализатор покажет «удалено в А, добавлено в Б» — технически верно, но по смыслу ничего не объясняет. Здесь нужен человеко-ориентированный подход . Библиотеки — такие же продукты, как и любые другие, и их потребители заслуживают внятного объяснения того, как эволюционирует API. Предлагаемый инструмент — Аудитор — умеет не только проверять совместимость, но и распознавать рефакторинги по их смыслу: отслеживать перемещение методов по иерархии, выявлять смену ответственности между классами, обнаруживать паттерны изменений. Вместо сухого списка «добавлено/удалено» он генерирует человеко-читаемые отчёты на вики-страницах проекта, где разработчик видит не просто факты, а историю эволюции структуры API. Это сохраняет актуальность ментальной модели библиотеки и снижает риск неверной интерпретации изменений при обновлении версий. В статье будут рассмотрены нюансы каждого из 3х уровней, чтобы дать теоретические основы, необходимые для понятия бинарной и исходной совместимостей версий (binary & source compatibility), а также же представлен практический обзор на новый фреймворк, написанный мною, для их автоматического аудита на вики-страницах, которые станут прекрасным дополнением к вашим Java проектам.

https://habr.com/ru/articles/1004286/

#java #api #документация #совместимость #библиотеки #экосистема #binary_compatibility #agile #wiki

API vs ABI: разницу видят не только лишь все

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

https://habr.com/ru/companies/alfa/articles/775180/

#binary_compatibility #library #application_binary_interface #gradle #runtime #разработка_библиотек #бинарная_совместимость #classфайл #public_api #компиляция_библиотек