Что такое api java
Как использовать API с Java?
Интерфейс разработки приложений (API) — это вычислительный интерфейс, который определяет взаимодействие между программным обеспечением. API-интерфейсы позволяют разработчикам не углубляться в исходный код некоторых сторонних программ. Они упрощают программирование, абстрагируя базовую реализацию и открывая только те объекты или действия, которые необходимы разработчику. Таким образом, разработчикам не нужно разбираться в операциях файловой системы, происходящих за кулисами.
При разработке на Java большинство основных задач программирования выполняются классами и пакетами API, что помогает минимизировать количество строк, написанных в одном фрагменте кода.
Java Development Kit (JDK) состоит из трех основных компонентов, а именно:
Java API описывает функции каждого из своих компонентов. Многие из этих компонентов заранее написаны и широко используются, поэтому разработчики могут применять заранее написанный код через Java API. После обращения к доступным классам и пакетам API разработчики могут вызывать необходимые классы кода и пакеты для реализации.
Типы API
Существует множество видов API. Существует около 15 000 общедоступных API-интерфейсов и многие тысячи частных API-интерфейсов, которые компании используют для расширения своих внутренних и внешних возможностей.
Зачем нам нужен API в Java?
Автоматизация: с помощью Java API работа может контролироваться компьютерными системами, участие программистов не требуется. С помощью API компании-разработчики программного обеспечения могут обновлять рабочие процессы, чтобы сделать их более быстрыми и эффективными.
Применение: поскольку API-интерфейсы Java могут легко получить доступ к программным компонентам, существует гораздо большая гибкость в доставке данных и услуг.
Эффективность: после предоставления доступа к Java API созданный контент может быть немедленно выпущен и доступен для каждого канала. Это позволяет быстро распространять контент.
Интеграция: API Java упрощают встраивание контента. Это обеспечивает дополнительную динамическую доставку данных.
Действия, которые вы можете выполнять через API
API может выполнять четыре типа действий:
Когда вы объединяете конечные точки с этими действиями, вы можете искать или обновлять любые доступные данные через API. Все эти действия различны, и вам нужно будет проверить документацию по API, чтобы узнать, как их кодировать.
Вот способы, которыми вы можете сделать запрос на сервере:
Для большинства API требуется ключ API. Как только вы найдете API, который хотите использовать, вам нужно будет проверить требования к доступу в документации. Тогда вам, скорее всего, придется пройти проверку личности. После этого вы получите уникальную строку букв и цифр для использования при доступе к API.
Самый простой способ начать использовать API — это найти в сети HTTP-клиент, например, REST-Client, Paw или Postman. Эти инструменты могут помочь вам структурировать запросы с помощью ключа API, который у вас есть для доступа к существующим API. Вам по-прежнему потребуется знание синтаксиса документации, но требуется очень мало знаний в области программирования.
Еще один хороший способ получить данные из API — создать URL-адрес из существующей документации API. Запрос API обычно не сильно отличается от обычного URL-адреса браузера, но возвращаемые данные будут в форме, удобной для чтения компьютерами.
Заключение
API очень полезен для извлечения данных из другого приложения или программного обеспечения. Если вы знаете, как читать документацию и писать запросы, вы можете получить большой объем данных. Но анализ всех этих данных может оказаться непосильным. Вот где в игру вступают разработчики. Они могут создавать программы, отображающие данные непосредственно в браузере или приложении в удобном для понимания формате.
Что такое API и как это работает
API — это интерфейс программирования приложения. Эта аббревиатура используется везде — от инструментов командной строки до приложений на Ruby on Rails.
API — это готовый код, который упрощает жизнь программистам. Разработчик может использовать готовый код API, чтобы писать приложение. Он помогает организовать код и сделать так, чтобы компоненты ПО могли использоваться неоднократно.
Из статьи вы узнаете:
Подробнее об API
API — это спецификация возможных взаимодействий с компонентом ПО. Например, если бы машина была компонентом ПО, в ее API содержалась бы информация о том, что машина может ускоряться, тормозить и включать радио. Ее API также бы включало информацию о том, как ускоряться.
API работает на 3 уровнях:
Приложение: Это приложения, которые вы используете на смартфоне, или ПО.
Програмирование: Программисты используют API, чтобы писать код.
Интерфейс: Как вы взаимодействуете с приложением.
Пример: Представьте официанта в ресторане. Вы — клиент, выбираете заказ в меню. Кухня — исполнитель вашего заказа.
Вам нужен посредник, который сообщит о заказе на кухню и принесет вам еду на стол. Им не может быть шеф-повар, потому что он готовит на кухне. Вам нужен кто-то, кто свяжет клиента и шеф-повара. И тут в игру входит официант — API.
Официант принимает ваш заказ, приносит его на кухню, говорит, что вы заказали. Затем доставляет ответ, или еду вам. Более того, если все сделано правильно, ваш заказ не упадет.
Виды API
Публичные API выпускаются такими компаниями, как Slack и Shopify, в надежде на то, что разработчики будут их использовать на своих платформах. Компании делятся набором вводных параметров, которые разработчики используют, чтобы достичь какого-то результата.
Публичное API можно использовать без проблем — доступ к документации можно получить без проблем.
Приватные API используются внутри компании. Если у компании много программных продуктов, приватное API используется, чтобы программы разговаривали между собой. Компоненты API могут меняться по желанию компании, тогда как изменения в публичном API может вызвать отчаянные протесты.
Давайте рассмотрим Java API и Twitter API в качестве примеров. Эти API относятся к виду публичных.
Java API
Java API — библиотека компонентов ПО доступных в готовом виде всем, кто установил Java Development Kit. Эти компоненты выполняют общие задачи и повышают производительность, так как программистам не нужно писать код с нуля каждый раз.
Один из базовых компонентов в ПО называется List, или Список. Этот компонент следит за списком сущностей. Java API определяет, что вы можете делать со списком: добавлять сущности, сортировать их в списке, определять, входит ли сущность в список. API также уточняет, как выполнять эти действия. Чтобы отсортировать список, вам нужно уточнить, какую сортировку вы хотите: по алфавиту, количественно, по цвету.
Документация API OpenJDK для метода сортировки Списка. Сравнитель — это параметр, который определяет сортировку списка
Twitter API
Twitter API, вместе со многими другими API в веб-версии, — пример REST API. REST API — это API, которое использует архитектурный стиль, основанный на передаче состояния представления. REST — это стиль строительных систем, который обеспечивает гибкое общение и отображение информации в вебе.
В REST API ресурс может быть чем угодно.
Примеры ресурсов: пользователь, список твитов, результаты поиска твитов. К каждому из этих ресурсов можно обращаться по его идентификатору. В случае REST API в веб-версии — это обычно URL.
Когда приложение запрашивает ресурс через идентификатор, API отдает текущее представление ресурса приложению в подходящем для него формате: в JPEG, HTML-странице или JSON.
Одна из отличительных характеристик REST — это то, что API отправляет данные приложению, которое их запрашивает. Несмотря на то, что это дает гибкость приложению, эта гибкость достигается ценой снижения эффективности. Пересылать данные в вебе для обработки — довольно медленный процесс.
API как уровень абстракции
Когда речь идет о ПО, API нужно везде. API идет рука об руку с одним из самых фундаментальных концептов в компьютерной науке — абстракцией.
Абстракция — способ организовать сложную систему так, что сложные действия могут выполняться просто.
Пример такой абстракции — программируемая облачная кнопка Amazon Dash Button. Ее можно настроить, чтобы подсчитывать или отслеживать предметы, звонки или сообщения, чтобы включать и выключать определенные действия
Можно выбрать внешний вид облачной кнопки Amazon
Вы заказываете кнопку Dash Button на Amazon и используете приложение на смартфоне, чтобы подключить кнопку к вашей сети Wi-Fi, учетной записи на Amazon и например, к вашей любимой марке бумажных полотенец.
Затем когда вы захотите заказать бумажные полотенца, жмете на кнопку. Она подключится к интернету и отправит сообщение, чтобы заказать их из вашей учетной записи Amazon. Через несколько дней вам доставят бумажные полотенца.
Как и API, Dash Button — это простой интерфейс, который прячет свою сложность от пользователя. Идентификатор продукта, который вы заказали, должен быть извлечен из базы данных. Ваш адрес доставки должен быть извлечен из вашей учетки, ближайший к вам склад с полотенцами нужно уведомить о заказе, а еще отгрузить нужный продукт со склада и упаковать. Затем товар нужно доставить по маршруту вместе с другими посылками.
Теперь представьте, что вам как клиенту пришлось бы координировать всё это.
Вы бы никогда не заказали бумажные полотенца, потому что это слишком трудозатратно.
К счастью, все эти муки спрятаны от вас. За тем, чтобы вам доставили полотенца, стоит длинная связанная цепь компьютерных систем и координации людей. А вам нужно только нажать на кнопку.
API, ради которых наконец-то стоит обновиться с Java 8. Часть 1
На сегодняшний день Java 8 является самой популярной версией Java и ещё довольно долго будет ей оставаться. Однако с тех пор уже выпущено пять новых версий Java (9, 10, 11, 12, 13), и совсем скоро выйдет ещё одна, Java 14. В этих новых версиях появилось гигантское количество новых возможностей. Например, если считать в JEP’ах, то в сумме их было реализовано 141:
Однако в этом цикле статей не будет никакого сухого перечисления JEP’ов. Вместо этого я хочу просто рассказать об интересных API, которые появились в новых версиях. Каждая статья будет содержать по 10 API. В выборе и порядке этих API не будет какой-то определённой логики и закономерности. Это будет просто 10 случайных API, не ТОП 10 и без сортировки от наиболее важного API к наименее важному. Давайте начнём.
1. Методы Objects.requireNonNullElse() и Objects.requireNonNullElseGet()
Появились в: Java 9
2. Методы-фабрики, возвращающие неизменяемые коллекции
Появились в: Java 9
Если предыдущие два метода – это просто косметика, то статические методы-фабрики коллекций позволяют действительно сильно сократить код и даже улучшить его безопасность. Речь о следующих методах, появившихся в Java 9:
Статические методы-фабрики позволяют создать неизменяемую коллекцию и инициализировать её в одно действие:
Если не пользоваться сторонними библиотеками, то аналогичный код на Java 8 выглядит гораздо более громоздким:
А в случае с Set или Map всё ещё печальнее, потому что аналогов Arrays.asList() для Set и Map не существует.
Если же наконец обновиться с Java 8, то работать с неизменяемыми коллекциями становится намного проще и приятнее благодаря методам-фабрикам.
3. Files.readString() и Files.writeString()
Появились в: Java 11
Java всегда была известна своей неспешностью вводить готовые методы для частых операций. Например, для одной из самых востребованных операций в программировании, чтения файла, очень долго не было готового метода. Лишь спустя 15 лет после выхода Java 1.0 появилось NIO 2, где был введён метод Files.readAllBytes() для чтения файла в массив байтов.
4. Optional.ifPresentOrElse() и Optional.stream()
Появились в: Java 9
Когда Optional появился в Java 8, для него не сделали удобного способа выполнить два разных действия в зависимости от того, есть ли в нём значение или нет. В итоге людям приходится прибегать к обычной цепочке isPresent() и get() :
Либо можно извернуться ещё таким образом:
Оба варианта не идеальны. Но, начиная с Java 9, такое можно сделать элегантно с помощью метода Optional.ifPresentOrElse() :
В Java 8 пришлось бы писать что-нибудь вроде:
Это выглядит громоздко и не очень читабельно.
Появились в: Java 9
Если без предыдущих API обойтись худо-бедно ещё можно, то вот замену метода Process.pid() в Java 8 найти будет довольно проблематично, особенно кроссплатформенную. Этот метод возвращает нативный ID процесса:
Появились в: Java 11
Целая гора полезных методов для строк появилась в Java 11.
Метод String.isBlank() позволяет узнать, является ли строка состоящей исключительно из whitespace:
Заметьте, что String.strip() не то же самое, что String.trim() : второй удаляет только символы, чей код меньше или равен U+0020, а первый удаляет также пробелы из Юникода:
Метод String.repeat() конкатенирует строку саму с собой n раз:
7. String.indent()
Появился в: Java 12
Конечно, наибольшый интерес такой метод будет представлять в сочетании с блоками текста, когда они станут стабильными, но ничто не мешает использовать его уже прямо сейчас без всяких блоков текста.
Появились в: Java 9
Stream записей является почти бесконечным, поэтому filter() использовать не получится. Тогда на помощь приходит takeWhile() :
А если мы хотим получить записи за 2019 год, то можно использовать dropWhile() :
Обе этих версии печатают все степени двойки, которые не превышают 100 :
Кстати, последний код можно было бы переписать с использованием takeWhile() :
Однако вариант с трёхаргументным iterate() всё-таки чище (и IntelliJ IDEA предлагает его исправить обратно).
9. Predicate.not()
Появился в: Java 11
Этот метод не вносит ничего принципиально нового и носит скорее косметический, нежели фундаментальный характер. И всё же возможность немного подсократить код всегда очень приятна. С помощью Predicate.not() лямбды, в которых есть отрицание, можно заменить на ссылки на методы:
А теперь используя not() :
10. Cleaner
Появился в: Java 9
С помощью Cleaner можно зарегистрировать очистку ресурса, которая произойдёт, если её забыли сделать явно (например, забыли вызвать метод close() или не использовали try-with-resources ). Вот пример абстрактного ресурса, для которого в конструкторе регистрируется очищающее действие:
По-хорошему, такой ресурс пользователи должны создавать в блоке try :
Заключение
Java не стоит на месте и постепенно развивается. Пока вы сидите на Java 8, с каждым релизом появляется всё больше и больше новых интересных API. Сегодня мы рассмотрели 10 таких API. И вы сможете использовать их все, если наконец решитесь мигрировать с Java 8.
В следующий раз мы рассмотрим ещё 10 новых API.
Если вы не хотите пропустить следующую часть, то рекомендую вам подписаться на мой Телеграм-канал, где я также публикую новости Java.
Современная разработка на Java: update, фичи, API и Copilot
Летом этого года мы в *instinctools организовали и провели серию онлайн-дискуссий с разработчиками и экспертами в области IТ. В рамках проекта «Техпора» нам хотелось услышать разные точки зрения на события и проблемы, которые волнуют разработчиков. Одна из этих серий касалась проблем современной разработки на Java. Дискуссия оказалась настолько информативной, что мы решили собрать самые интересные моменты и опубликовать их здесь, на «Хабре».
В разговоре приняли участие Developer JetBrains Тагир Валеев, организатор конференции RigaDevDays, основатель латвийского JUG Дмитрий Буздин, Developer Advocate проекта GraalVM, OracleLabs Олег Шелаев и Java Developer *instinctools Денис Лешенюк. Сразу хотим сказать, что мы не задавали тон беседе и не ставили экспертов в какие-то рамки. Это был достаточно свободный разговор, который касался наиболее важных тем для разработчиков. Если вы хотите поделиться своим взглядом на обсуждаемые вопросы – пишите в комментариях.
«Почему переезд на более новую версию Java всегда вызывает столько вопросов?»
Developer JetBrains Тагир Валеев: Недавно наша компания проводила опрос на тему, какую версию Java разработчики и заказчики используют чаще всего. Опрос проводился в начале 2021 года. Java 8 набрала 72%, Java 11 – 42%, а на третьем месте была на тот момент самая «свежая» версия – Java 15 с 14%. Получилось, что в момент выхода новой версии Java привлекает к себе интерес, который потом быстро затухает. И еще такой момент: если кто-то пользуется Java от Azul, то можно достаточно долго сидеть на промежуточных версиях.
Фото vesti.az
Developer Advocate проекта GraalVM, OracleLabs Олег Шелаев: Я читал статью Карла Мастранджело, который описывал свой опыт обновления приложений с Java 8 на Java 16 на Netflix. В статье был описан очень интересный феномен, почему никто в Netflix не решался на обновление Java в проектах. Причем было очевидно, что новая версия Java функционально лучше. Новые решения всегда лучше, ведь эти решения создает команда разработчиков – умные люди, которые двигают вперед продукт. Язык становится лучше, мощнее, удобнее. Казалось бы, нужно обновляться и все должны хотеть эти обновления. Но почему-то многие компании и проекты этого обновления не делают.
Мастранджело рассказывает в своей статье, как он пришел на Netflix и обновил Java. Он делал обновление постепенно. Сначала нашел одну библиотеку, которая не поддерживала прямолинейный upgrade, отправил pull request на GitHub, его приняли – и библиотека стала лучше работать на Java 11. Затем он пошел дальше: обновил еще одну библиотеку, потом еще одну и так далее.
И за достаточно короткий промежуток времени (несколько месяцев) он один перелопатил систему библиотек, которые использовались на проектах, и провел достаточно безболезненный upgrade. Почему он это сделал? Просто потому, что ему никто не сказал: ой, как сложно сделать upgrade на новую версию Java.
Получилось, что Карл не знал, что это сложно сделать и сделал. Как говорится, глаза боятся, а руки делают. Ты постепенно двигаешься в лучшую сторону, и все. Понятно, что есть компании и проекты, в которых конкретная версия Java – это функциональное требование. Это может быть требование проектов из экосистемы или требование компании, у которой собственные регуляции и оплаченная поддержка определенной версии. Но есть много проектов, которые «знают», что якобы очень сложно обновляться на Java 11, ведь в ней добавили var, убрали API и что-то сделали с reflection. Что сделали с reflection, никто не знает, но все боятся. Мне кажется, провести обновление достаточно легко, если ты берешь и делаешь это.
«Если вы проводите обновление, то нужно добиться, чтобы все зависимости поддерживали новую версию»
Тагир Валеев: Если вы проводите обновление, то нужно добиться того, чтобы все зависимости поддерживали новую версию. Причем не только зависимости, но и сами библиотеки. Это может быть tooling, это могут быть maven plugin. Когда вышла Java 9, многие maven plugin просто «разломались». Причем их сломал не Jigsaw, а то, что изменился формат версии. Единичка в начале исчезла, было 1.8, а стало 9 – и парсерам «сносило крышу».
Фото chemodur.livejournal.com
У вас мог быть статический анализатор на CI или что-то зависело от asm библиотеки, которую с каждой версии нужно бампать. Поднять транзитивную зависимость сложно. Сейчас с переходом на Java 11 не возникает таких страшных проблем. Практически все ваши зависимости, которые могли быть использованы, до 11 версии дотянулись. У JetBrains есть своя история, нам довольно сложно переходить на новую версию Java, так как у нас своя Java (IntelliJ IDEA и другие IDE на сборке JVM). И чтобы перейти нам на новую версию, следует провести очень большую работу.
«Я люблю фичи, когда в языке появляется что-то новое и приятное…»
Тагир Валеев: Я люблю фичи, когда в языке появляется что-то новое и приятное. Если фича появляется, то мы в IDE занимаемся ее поддержкой. Конечно, очень круто использовать records, ведь это позволяет в локальном контексте делать в Java множественный возврат из методов. Например, мне нужно вернуть из метода два значения и в соседнем методе использовать их. Разработчики создают какие-то классы, типа «пара», или пишут в переменную, создают массив из двух элементов. Иными словами, многим приходят на ум совершенно ужасные решения, потому что объявить класс на два поля было сложно. А сейчас это одна строчка кода. Его можно объявить приватным классом, вернуть и использовать. Но еще из важных фич я хотел бы отметить все, что происходит со свичами, как их прокачивают начиная с Java 14. И records еще долго будут завоевывать свое место под солнцем, а вот миграции на новые свичи идут практически автоматически. Наше IDE умеет это замечательно делать, вы переходите на новую версию Java, она сама видит, что этот старый и некрасивый свич можно превратить в новый, и он становится гораздо компактнее и красивее.
Фото Pinterest.com
«Не надо в начале карьеры переживать, что вы не на последней Java. »
Дмитрий Буздин: Не надо в начале карьеры переживать, что вы не на последней Java. Базовые принципы программирования похожи на всех языках и на всех версиях. Умение дебажить, писать автоматизированные тесты и структурировать код переносится с одного языка на другой достаточно просто. Сначала нужно научиться работать в команде, а дальше можно перейти на другой проект, где будет «хорошая Java». Ни для кого не секрет, что кадровый рынок в IТ на пике «пузыря», поэтому поменять работу на более интересную не составляет труда.
Java Developer *instinctools Денис Лешенюк: Тут другой вопрос: насколько для тебя будет полезно следить за новшествами, если ты работаешь на Java 8? Будут ли новые знания откладываться в голове или после первого сложного релиза на твоем проекте и эти знания просто «смоет».
Дмитрий Буздин: За всеми технологиями не уследить. Если ты Java-эксперт, то можешь следить за всеми новинками в языке. Но вот ты, например, прочитал про shenandoah или про какие-то «GC-вещи». Но на практике далеко не у всех будет возможность их «потрогать» или получить опыт сравнения разных алгоритмов GC. И тут возникает вопрос: а надо тебе это или нет? Ты либо идешь в продуктовую разработку, или занимаешься созданием инструментария и open JDK. Это совершенно разные направления, их вряд ли стоит сравнивать. В мире достаточно мало специалистов занято разработкой JVM. Это очень интересно и может быть пиком интеллектуальной карьеры, но, возможно, это не всем нужно. Для разработчика главное выбрать свой стек и технологии, а дальше достаточно читать release notes, ходить на ивенты, общаться. Найти работу, где будет достаточно возможности для развития, сегодня достаточно просто.
Тагир Валиев: Все знать невозможно, вокруг много чего происходит. Следить за всем новым просто нереально и не стоит пытаться. Вы всегда понимаете, что у вас есть специализация, вы заняты в конкретной области и в конкретном проекте. Вот в этой области забирайтесь настолько глубоко, насколько нужно для решения ваших задач. Копая вглубь, старайтесь смотреть широко. Попишите иногда на другом языке программирования, хотя бы на уровне «hello world». Я пишу на Java, но просматриваю, что нового выходит на C#. Я не пишу на C#, но мне интересно, потому что все, что появляется сегодня в C#, завтра может быть и в Java.
Поглядывайте вокруг себя, вы не сможете погрузиться во все глубоко, но вполне возможно, что вы прочитаете про другой язык, а через 2-3 года что-то подобное «завезут» в ваш. А если и не «завезут», то вы поймете, что новые знания изменили ваше мировоззрение и помогают решить задачу, с которой вы сейчас столкнулись. Не прекращайте учиться, пытайтесь узнавать что-то новое, это помогает держать мозг в тонусе, а вы будете работоспособными большее количество лет.
«Программная разработка – это всегда история про деньги»
Дмитрий Буздин: Программная разработка – это всегда история про деньги. В облачных сервисах память – это один из самых дорогих ресурсов. Обычно CPU в проектах не используется «на полную», а вот память в Java-проектах часто выбирается полностью. Это происходит потому, что полный «фарш» Spring – это 200 мегабайт, если делать меньше, то получим ошибку. Это и является причиной, почему многие компании идут на Go. Они делают микросервис на Go, он занимает 50 Мб RAM, заказчик или разработчик считает, сколько ему это выйдет по деньгам, и моментально принимает решение.
Исходя из микросервисной архитектуры, мы можем предположить, что в проекте будет, например, 20 микросервисов. Получается, что по 150 Мб оверхэда с каждого спринга, а нам нужно рассчитывать на три реплики, съедается несколько десятков гигабайт. И главный вопрос – почему? И тут люди начинают отказываться от Java, несмотря на другие преимущества.
Фото Google.com
«Если ИИ что-то и оптимизирует, то только overflow»
Тагир Валиев: Говоря о фичах и развитии программирования, я бы не стал недооценивать технологии искусственного интеллекта. Несколько лет назад произошел качественный скачок.
Дмитрий Буздин: Если ИИ что-то и оптимизирует, то только поход в stackoverflow. Ты пишешь два кода. Первый – системный, который решается походом в stackoverflow. И здесь действительно можно получить какой-то прирост. Но тут еще получается и много копипаст-кода, который непонятно откуда притянут.
Скачок не может произойти из-за сути программирования. Программирование – это инструкции. И обучить ИИ программированию можно, если только мы в машинный интеллект «закачаем» знания о конкретной проблемной области. Сейчас ИИ может играть в Starcraft и находить баги, но писать код искусственный интеллект не может. Ведь кто-то должен человеческие требования транслировать в какой-то язык программирования, будь это визуальный язык или язык жестов. Исключить из разработки ПО человека пока просто невозможно, ИИ может обеспечить только больший комфорт в программировании.
Представим, что мы сделали ИИ, который умеет программировать интернет-казино. В этом случае я соглашусь, что такой ИИ сможет помочь быстро сделать интернет-казино. Но если смотреть на ИИ как на средство для закрытия файловых стримов и решения типовых проблем, то – нет.
Олег Шелаев: Непонятно, как будет развиваться прогресс, но ИИ будет применяться в узкоспециализированных вещах. Например, можно будет с помощью ИИ просматривать код, чтобы указывать разработчику, например, куда установить курсор, чтобы прописать какой-то параметр. Такого, что придет заказчик и попросит создать робота, который будет покупать биткоины, когда они стоят мало, и продавать их, когда они дорожают, а ИИ сделает jar-файл, конечно, не будет. Работа разработчиков программного обеспечения, скорее всего, будет упрощаться по мере развития технологий ИИ. Скорее всего, будет так, как с переводчиками. Приложений для перевода много, но по факту сложный перевод или ответственные встречи проводят профессиональные переводчики, а не программы. Люди де-факто решают какие-то критические вопросы, по такому пути может развиваться и ИИ в программировании. Не исключено, что разработчики будут писать только тесты, а ИИ – код.
«Это приятно, что вы пишите всего 30% кода, а денег получаете за 100%»
Тагир Валиев: Недавно вышел GitHub Copilot который можно пока использовать только по приглашению. Но в Twitter можно уже увидеть записи, в которых разработчики демонстрируют сумасшедшие вещи. Оказывается, достаточно написать только название метода, а GitHub Copilot по названию полностью «придумает» тебе его тело. Так что новое будущее программирования уже не за горами, и мы внутри своей команды серьезно обсуждали, что разработчикам придется перепрофилироваться.
Фото imgur.com
Не исключено, что GitHub Copilot будет писать за всех программы. С другой стороны, то, что мы сами попробовали, еще не настолько волшебно, чем те примеры, которые публикуются в Twitter. Если смотреть на то, что происходит в разработке IDE, то можно отметить множество инкрементальных вещей, и они мне нравятся. Недавно появилась возможность, например, написать в Java «list.m» и вам тут же предлагается вариант«.stream.map».
Я поставил эксперимент: взял стандартную задачу подсчета в текстовом файле наиболее частотно встречающихся слов и написал на Java с нуля. При этом я включил логирование, из IDE легко сделать keylogger, включив режим записи макроса. И получил показатели, где я вручную вводил символы, а где IDE мне подсказывало. Получилось, что IDE написало за меня 2/3 кода. Это приятно, что вы пишите всего 30% кода, а денег получаете за 100%. Но стоит отметить, что написание нового кода – это далеко не самая большая часть работы программиста. Часто программист занимается отладкой, рефакторингом, исследованием багов, написанием и чтением документации, какими-то архитектурными вещами. И в перечисленных задачах автоматизация хоть и существует, но двигается с разной скоростью. Так что есть еще очень много работы, которую нужно делать программисту. И в будущее я смотрю с оптимизмом, ведь автоматизироваться будет наиболее скучная часть работы, которую мы головой понимаем, как сделать, но руками нам лень этим заниматься. Компьютер с радостью сделает за нас скучную работу, а самая интересная часть задачи будет на программистах довольно долго.
Дмитрий Буздин: Во многих проектах есть большая польза от умения планирования функционала. И в чисто бизнес-проектах скорость создания кода напрямую влияет на продуктивность. «Джетбрейнс» – это технология, которая ускоряет программирование в разы, но ей еще нужно «учиться». Если вы не используете какие-то умные фишки автокомлишена, а пытаетесь руками писать код, то вам до senior еще далеко по продуктивности. Эту «штуку» нужно приоритетно осваивать. Что касается замены программистов на ИИ, то этого не произойдет. Я делал на эту тему научную работу, идея замены разработчика на машину витает с 1980 года. Но пока мы видим только технологии, которые ускоряют написание или генерацию кода.