Чем ближе anthropic, к ipo, тем больше идиотизма мы будем наблюдать. Интересно посмотреть на этот продукт после года эксплуатации. Пока это маркетинговый хайп, не более
В 2026 году отметать все наработки и заявлять, что все не так и нужно делать все по-другому, потому что мне так кажется.. нуда нуда ведь все поменялось со времён Фаулера и Кента Бека, или ничего не поменялось и вы просто делаете ошибку в статье, на голубом глазу заявляя, что они просто устарели и все не так. Сослался я на книгу так как там вроде аксиомы рефакторинга прописаны, которым стоит следовать. 2*2 всегда 4, либо меняйте базовые аксиомы, чего в статье не сделано.
"UPD: про Unit тесты" тут вообще ад описан интересно где такое ) ни разу с таким трёшки не сталкивался)
https://martinfowler.com/articles/refactoring-2nd-ed.html крайне советую. Заодно solid. Штука в том что если вы пишите нормальный код, то юниты это просто подпорки на которые вы ориентируетесь. Фактически колличество тестов до и после должно быть примерно одинаковым. Там так вы код меняете а не использование его. Рефачить в потом писать тесты , странно...
Не ближе его роль в сре. В конкретно этой статье проблема в нт, имхо. Все кейсы про то что нт по сути нет или сделаны для галочки. Первый кейс: у вас либо нет теста, либо логин замокан(какой это тогда ни тест с моками). Очередь переполнилась: либо нет теста либо тест с моками систем с которыми взаимодействует. Моки отвечают быстро, а реальность другая.. 3 кейс тоже самое.Похоже вместо нт написаны бенчмарки. Плюсом вместо доработки и оттачивания стресс тестирования, вводится новая новая практика.
Вообщем просто не понимание процесса разработки.. юниты нужны не только для качества , но и для поддержки кода в будущем, рефакторинг например, да любые изменения в принципе не возможны без покрытия юнит тестами. Есть такой принцип написания текстов FIRST, F-FAST... Такие тесты и него удешевляют разработку, а не стоят дополнительные деньги. Главное в статье спутано покрытие кода и покрытия кейсов использования системы.
Опус о том что показываю сломанные юнит тест , а система работает, показывает просто бездну. Значит работает система не потому варианту , что в тесте, когда пишется код, код и тесты актуализируются. То есть если у вас есть блок мертвого кода, это не значит, что у вас плохие тесты, это значит у вас проблема с процессами разработки.
Опус о невозможности что-то тестить если это Букинг отелей... Тут со дна стучат уже. Ну возьмите вы практически стандарт индустрии: test containers. Или вот есть у вас рест: 400 ошибку. Хотя да.. юнит тесты нужны слабым программистам))
Обычно процесс выглядит как: maven central/github/any other source ->local installation: artifactory/nexus-> проверка лицензий проекта на этапе подключения(это базовый уровень разработчика что и почему он тянет нового)->юрист по лицензированию для перепроверки лицензий, перед выпусками версий где добавляется новое.
стек разработки обычно очень стабильный и что-то реально новое тянется редко, то есть реально заморачиваться придется только первый раз с юристом, дальше инкрементальные изменения ну раз в год максимум.
Это все понадобится как только вы реально захотите выйти на рынок.
Лично сидел юристом из Франции и помогал с проверкой лицензий, каждый год в течении недели. Колличество новых фич/фиксов за год сложно подсчитать, их были тысячи.
Валидация безопасности скорее миф. Проверить код всех зависимостей для rest hello world на spring boot java 21, конечно можно, но ресурсы нужны не подъемные, и переносится на комьюнити в целом + нужно следить и вовремя обновлять зависимости
2 второе: опять решение задачек. Решил одну, вторую рассказываю алгоритм решения (не перебор, не o(n) по памяти, но интервьюер говорит надо ещё быстрее решить , тут я и сбился ... Задача была относительно простая, но требовалось чтото чего я придумать не смог. За 10 мин до конца говорю, понимая что мое решение можно успеть написать. Не могу найти то решение, мне интервьюер и говорит: все равно 10 мин не хватит, остановимся))
Ради проформы пошел гуглить решение, оказалась hard leetcode, решение мной предложенное проходило по времени , и было одним из самых популярных решений, на сайте. О чем я и написал соответственно hr, на что получил ... Да ничего не получил, просто заигнорили и все...
Наверное идеально построеный процесс для найма после универа)
Сервис/канбан, да любой из agile, просто набор церемоний , как конструктор, собери под свой проект, кажется agile как раз про гибкость, а не твердолобое выполнение церемоний, agile manifesto вам в руки.
Тоже самое про ООП.. в ООП яп давно пышные вещи.
Попробуйте разработать что-то большое без всего этого, покажите что получилось. Новички часто страдают критикой, вырабатывают какие-то мега инструкции, пробуют какие о новые подходы без адаптации к задаче и говорят : ну гавно же. Не гавно, просто выбирайте инструмент под задачу, и даже выбранные инструменты дорабатывайте под задачу. Как раз делал ревью кода, где чувак не понимает , что речь это не rmi, что нужно немного в структурность, не нужно писать дубликаты типа getbycompanyid, getbyclientid, getbyxxxx, не понимает зачем и как валидироватьтвходные данные, но твердо предлагает перейти на другой подход к бранчингу в проекте.
Странно что рассматривались только платные системы. Opentelemetry для трейсингв, elk для логов например. в принципе не ясно с ценовой политикой в динатрейс и когда они забанят лицензию
Дайте угадаю у вас текучка кадров и отставание по срокам выполнения проекта?
Смысл спрашивать примеры,которые никогда не пройдут ревью. Или такое у вас в репе лежит и радует глаз "сложными конструкциями". Тем более на сеньерскую позицию. Вам компилятор нужен ?) в принципе самоутвердиться за счёт собеседуемого легко, он в нервозном состоянии, но делать это как минимум глупо, задача ведь не в этом.
А насчёт сроков и текучки сталкивался с такими.. компания начиналась с м и заканчивалась на биржа, там один тимлид , назовем его Филип , устраивал митинги чтобы договориться сколько нужно писать пробелов в табе(при включенной одинаковой настройке на команду) , нужны ли комментарии в тестах, какая максимальная длинна лямбда функции(при наличии корпоративного литера) и ТП, при просрочке проекта где-то на 8 месяцев и постоянной текучки из-за карательного ревью и "тянем друзей" в проекте
Визионер.
Чем ближе anthropic, к ipo, тем больше идиотизма мы будем наблюдать. Интересно посмотреть на этот продукт после года эксплуатации. Пока это маркетинговый хайп, не более
Отлично, детально, спасибо!
Нейрослоп реклама через гуглтранслейт )
В 2026 году отметать все наработки и заявлять, что все не так и нужно делать все по-другому, потому что мне так кажется.. нуда нуда ведь все поменялось со времён Фаулера и Кента Бека, или ничего не поменялось и вы просто делаете ошибку в статье, на голубом глазу заявляя, что они просто устарели и все не так. Сослался я на книгу так как там вроде аксиомы рефакторинга прописаны, которым стоит следовать. 2*2 всегда 4, либо меняйте базовые аксиомы, чего в статье не сделано.
"UPD: про Unit тесты" тут вообще ад описан интересно где такое ) ни разу с таким трёшки не сталкивался)
https://martinfowler.com/articles/refactoring-2nd-ed.html крайне советую. Заодно solid. Штука в том что если вы пишите нормальный код, то юниты это просто подпорки на которые вы ориентируетесь. Фактически колличество тестов до и после должно быть примерно одинаковым. Там так вы код меняете а не использование его. Рефачить в потом писать тесты , странно...
Вас запишут в луддиты, но благодаря таким , пока ещё, среди кучи аи-слопа, можно найти нормально написанные тексты. нормальные программы.
Не ближе его роль в сре. В конкретно этой статье проблема в нт, имхо. Все кейсы про то что нт по сути нет или сделаны для галочки. Первый кейс: у вас либо нет теста, либо логин замокан(какой это тогда ни тест с моками). Очередь переполнилась: либо нет теста либо тест с моками систем с которыми взаимодействует. Моки отвечают быстро, а реальность другая.. 3 кейс тоже самое.Похоже вместо нт написаны бенчмарки. Плюсом вместо доработки и оттачивания стресс тестирования, вводится новая новая практика.
Мало было январского обновления...
Вообщем просто не понимание процесса разработки.. юниты нужны не только для качества , но и для поддержки кода в будущем, рефакторинг например, да любые изменения в принципе не возможны без покрытия юнит тестами. Есть такой принцип написания текстов FIRST, F-FAST... Такие тесты и него удешевляют разработку, а не стоят дополнительные деньги. Главное в статье спутано покрытие кода и покрытия кейсов использования системы.
Опус о том что показываю сломанные юнит тест , а система работает, показывает просто бездну. Значит работает система не потому варианту , что в тесте, когда пишется код, код и тесты актуализируются. То есть если у вас есть блок мертвого кода, это не значит, что у вас плохие тесты, это значит у вас проблема с процессами разработки.
Опус о невозможности что-то тестить если это Букинг отелей... Тут со дна стучат уже. Ну возьмите вы практически стандарт индустрии: test containers. Или вот есть у вас рест: 400 ошибку. Хотя да.. юнит тесты нужны слабым программистам))
Зачем это на хабре? 100500 статей с оконулевой связью к разработке но про "ai"
0 информативности в или генерированной статье :(
Обычно процесс выглядит как: maven central/github/any other source ->local installation: artifactory/nexus-> проверка лицензий проекта на этапе подключения(это базовый уровень разработчика что и почему он тянет нового)->юрист по лицензированию для перепроверки лицензий, перед выпусками версий где добавляется новое.
стек разработки обычно очень стабильный и что-то реально новое тянется редко, то есть реально заморачиваться придется только первый раз с юристом, дальше инкрементальные изменения ну раз в год максимум.
Это все понадобится как только вы реально захотите выйти на рынок.
Лично сидел юристом из Франции и помогал с проверкой лицензий, каждый год в течении недели. Колличество новых фич/фиксов за год сложно подсчитать, их были тысячи.
Валидация безопасности скорее миф. Проверить код всех зависимостей для rest hello world на spring boot java 21, конечно можно, но ресурсы нужны не подъемные, и переносится на комьюнити в целом + нужно следить и вовремя обновлять зависимости
Очевидно, чтобы оставить часть платформ без обновлений гита. Ну и часть разработчиков выкинуть из проекта.
Помню проходил с год назад собес,
1 алг(к)о собеседование прошел
2 второе: опять решение задачек. Решил одну, вторую рассказываю алгоритм решения (не перебор, не o(n) по памяти, но интервьюер говорит надо ещё быстрее решить , тут я и сбился ... Задача была относительно простая, но требовалось чтото чего я придумать не смог. За 10 мин до конца говорю, понимая что мое решение можно успеть написать. Не могу найти то решение, мне интервьюер и говорит: все равно 10 мин не хватит, остановимся))
Ради проформы пошел гуглить решение, оказалась hard leetcode, решение мной предложенное проходило по времени , и было одним из самых популярных решений, на сайте. О чем я и написал соответственно hr, на что получил ... Да ничего не получил, просто заигнорили и все...
Наверное идеально построеный процесс для найма после универа)
"Критикует - предлагай"
Сервис/канбан, да любой из agile, просто набор церемоний , как конструктор, собери под свой проект, кажется agile как раз про гибкость, а не твердолобое выполнение церемоний, agile manifesto вам в руки.
Тоже самое про ООП.. в ООП яп давно пышные вещи.
Попробуйте разработать что-то большое без всего этого, покажите что получилось. Новички часто страдают критикой, вырабатывают какие-то мега инструкции, пробуют какие о новые подходы без адаптации к задаче и говорят : ну гавно же. Не гавно, просто выбирайте инструмент под задачу, и даже выбранные инструменты дорабатывайте под задачу. Как раз делал ревью кода, где чувак не понимает , что речь это не rmi, что нужно немного в структурность, не нужно писать дубликаты типа getbycompanyid, getbyclientid, getbyxxxx, не понимает зачем и как валидироватьтвходные данные, но твердо предлагает перейти на другой подход к бранчингу в проекте.
Бред бредовый.. начиная с не настроенного литера. Выгорание на ревью серьезно?
Странно что рассматривались только платные системы. Opentelemetry для трейсингв, elk для логов например. в принципе не ясно с ценовой политикой в динатрейс и когда они забанят лицензию
Дайте угадаю у вас текучка кадров и отставание по срокам выполнения проекта?
Смысл спрашивать примеры,которые никогда не пройдут ревью. Или такое у вас в репе лежит и радует глаз "сложными конструкциями". Тем более на сеньерскую позицию. Вам компилятор нужен ?) в принципе самоутвердиться за счёт собеседуемого легко, он в нервозном состоянии, но делать это как минимум глупо, задача ведь не в этом.
А насчёт сроков и текучки сталкивался с такими.. компания начиналась с м и заканчивалась на биржа, там один тимлид , назовем его Филип , устраивал митинги чтобы договориться сколько нужно писать пробелов в табе(при включенной одинаковой настройке на команду) , нужны ли комментарии в тестах, какая максимальная длинна лямбда функции(при наличии корпоративного литера) и ТП, при просрочке проекта где-то на 8 месяцев и постоянной текучки из-за карательного ревью и "тянем друзей" в проекте
Отбирать с помощь "ии" персонал ближайшие лет 5 как минимум странно. Вы ещё расчеты на Ии начните делать. видел плагин тут для екселя недавно ...