Да, интересные мысли. Но меня здесь больше волнуют не джуны, а в целом организация разработки ПО.
Вот есть то что называется "промышленной разработкой": команда из большого количества разных специалистов - бизнес-аналитик, дизайнер, системный аналитик, архитектор, разработчик, тестировщик, девопс, техпис (и еще каждой твари по паре) делают большой проект. Они реализуют задачи, передавая их друг другу (по принципу конвейера). SDLC и так далее.
И тут появляется ИИ. Как он повлияет на конвейер? Как изменится набор ролей? Как изменится соотношение количества специалистов разных ролей? Как изменятся передаваемые между ними артефакты?
По этой теме я пока ничего концептуального не видел:
Часть статей про то, что "конвейер" вообще не нужен, и всё это может делать один человек (т.н. "инженер полного цикла"). Наверно может, но далеко не во всех случаях.
Вторая часть статей - про то, как изменится работа разработчика, безотносительно к другим специалистам. Будто бы разработчик работает в вакууме. Тот же Spec driven development обычно описан так, что всё это делает один специалист. В реальных больших проектах это скорее всего не так.
Вот и интересно - есть ли практика внедрения ИИ в командную разработку на всех этапах процесса разработки? Не просто "оставляем процесс как есть, а каждый специалист использует ИИ для своих задач", а "перестраиваем процесс с целью максимально эффективного использования ИИ".
Информационные системы, уже подключенные к ЕСИА в соответствии с положениями Регламента версии 2.42 и ниже, могут продолжать применение действующих технических решений до 31 декабря 2026 года. При наступлении указанной даты все участники информационного взаимодействия обязаны применять техническое решение по реализации протокола OpenID Connect при взаимодействии с ЕСИА (создано в соответствии с техническим заданием, согласованным Минцифры России), а также прошедшее процедуру оценки влияния на выполнение предъявленных к СКЗИ требований.
Я правда думаю что срок перенесут, почти никто не готов будет.
За последние пару лет там всё сильно усложнилось, просто так не подключиться.
Во-первых, СКЗИ "КриптоПро CSP" нужен не абы какой, а в исполнении КС3. По требованиям формуляра там должен быть аппаратный модуль доверенной загрузки и замкнутая программная среда. Достаточно легко это настроить на Астре, на других ОС есть нюансы.
Во-вторых, для взаимодействия с ЕСИА нужно использовать либо одно из типовых решений (их по сути два и оба специфические), либо пройти процедуру оценки влияния среды функционирования на СКЗИ. Это полгода и 3-5 миллионов рублей.
Персоны - это простой, дешевый и быстрый метод, который приносит некоторую ограниченную пользу. Полноценные исследования (в том числе описанные в разделе "Что делать?") приводят к более качественному результату, но дольше и дороже.
Здесь не должно быть противопоставления, это методы из разных весовых категорий. В зависимости от ситуации на проекте можно использовать и тот, и другой.
Исследования лучше чем выдуманные из головы персоны, персоны лучше чем ничего.
Запрос №1 очень опасный. Если нет индекса по полю created_at, то будет sequence scan, что на большой таблице создаст нагрузку на систему. ORDER BY на больших таблицах надо с осторожностью использовать.
Не совсем понял про "Взаимодействие с ЕСИА будет осуществляться через шлюзовой модуль (API Gateway), доступный с 2025 года" - что изменяется с появлением данного модуля? Примеры кода приведены уже с его учетом или нет?
Если разбирались с этим вопросом, поясните пожалуйста в чем разница.
А меня пугает то что происходит в сообществе разработки ядра Linux. Процесс как-то движется вперед (а не тратит всё время на обсуждения и выяснение отношений) только на личном авторитете Торвальдса. Если он по какой-то причине перестанет участвовать в разработке ядра (bus-фактор никто не отменял) - вполне вероятен распад на несколько конкурирующих проектов и разруха.
Да, интересные мысли. Но меня здесь больше волнуют не джуны, а в целом организация разработки ПО.
Вот есть то что называется "промышленной разработкой": команда из большого количества разных специалистов - бизнес-аналитик, дизайнер, системный аналитик, архитектор, разработчик, тестировщик, девопс, техпис (и еще каждой твари по паре) делают большой проект.
Они реализуют задачи, передавая их друг другу (по принципу конвейера). SDLC и так далее.
И тут появляется ИИ.
Как он повлияет на конвейер? Как изменится набор ролей? Как изменится соотношение количества специалистов разных ролей? Как изменятся передаваемые между ними артефакты?
По этой теме я пока ничего концептуального не видел:
Часть статей про то, что "конвейер" вообще не нужен, и всё это может делать один человек (т.н. "инженер полного цикла"). Наверно может, но далеко не во всех случаях.
Вторая часть статей - про то, как изменится работа разработчика, безотносительно к другим специалистам. Будто бы разработчик работает в вакууме. Тот же Spec driven development обычно описан так, что всё это делает один специалист. В реальных больших проектах это скорее всего не так.
Вот и интересно - есть ли практика внедрения ИИ в командную разработку на всех этапах процесса разработки? Не просто "оставляем процесс как есть, а каждый специалист использует ИИ для своих задач", а "перестраиваем процесс с целью максимально эффективного использования ИИ".
Вам не кажется, что "погонщик LLM" при таком подходе перестает быть разработчиком, а становится системным аналитиком (и немного архитектором)?
И к спецификациям надо применять подходы и наработки именно из сферы системного анализа?
Вносите вы смущение в умы :(
Есть же классификация у Вигерса, все ее плюс-минус знают. А у вас очень похожая схема, но в деталях отличается.
Даже интересно стало что имели в виду авторы вопроса
Регламент ЕСИА, пункт 10.1:
Я правда думаю что срок перенесут, почти никто не готов будет.
За последние пару лет там всё сильно усложнилось, просто так не подключиться.
Во-первых, СКЗИ "КриптоПро CSP" нужен не абы какой, а в исполнении КС3. По требованиям формуляра там должен быть аппаратный модуль доверенной загрузки и замкнутая программная среда. Достаточно легко это настроить на Астре, на других ОС есть нюансы.
Во-вторых, для взаимодействия с ЕСИА нужно использовать либо одно из типовых решений (их по сути два и оба специфические), либо пройти процедуру оценки влияния среды функционирования на СКЗИ. Это полгода и 3-5 миллионов рублей.
Персоны - это простой, дешевый и быстрый метод, который приносит некоторую ограниченную пользу. Полноценные исследования (в том числе описанные в разделе "Что делать?") приводят к более качественному результату, но дольше и дороже.
Здесь не должно быть противопоставления, это методы из разных весовых категорий. В зависимости от ситуации на проекте можно использовать и тот, и другой.
Исследования лучше чем выдуманные из головы персоны, персоны лучше чем ничего.
Запрос №1 очень опасный. Если нет индекса по полю created_at, то будет sequence scan, что на большой таблице создаст нагрузку на систему. ORDER BY на больших таблицах надо с осторожностью использовать.
Спасибо за статью
Не совсем понял про "Взаимодействие с ЕСИА будет осуществляться через шлюзовой модуль (API Gateway), доступный с 2025 года" - что изменяется с появлением данного модуля? Примеры кода приведены уже с его учетом или нет?
Если разбирались с этим вопросом, поясните пожалуйста в чем разница.
А меня пугает то что происходит в сообществе разработки ядра Linux. Процесс как-то движется вперед (а не тратит всё время на обсуждения и выяснение отношений) только на личном авторитете Торвальдса. Если он по какой-то причине перестанет участвовать в разработке ядра (bus-фактор никто не отменял) - вполне вероятен распад на несколько конкурирующих проектов и разруха.
P.S. Недавно в блоге про это заметку писал: https://t.me/tnvblog/4
Не понял почему в заголовке ИЛИ.
Микросервисная архитектура - это с моей точки зрения про структуру системы, статика.
Событийно-ориентированная - про порядок взаимодействия, динамика.
Одно не исключает другого, эти вещи разного порядка.
Звучит как "вам яблоко большое или красное"
WSDL у вас выглядит неполным, не хватает binding и service
Даже интересно стало - что даст аналитику вдумчивое чтение 149-ФЗ. Если он не на госсектор работает, конечно.
Каналы из статьи в массе своей тоже правительственные
Вопрос только в том какой страны это правительство
Лично не использовал, поскольку не имею устройства на котором его можно запустить.
Под "интересное" имел в виду что общая логика приложения соответствует моему запросу и его стоило бы посмотреть. Другие похожие сильно дальше.
Статья интересна тем, что набор инструментов практически не пересекается с тем что использую я сам (и с тем что вижу вокруг). Есть о чем поразмыслить.
Ну не то чтобы прямо "здорового", но не жалуюсь :)
Что то смешались в одну кучу совершенно разные компании
Выручка Озона и выручка например Айтеко это две большие разницы
Лично видел систему где все суммы для оплаты в бюджет округлялись вверх - лучше переплатить полкопейки, чем потом доказывать что не верблюд.
Разные варианты бывают.
Неплохо бы для начала понять, а правильно ли с точки зрения бизнеса распределять погрешность округления по другим строкам.
Слышал разные точки зрения от бухгалтеров.