да пользователь то не несет, а вот корпорации, судя по поведению ИИ гигантов - охотно. А вот уже корпорации просят насильно сотрудников заставляют пользоваться ИИ(так как уже вложили деньги).
Я время от времени пытаюсь кодить с копайлотом - только медленнее получается. Нет там производительности пока что. ИИ может заменить людей в сферах, где это как это сказать..качеством можно пожертвовать.
Похоже, что основная прибыль от ИИ как производителя кирок и лопат в век золотой лихорадки. Проблема только в том, что добывают гавно вместо золота. И тут уж вопрос..что будет дальше?
Таже НВИДИА и АМД(сейчас после контракта с продажей в Китай) будут поднимать совершенно законные бабки за устройства. Но что дальше по цепочке? Люди закупятся и вложатся огромные бюджеты, закупят эти железки..а на выходе могут получить хрен да ни хрена. И вот это уже выглядит как страшно - деньги вложены, а прибыли - нет.
Удивительное кол-во восторженных комментариев к абсолютно бесполезной статье - вот, что страшно. То есть к поколению, которое умеет только формы клепать добавились еще и снежинки, которых все вокруг обижают. Дичь какая-то...Причем, в статье про условно токсичных гейткиперов(первый раз слышу такой термин за 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), либо же команда подбирается со знанием нужных архитектурных подходов.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Немного надоедает слышать про копипасту и изменения.
Почему никто не говорит, что код может быть одинаковым, но не копипастой? Для примера, два разных сценария используют условно одинаковый код(допустим, запрос в какую то систему с нужными параметрами)? Я могу сделать "общий" запрос, но, в случае, если одна из систем потребует изменений, а другая - нет, мы рискуем получить какую-нибудь ошибку.
В целом, сам подход, при котором мы в одном месте меняем и все где-то как-то само происходит - таит в себе кучу проблем. Нет уж - дублируйте код, делайте копипасту, пока вы точно не уверены, что понимаете, как работать с "общими" компонентами.
В самом общем случае мы имеем 3 класса: ZooAnimal, ZooKeeper, Food.
В ZooAnimal у нас инкапсулируется метод eat(Food), который внутри себя решает, ест животное это или выбрасывает исключение, что животное сдохло. Чтобы понять, ест ли это животное или нет, можно при создании животного передать список того, что же оно ест. И есть метод - дай мне доступную еду.
В ZooKeeper у нас инкапсулирует метод feed(List<ZooAnimal> animals, List<Food> food), который просто перебирает животных и к каждому подбирает первую попавшуюся еду из списка доступных у животного. Метод поиска еды можно усложить(он в ZooKeeper) сколько угодно - прикрутить расчет и все такое. Но в таком виде он примитивный - дай мне первую попавшуюся еду, которая соответствует еде из списка доступных.
Дальше просто создаем список животных, еду и передаем это все ZooKeeper.
Можно усложнять и добавлять классы, но откуда в этой задаче switch? ООПе же.
да пользователь то не несет, а вот корпорации, судя по поведению ИИ гигантов - охотно. А вот уже корпорации просят насильно сотрудников заставляют пользоваться ИИ(так как уже вложили деньги).
Нет никаких микроскопических областей ответственности в Сбере, по крайней мере в ИТ там каждый выполняет несколько ролей, причем очень жирных.
жпу есть только у нвидии и амд по сути. Может только тем, кто ими владеет развивать ИИ?
что за страны, где не нужен нал?О-о Азиатские, надеюсь?
Я время от времени пытаюсь кодить с копайлотом - только медленнее получается. Нет там производительности пока что. ИИ может заменить людей в сферах, где это как это сказать..качеством можно пожертвовать.
Похоже, что основная прибыль от ИИ как производителя кирок и лопат в век золотой лихорадки. Проблема только в том, что добывают гавно вместо золота. И тут уж вопрос..что будет дальше?
Таже НВИДИА и АМД(сейчас после контракта с продажей в Китай) будут поднимать совершенно законные бабки за устройства. Но что дальше по цепочке? Люди закупятся и вложатся огромные бюджеты, закупят эти железки..а на выходе могут получить хрен да ни хрена. И вот это уже выглядит как страшно - деньги вложены, а прибыли - нет.
Все равно всё в итоге держится на мнении опытных разработчиков\аналитиков\тестировщиков. Играйте вы хоть в покер, хоть в подкидного.
ага...только до Ленина была еще февральская революция, и Ленин свергал не царя вовсе ;) Ну ок.
Удивительное кол-во восторженных комментариев к абсолютно бесполезной статье - вот, что страшно. То есть к поколению, которое умеет только формы клепать добавились еще и снежинки, которых все вокруг обижают. Дичь какая-то...Причем, в статье про условно токсичных гейткиперов(первый раз слышу такой термин за 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 и в самом деле сложнее сменить, чем страну.
понятно, описания не будет, а будет просто какая-то воображаемая декомпозиция.
От ООП что-то совсем мало осталось.
В самом общем случае мы имеем 3 класса: ZooAnimal, ZooKeeper, Food.
В ZooAnimal у нас инкапсулируется метод eat(Food), который внутри себя решает, ест животное это или выбрасывает исключение, что животное сдохло. Чтобы понять, ест ли это животное или нет, можно при создании животного передать список того, что же оно ест. И есть метод - дай мне доступную еду.
В ZooKeeper у нас инкапсулирует метод feed(List<ZooAnimal> animals, List<Food> food), который просто перебирает животных и к каждому подбирает первую попавшуюся еду из списка доступных у животного. Метод поиска еды можно усложить(он в ZooKeeper) сколько угодно - прикрутить расчет и все такое. Но в таком виде он примитивный - дай мне первую попавшуюся еду, которая соответствует еде из списка доступных.
Дальше просто создаем список животных, еду и передаем это все ZooKeeper.
Можно усложнять и добавлять классы, но откуда в этой задаче switch? ООПе же.