Я вчера Луну-то снять не мог во время лунного затмения. Глазами прекрасно видно, в бинокль отлично видно (кратеры разглядывал). В телефоне вообще ничего не видно.
Ночью темный объект, пусть с огнями или контуром, как у комментатора выше, просто не отобразится в телефоне.
То-ли пример неверный, то ли еще что. Интеграционные тесты предназначены только для одного - тестирования интеграции - сиречь для того, чтобы проверить, что вилка с розеткой правильно спроектированы и изготовлены.
Я вижу, что тестконтейнеры хороши, когда начинаешь писать тесты в унаследованный проект, где обращение к сторонним сервисам, вроде бд, производится прямо в нижних методах. Выбрали из базы - посчитали что-то - сохранили в базу - выбрали из базы - посчитали - сохранили в базу - закончили упражнение. Такие классы не проюнитишь без серьезного перелопачивания.
Правильное решение для такого кейса - сохранеие адреса выделяется в отдельный класс. В него инжектится датасурс к базе. userService.registerUser - такого быть не должно. Репозиторий должен делать только getUser и saveUser. getUser должен просто возвращать или null, или пользователя по верхнему регистру с идентификатором. saveUser - просто создавать или апдейтить пользователя. В базе должно быть два поля - как есть, и верхнем регистре (можно сделать индекс с верхним регистром и запрос делать UPPER(user) = :user). Никаких проверок и ошибок он не должен возвращать. Это simple объект. Проверка должна осуществляться в бизнес-классе (UserService). В нем из входа приводится к верхнему регистру, обращается к датасурсу, если есть - выбрасывается исключение, если нет - делается вызов saveUser. Этот класс и метод отлично юнит-тестится.
Тестконтейнеры приходится (ПРИХОДИТСЯ!) применять в случае унаследованной системы, также когда часть логики в процедурах или сторонних системах, и на нее завязана тестируемая функциональность.
Более того, я считаю, тестконтейнеры ВРЕДЯТ организации, поскольку вместо правильного разделения слоев, поощряют писать код-лапшу, в котором не применяется DI, не используется в полную мощь Spring, и обращения к сторонним сервисам производится на самых нижних уровнях. Такой бардак обязательно выйдет боком. Не говоря о том, что производительность тесконтейнеров, в отличии от юнит, ужасная - процесс разработки просто или встанет, потому что билд с тестами будет делаться по полчаса-час, либо их просто отключат.
4 Плеер юзабильнее. Чтобы перейти к следующей песне, надо телефон разблокировать - нажать на кнопку разблокировки или потапать по экрану, подержать палец на кружке, три раза сделать попытку при этом, потом перейти в приложение проигрывания, помудохаться там с интерфесом, добраться до маленькой кнопки перехода к следующей песне. На плеере ты нажимаешь на кнопку перехода к следующей песне. Можно не доставая его из кармана. И вот так всё в телефоне. Все через жопу, с чудовищными дрыгающимися, выползающимися, наславивающимися интерфейсами. С кучей рекламы, картинок, анонсов, предложений, пропагации новинок и новых исполнителей, всякого говна... Задача найти свою любимую песню или плейлист превращается в квест. Телефон начинает греться, сжирает заряд за несколько часов, ты не успеваешь дойти до дома, он садится и ты не можешь вызвать такси или купить билет на электричку (а сейчас еще и получишь траблы от теток в мышином, если не включишь телефон).
Звучит красиво, но интуитивно понимаю, что когда все начнут экономить (тратя на это деньги), то облачные провайдеры просто поднимут тарифы, нивелируя эти усилия.
Вы платите не за опыт, а за нахождение на работе и выполнение должностных обязанностей.
Законом не предусмотрено уголовка за невыполнение должностных обязанностей (бгг). При невыполнение должностных обязанностей максимум, что может сделать работодатель - прервать договор найма (что логично).
Ответственность за успешное выполнение производственных задач несет (внезапно!) непосредственный начальник. Это он дает задачи согласно квалификации работника и должностной инструкции. Если работник не может выполнять задачи - начальник НЕМЕДЛЕННО должен инициировать либо пересмотр квалификации и инструкции в сторону упрощения, либо прекращение договора найма. С учетом периода учебы, онбординга и прочего.
С п. 3 вообще все просто. Я знаю одну компанию (на букву N), в которой на эту тему вообще не парились. Они нанимали вообще ВСЕХ, кто удовлетворял опубликованным требованиям, более-менее. Затем во время испытательного срока определялось, может ли соискатель выполнять соответствующие задачи. Не может - через полтора месяца расчитывали. Адью. У них из десяти таким образом нанятых работников оставалось 1-2 человека. Это не проблема работодателя, это проблема работника - соответствовать предлагаемой позиции.
Человек выходил на работу? Выходил. Вы не смогли монетизировать его скиллы и время? Это ваша проблема. Он свое время отдал. Оплатите, пожалуйста. Если бы человек не выходил на рабочее место, но при этом подделал бы табель (вы хоть знаете, что это такое?) - вот тогда это было бы мошенничество.
Объяснять шаровую молнию глюками мозга и фантазиями "свидетелей" неправомерно, так как полно материальных свидетельств взаимодействия шаровых молний с окружающими предметами.
А попробуйте написать такую-же статью, но без импортных аббревиатур и прочих "Proof-of-Concept". Все эти этапы имеют обычных русские термины, прозрачные и абсолютно понятные, которые даже в ГОСТе прописаны.
Читал я книгу банды четырех. По молодости был в восторге и тоже всем ее пихал в нос. Потом понял, что эта книга - для продажи и заработка, а эти так называемые паттерны - архитектура ради архитектуры.
Тащемта, solid - это довольно убогая формализация идеологии, которую разработал Дядя Боб. Причем, формализованная не им, а какими-то левыми людьми. Причем ТАК формализованная, и так неправильно понимаемая как формализаторами, так и большинством изучаемых solid, что Дядя Боб ругается (есть где-то видео). Если вы хотите хорошо программировать, то надо не solid по википедии или случайным статьям изучать, и тем более, ЗАЗУБРИВАТЬ, что означают буквы в этом акрониме, а почитать книги Дяди Боба.
В частности, эта S, сингл респонсибилити, понимается совершенно неправильно большинством. Большинство думает, что это значит, что класс должен делать что-то одно, и пишут буквально классы с одним-единственным методом Invoke. Сам же Дядя говорит, что классы могут содержать хоть триста методов, и тем не менее, они действительно удовлетворяют S-принципу.
И да, можно писать код, который формально удовлетворяет SOLID, и тем не менее - лютый говнокод.
Россияне проголосовали за РФ, американцы бы проголосовали за США. Не вижу проблемы.
Я вчера Луну-то снять не мог во время лунного затмения. Глазами прекрасно видно, в бинокль отлично видно (кратеры разглядывал). В телефоне вообще ничего не видно.
Ночью темный объект, пусть с огнями или контуром, как у комментатора выше, просто не отобразится в телефоне.
Вы переоцениваете возможности телефонов.
То-ли пример неверный, то ли еще что. Интеграционные тесты предназначены только для одного - тестирования интеграции - сиречь для того, чтобы проверить, что вилка с розеткой правильно спроектированы и изготовлены.
Я вижу, что тестконтейнеры хороши, когда начинаешь писать тесты в унаследованный проект, где обращение к сторонним сервисам, вроде бд, производится прямо в нижних методах. Выбрали из базы - посчитали что-то - сохранили в базу - выбрали из базы - посчитали - сохранили в базу - закончили упражнение. Такие классы не проюнитишь без серьезного перелопачивания.
Правильное решение для такого кейса - сохранеие адреса выделяется в отдельный класс. В него инжектится датасурс к базе.
userService.registerUser - такого быть не должно. Репозиторий должен делать только getUser и saveUser. getUser должен просто возвращать или null, или пользователя по верхнему регистру с идентификатором. saveUser - просто создавать или апдейтить пользователя. В базе должно быть два поля - как есть, и верхнем регистре (можно сделать индекс с верхним регистром и запрос делать UPPER(user) = :user). Никаких проверок и ошибок он не должен возвращать. Это simple объект. Проверка должна осуществляться в бизнес-классе (UserService). В нем из входа приводится к верхнему регистру, обращается к датасурсу, если есть - выбрасывается исключение, если нет - делается вызов saveUser. Этот класс и метод отлично юнит-тестится.Тестконтейнеры приходится (ПРИХОДИТСЯ!) применять в случае унаследованной системы, также когда часть логики в процедурах или сторонних системах, и на нее завязана тестируемая функциональность.Более того, я считаю, тестконтейнеры ВРЕДЯТ организации, поскольку вместо правильного разделения слоев, поощряют писать код-лапшу, в котором не применяется DI, не используется в полную мощь Spring, и обращения к сторонним сервисам производится на самых нижних уровнях. Такой бардак обязательно выйдет боком. Не говоря о том, что производительность тесконтейнеров, в отличии от юнит, ужасная - процесс разработки просто или встанет, потому что билд с тестами будет делаться по полчаса-час, либо их просто отключат.Надо просто создать условия на Земле ХУЖЕ, чем... погодите-ка...
И у светодиодных ламп?
Какие открытия в фундаментальной науке сделал Китай за последние 50 лет?
То есть, надо чтобы пластиковая упаковка для производителей пива и товаров была дороже, чем стеклянная и деревянная? И в чем проблема?
Эта проблема похожа на следующий вопрос: может ли ML-модель понять, что она такое и как она устроена?
4 Плеер юзабильнее. Чтобы перейти к следующей песне, надо телефон разблокировать - нажать на кнопку разблокировки или потапать по экрану, подержать палец на кружке, три раза сделать попытку при этом, потом перейти в приложение проигрывания, помудохаться там с интерфесом, добраться до маленькой кнопки перехода к следующей песне. На плеере ты нажимаешь на кнопку перехода к следующей песне. Можно не доставая его из кармана. И вот так всё в телефоне. Все через жопу, с чудовищными дрыгающимися, выползающимися, наславивающимися интерфейсами. С кучей рекламы, картинок, анонсов, предложений, пропагации новинок и новых исполнителей, всякого говна... Задача найти свою любимую песню или плейлист превращается в квест. Телефон начинает греться, сжирает заряд за несколько часов, ты не успеваешь дойти до дома, он садится и ты не можешь вызвать такси или купить билет на электричку (а сейчас еще и получишь траблы от теток в мышином, если не включишь телефон).
Звучит красиво, но интуитивно понимаю, что когда все начнут экономить (тратя на это деньги), то облачные провайдеры просто поднимут тарифы, нивелируя эти усилия.
Вы платите не за опыт, а за нахождение на работе и выполнение должностных обязанностей.
Законом не предусмотрено уголовка за невыполнение должностных обязанностей (бгг). При невыполнение должностных обязанностей максимум, что может сделать работодатель - прервать договор найма (что логично).
Ответственность за успешное выполнение производственных задач несет (внезапно!) непосредственный начальник. Это он дает задачи согласно квалификации работника и должностной инструкции. Если работник не может выполнять задачи - начальник НЕМЕДЛЕННО должен инициировать либо пересмотр квалификации и инструкции в сторону упрощения, либо прекращение договора найма. С учетом периода учебы, онбординга и прочего.
С п. 3 вообще все просто. Я знаю одну компанию (на букву N), в которой на эту тему вообще не парились. Они нанимали вообще ВСЕХ, кто удовлетворял опубликованным требованиям, более-менее. Затем во время испытательного срока определялось, может ли соискатель выполнять соответствующие задачи. Не может - через полтора месяца расчитывали. Адью. У них из десяти таким образом нанятых работников оставалось 1-2 человека. Это не проблема работодателя, это проблема работника - соответствовать предлагаемой позиции.
Человек выходил на работу? Выходил. Вы не смогли монетизировать его скиллы и время? Это ваша проблема. Он свое время отдал. Оплатите, пожалуйста. Если бы человек не выходил на рабочее место, но при этом подделал бы табель (вы хоть знаете, что это такое?) - вот тогда это было бы мошенничество.
Не надо сочинять ахинею про "мошенничество".
Объяснять шаровую молнию глюками мозга и фантазиями "свидетелей" неправомерно, так как полно материальных свидетельств взаимодействия шаровых молний с окружающими предметами.
Где пункт в голосовалке "Разделит судьбу NFT"?
По западным законам в договоре можно написать какие-то ограничения, которые накладываются на бизнес одной из сторон?
А попробуйте написать такую-же статью, но без импортных аббревиатур и прочих "Proof-of-Concept". Все эти этапы имеют обычных русские термины, прозрачные и абсолютно понятные, которые даже в ГОСТе прописаны.
Собственно, все эти аббревиатуры - суть только попытка формализации того, что и так известно. Плюс еще возможность заработать на написании книг.
простите, зачем писать бинарный поиск? Где? Можно начерно кейс обрисовать, когда и зачем это может понадобиться?
Читал я книгу банды четырех. По молодости был в восторге и тоже всем ее пихал в нос. Потом понял, что эта книга - для продажи и заработка, а эти так называемые паттерны - архитектура ради архитектуры.
Тащемта, solid - это довольно убогая формализация идеологии, которую разработал Дядя Боб. Причем, формализованная не им, а какими-то левыми людьми. Причем ТАК формализованная, и так неправильно понимаемая как формализаторами, так и большинством изучаемых solid, что Дядя Боб ругается (есть где-то видео). Если вы хотите хорошо программировать, то надо не solid по википедии или случайным статьям изучать, и тем более, ЗАЗУБРИВАТЬ, что означают буквы в этом акрониме, а почитать книги Дяди Боба.
В частности, эта S, сингл респонсибилити, понимается совершенно неправильно большинством. Большинство думает, что это значит, что класс должен делать что-то одно, и пишут буквально классы с одним-единственным методом Invoke. Сам же Дядя говорит, что классы могут содержать хоть триста методов, и тем не менее, они действительно удовлетворяют S-принципу.
И да, можно писать код, который формально удовлетворяет SOLID, и тем не менее - лютый говнокод.