Max Home IndustryСуществует так мало информации о том, как мы на самом деле кодируем, что почти любые данные заслуживают внимания. В данном случае речь идет о том, как и почему Java-программисты ломают API, которые они создают и развивают.
Мы все знаем, что изменение API и исправление программного обеспечения, которое было нарушено каким — либо обновлением библиотеки, — это факт жизни, но почему? Почему программисты, которые также понимают важность того, чтобы не вносить критических изменений, тем не менее чувствуют необходимость их вносить? Этот вопрос задают некоторые недавние исследования Алины Брито, Лаэрте Ксавье, Андре Хора и Марко Тулио Валенте, которые будут представлены на Международной конференции по анализу, эволюции и реинжинирингу программного обеспечения:
В этом контексте в литературе нет полного ответа на один важный вопрос: несмотря на признание практики программирования, которая может нанести вред клиентским приложениям, почему разработчики нарушают API?
Четыре точных вопроса, на которые они должны ответить, таковы::
Как часто изменения влияют на клиентов? 39% изменений, исследованных в исследовании, могут оказать влияние на клиентов. Однако, по мнению опрошенных разработчиков, в большинстве случаев требуется незначительная миграция.
Почему разработчики нарушают API? Мы определили три основных мотивации для взлома API, включая изменения для поддержки новых функций, упрощения API и улучшения ремонтопригодности.
Почему разработчики не осуждают сломанные API? Большинство разработчиков упомянули увеличение усилий по обеспечению ремонтопригодности в качестве причины того, что они не осуждают сломанные API.
Как разработчики документируют критические изменения? Большинство разработчиков планируют документировать обнаруженные критические изменения, в основном используя примечания к выпуску и журналы изменений
Команда отслеживала 400 библиотек Java, размещенных на GitHub, в течение 116 дней. Они обнаружили 282 возможных критических изменения и получили ответы от разработчиков 55% библиотек.
Последующие интервью выявили некоторые дополнительные интересные факты. Большинство критических изменений были вызваны рефакторингом кода программистами. Удивительное количество программистов утверждали, что изменения касались внутренних утилит, которые никогда не предназначались для использования внешним миром.
Что касается точных причин изменений, то наиболее часто цитируемыми мотивами были четыре: Новые функции, Упрощение API, Улучшение ремонтопригодности и Исправление ошибок.
В целом, похоже, что разработчики оценили улучшения в своем коде и библиотеке выше необходимости поддерживать контракт API с внешним миром. Они, по-видимому, рассудили, что влияние изменений на их пользователей было небольшим, и выгоды для них перевешивали потерю стабильности. В исследовании есть некоторые доказательства того, что некоторые из их клиентов согласились с таким отношением, сославшись на усилия, необходимые для перехода на модифицированный API, как на «незначительные».
Удивительно обнаружить такое небрежное отношение среди программистов, создающих библиотеки для потребления другими. Тем не менее, я уверен, что вы можете придумать важные API, которые, по-видимому, нарушают правила просто потому, что команда разработчиков решает, что они могут лучше выполнять свою работу. Возможно, самым большим недавним примером этого является переход от Angular.js к не обратно совместимому угловому. Также удивительно, что отсутствие инкапсуляции цитируется как причина того, что мы не понимаем, что внутреннее изменение имело внешние последствия.
Что мы можем с этим поделать?
Исследователи предполагают, что инструмент, который они использовали для обнаружения изменений, APIDIFF, может помочь создателям библиотек понять, какой хаос они собираются нанести, перечисляя потенциально разрушительные изменения.
Однако, по сути, несмотря на годы работы над версиями как кода, так и интерфейсов, кажется, что программисты просто ценят свою собственную работу больше, чем любое влияние, которое она может оказать на внешний мир. Начать все сначала, потому что теперь мы знаем, как сделать это правильно, — это обычная ошибка программиста. Также кажется, что та же ошибка применима и в меньшем масштабе.