да пользователь то не несет, а вот корпорации, судя по поведению ИИ гигантов - охотно. А вот уже корпорации просят насильно сотрудников заставляют пользоваться ИИ(так как уже вложили деньги).
Само собой западные компании несли свет в нашу дремучую родину ;) А на Западе при трудоустройве тебя поливают маслом и массажируют весь период найма. А массовые увольнения в той же ИТ отрасли - это не то.
Я время от времени пытаюсь кодить с копайлотом - только медленнее получается. Нет там производительности пока что. ИИ может заменить людей в сферах, где это как это сказать..качеством можно пожертвовать.
Похоже, что основная прибыль от ИИ как производителя кирок и лопат в век золотой лихорадки. Проблема только в том, что добывают гавно вместо золота. И тут уж вопрос..что будет дальше?
Таже НВИДИА и АМД(сейчас после контракта с продажей в Китай) будут поднимать совершенно законные бабки за устройства. Но что дальше по цепочке? Люди закупятся и вложатся огромные бюджеты, закупят эти железки..а на выходе могут получить хрен да ни хрена. И вот это уже выглядит как страшно - деньги вложены, а прибыли - нет.
Удивительное кол-во восторженных комментариев к абсолютно бесполезной статье - вот, что страшно. То есть к поколению, которое умеет только формы клепать добавились еще и снежинки, которых все вокруг обижают. Дичь какая-то...Причем, в статье про условно токсичных гейткиперов(первый раз слышу такой термин за 20 лет в в ИТ, если честно) автор якобы демистифицирует разработку, фактически приравнивая их к чернорабочим. Автору, видимо, невдомек, что сложность бизнес разработки не в перекладывании json`ов, а в сопровождении продукта из клубка сложных бизнес-процессов, где следует поддерживать баланс гибкости и надежности. Чем дольше живет приложение, тем сложнее его дорабатывать в силу того, что кодовая база растет, сложность восприятия - тоже. Архитектура "кода" даже одного приложения - нынче большая сложность, требующая очень разных подходов к декомпозиции и организации, а я не говорю про 10ки микросервисов. Теперь, разработчик, вместо того, чтобы быть просто хорошим математиком, должен оперировать довольно сложными концепциями причем и в самом деле для довольно простых приложений - таков тренд. Если попытаться посчитать условный стек знаний мидла на бэке типичного кровавого энтерпрайз - так быстро кончатся пальцы: от языка разработки(обычно два: java+kotlin, допустим), до фреймворков, которые используются в языке(пусть будет типичный стек из spring boot`а, хибера, логгеров, ломбоков, мапстрактов каких-нить), все это сверху обмазывается средствами сборки проектов(пусть будет мавен), и средой разработки(intellij idea), средствами профилирования(visualvm допустим), средствами тестирования(junit, archunit, mockito, testcontainers), инструментами докеризации(прости господи, там один openshift стоит всей разработки), базами данных(минимум сегодня - postrgresql), но на собесе тебя точно спросят про nosql и ты расскажешь, как любишь монгу или кассандру, какими нить очередями(kafka - ближе будет ко всем), минимальными знаниями средств автоматизации сборки и деплоя(jenkins) - это совсем не весь набор инструментов, которые РЕГУЛЯРНО меняются. Все это сверху приправлено сложностью предметной области,паттернами снижения сложности и разработки и так далее.
Да, через 5 - 7 лет это и в самом деле может казаться рутиной..и все будет казаться простым, кроме все той же организации кода и снижения сложности. Спустя 10 лет ты каждый раз будешь думать над тем, как через 5 лет твой проект будет жить, как развиваться, что заложить в архитектуру, чтобы он был достаточно гибким на протяжении всего срока жизни.
В конечно счете если взять типичную трехслойную архитектуру кода, запретить просачиваться ЛЮБЫМ НЕ БИЗНЕС сущностям в сервис слой(если совсем - то просто запретить импорт всех пакетов, кроме собственных и допустим java.*) и мы получим +- тоже самое.
Тогда сервис слой будет в себе содержать алгоритм, бизнес логику или что там аналитик ставит(последовательность вызовов, преобразований, проверок и т.д.) и все - это будет довольно просто тестируемо. И в таком случае мы любой из слоев можем легко заменить(допустим с хибера перейти на jooq).
И тут пытливый читатель спросит: а как же модули? А я отвечу, что тут начнется то, из за чего это все сложно стартует - чтобы работать с фичами\модулями\ддд и всем остальным, надо чтобы анализ работал над постановкой задач, надо чтобы проект имел функциональную модель(или любую другую) с границами, чтобы повторять модули за этой моделью, иначе со временем реальность разойдется с кодовой базой, появится либо дубли, либо переиспользование адаптеров из других модулей и так далее. Сложно всем будет.
а что такое бизнес логика? если представить, что адаптер реализует сохранение сущности в бд, то бизнес логикой является вызов+аргументы функции адаптера.
Ну и честно сказать, я такие "прокси приложения, которые просто перекладывают" вижу только при старте проекта, а через полгода - в условном сервис слое уже увесистая лапша из вызовов других адаптеров, проверок разнообразных и т.д.
Есть ощущение, если провести декомпозицию будущей системы сверху вниз в том же столетнем idef0, то мы получим:
1) функции системы
2) кол-во связей функций между друг другом
из чего мы можем получить первичную оценку, что, куда и как можно отнести.
И еще нюанс или вопрос: как так получилось, что api появилось до декомпозиции ?
Флаг прочтения есть только у персональных уведомлений. Уведомления отправляются разными экторами в разное время — персональные отправляются системой автоматически, а новостные — по запросу администратора. Они отправляются разным людям — персональные отправляются водителю, создавшему точку, а новостные — всем водителям. Даже методы API для отправки используются разные.
Архитектурные подходы идут по спирали: на одном витке преобладают формальные подходы(uml, паттерны, формализованный подход), на другом витке — неформальные(к которым можно отнести вариаци tdd, user story map знаменитого Jeff Patton). В конечном итоге, как мне кажется, архитектура и в самом деле подбирается под команду(чтобы не переучивать всех на очередной язык разметки unm, bpmn & etc), либо же команда подбирается со знанием нужных архитектурных подходов.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Немного надоедает слышать про копипасту и изменения.
Почему никто не говорит, что код может быть одинаковым, но не копипастой? Для примера, два разных сценария используют условно одинаковый код(допустим, запрос в какую то систему с нужными параметрами)? Я могу сделать "общий" запрос, но, в случае, если одна из систем потребует изменений, а другая - нет, мы рискуем получить какую-нибудь ошибку.
В целом, сам подход, при котором мы в одном месте меняем и все где-то как-то само происходит - таит в себе кучу проблем. Нет уж - дублируйте код, делайте копипасту, пока вы точно не уверены, что понимаете, как работать с "общими" компонентами.
да пользователь то не несет, а вот корпорации, судя по поведению ИИ гигантов - охотно. А вот уже корпорации просят насильно сотрудников заставляют пользоваться ИИ(так как уже вложили деньги).
Нет никаких микроскопических областей ответственности в Сбере, по крайней мере в ИТ там каждый выполняет несколько ролей, причем очень жирных.
жпу есть только у нвидии и амд по сути. Может только тем, кто ими владеет развивать ИИ?
Само собой западные компании несли свет в нашу дремучую родину ;) А на Западе при трудоустройве тебя поливают маслом и массажируют весь период найма. А массовые увольнения в той же ИТ отрасли - это не то.
что за страны, где не нужен нал?О-о Азиатские, надеюсь?
Я время от времени пытаюсь кодить с копайлотом - только медленнее получается. Нет там производительности пока что. ИИ может заменить людей в сферах, где это как это сказать..качеством можно пожертвовать.
Похоже, что основная прибыль от ИИ как производителя кирок и лопат в век золотой лихорадки. Проблема только в том, что добывают гавно вместо золота. И тут уж вопрос..что будет дальше?
Таже НВИДИА и АМД(сейчас после контракта с продажей в Китай) будут поднимать совершенно законные бабки за устройства. Но что дальше по цепочке? Люди закупятся и вложатся огромные бюджеты, закупят эти железки..а на выходе могут получить хрен да ни хрена. И вот это уже выглядит как страшно - деньги вложены, а прибыли - нет.
Все равно всё в итоге держится на мнении опытных разработчиков\аналитиков\тестировщиков. Играйте вы хоть в покер, хоть в подкидного.
ага...только до Ленина была еще февральская революция, и Ленин свергал не царя вовсе ;) Ну ок.
Удивительное кол-во восторженных комментариев к абсолютно бесполезной статье - вот, что страшно. То есть к поколению, которое умеет только формы клепать добавились еще и снежинки, которых все вокруг обижают. Дичь какая-то...Причем, в статье про условно токсичных гейткиперов(первый раз слышу такой термин за 20 лет в в ИТ, если честно) автор якобы демистифицирует разработку, фактически приравнивая их к чернорабочим. Автору, видимо, невдомек, что сложность бизнес разработки не в перекладывании json`ов, а в сопровождении продукта из клубка сложных бизнес-процессов, где следует поддерживать баланс гибкости и надежности. Чем дольше живет приложение, тем сложнее его дорабатывать в силу того, что кодовая база растет, сложность восприятия - тоже. Архитектура "кода" даже одного приложения - нынче большая сложность, требующая очень разных подходов к декомпозиции и организации, а я не говорю про 10ки микросервисов. Теперь, разработчик, вместо того, чтобы быть просто хорошим математиком, должен оперировать довольно сложными концепциями причем и в самом деле для довольно простых приложений - таков тренд. Если попытаться посчитать условный стек знаний мидла на бэке типичного кровавого энтерпрайз - так быстро кончатся пальцы: от языка разработки(обычно два: java+kotlin, допустим), до фреймворков, которые используются в языке(пусть будет типичный стек из spring boot`а, хибера, логгеров, ломбоков, мапстрактов каких-нить), все это сверху обмазывается средствами сборки проектов(пусть будет мавен), и средой разработки(intellij idea), средствами профилирования(visualvm допустим), средствами тестирования(junit, archunit, mockito, testcontainers), инструментами докеризации(прости господи, там один openshift стоит всей разработки), базами данных(минимум сегодня - postrgresql), но на собесе тебя точно спросят про nosql и ты расскажешь, как любишь монгу или кассандру, какими нить очередями(kafka - ближе будет ко всем), минимальными знаниями средств автоматизации сборки и деплоя(jenkins) - это совсем не весь набор инструментов, которые РЕГУЛЯРНО меняются. Все это сверху приправлено сложностью предметной области,паттернами снижения сложности и разработки и так далее.
Да, через 5 - 7 лет это и в самом деле может казаться рутиной..и все будет казаться простым, кроме все той же организации кода и снижения сложности. Спустя 10 лет ты каждый раз будешь думать над тем, как через 5 лет твой проект будет жить, как развиваться, что заложить в архитектуру, чтобы он был достаточно гибким на протяжении всего срока жизни.
Прямо мемуары снежинки.
В конечно счете если взять типичную трехслойную архитектуру кода, запретить просачиваться ЛЮБЫМ НЕ БИЗНЕС сущностям в сервис слой(если совсем - то просто запретить импорт всех пакетов, кроме собственных и допустим java.*) и мы получим +- тоже самое.
Тогда сервис слой будет в себе содержать алгоритм, бизнес логику или что там аналитик ставит(последовательность вызовов, преобразований, проверок и т.д.) и все - это будет довольно просто тестируемо. И в таком случае мы любой из слоев можем легко заменить(допустим с хибера перейти на jooq).
И тут пытливый читатель спросит: а как же модули? А я отвечу, что тут начнется то, из за чего это все сложно стартует - чтобы работать с фичами\модулями\ддд и всем остальным, надо чтобы анализ работал над постановкой задач, надо чтобы проект имел функциональную модель(или любую другую) с границами, чтобы повторять модули за этой моделью, иначе со временем реальность разойдется с кодовой базой, появится либо дубли, либо переиспользование адаптеров из других модулей и так далее. Сложно всем будет.
а что такое бизнес логика? если представить, что адаптер реализует сохранение сущности в бд, то бизнес логикой является вызов+аргументы функции адаптера.
Ну и честно сказать, я такие "прокси приложения, которые просто перекладывают" вижу только при старте проекта, а через полгода - в условном сервис слое уже увесистая лапша из вызовов других адаптеров, проверок разнообразных и т.д.
так я потому и спросил, что есть - полез в апи и там увидел в концепции про ключи идемпотентности. Ну ок, буду ждать тогда - интересно.
А самое интересно про идемпотентность оставили вне статьи?;)
Есть ощущение, если провести декомпозицию будущей системы сверху вниз в том же столетнем idef0, то мы получим:
1) функции системы
2) кол-во связей функций между друг другом
из чего мы можем получить первичную оценку, что, куда и как можно отнести.
И еще нюанс или вопрос: как так получилось, что api появилось до декомпозиции ?
Флаг прочтения есть только у персональных уведомлений. Уведомления отправляются разными экторами в разное время — персональные отправляются системой автоматически, а новостные — по запросу администратора. Они отправляются разным людям — персональные отправляются водителю, создавшему точку, а новостные — всем водителям. Даже методы API для отправки используются разные.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Немного надоедает слышать про копипасту и изменения.
Почему никто не говорит, что код может быть одинаковым, но не копипастой? Для примера, два разных сценария используют условно одинаковый код(допустим, запрос в какую то систему с нужными параметрами)? Я могу сделать "общий" запрос, но, в случае, если одна из систем потребует изменений, а другая - нет, мы рискуем получить какую-нибудь ошибку.
В целом, сам подход, при котором мы в одном месте меняем и все где-то как-то само происходит - таит в себе кучу проблем. Нет уж - дублируйте код, делайте копипасту, пока вы точно не уверены, что понимаете, как работать с "общими" компонентами.
IP и в самом деле сложнее сменить, чем страну.
понятно, описания не будет, а будет просто какая-то воображаемая декомпозиция.