Здесь фактически значение null могло бы появиться только в том случае, когда animatedView равен null. Добавление простой проверки if (animatedView != null) избавит нас от цепочки безопасных вызовов. Но в данном примере вообще нет необходимости в том, чтобы animatedView принимало значение null. Поэтому лучше его сделать lateinit переменной, и тогда код вообще не будет содержать проверок на null
Конечно необходимости нет. Пока однажды не отстрелите себе ногу из-за того, что инициализация почему-то не прошла либо метод вызвался до инициализации.
Может быть фрагмент сразу после создания в мусорку отправился, может быть переход слишком быстрым был, может быть ещё куча всяких условий.
lateinit не стоит бездумно лупить куда попало, обязательно нужно держать в голове порядок инициализации и использования переменной, иначе потом будет больное ой в виде UninitializedPropertyAccessException.
Опять же, в ряде отраслей у нвидии есть вкусные эксклюзивные фичи, в которые вкладывались средства. Например для любителей машинного обучения есть CUDA, для геймеров DLSS.
А с перекупами и майнерами имеем что?
* Затраты на эти фичи не отбиваются, это раз.
* Пока ты спишь, враг качается Пока карт нет в продаже, индустрия уходит на решения конкурента, это два.
Насчет дороговизны отсутствия тестов – нет, не измерял, вот честно. Но мне лично это кажется очевидным.
Кейс:
1. Разработчик пишет код без тестов. Запускает локально проект, вроде норм. Отдает тестировщикам
2. Тестировщики находят баги, возвращают
3. Разработчик продолжает ковыряться и получать зарплату
Вместо этого можно написать тесты, и тогда тестировщики не вернут задачу на доработку.
Осталось только подсчитать, программист больше времени потратит на починку багов или на написание тестов?
Что будет больше, зп программиста+зп тестировщика при починке багов или только зп программиста который обмазывается тестами по самое нехочу?
Ну и не всегда тестировщик возвращает только баги. Зачастую это и результат двусмысленности в поставленном ТЗ которое потом доуточняется продукт-овнером и спускается обратно программисту.
От такого вас тесты точно не спасут, т.к. проблема в восприятии задачи программистом, а не в коде.
И в чем проблема поменять скомпилированный исходник?
Назовём это цеховой солидарностью, поскольку
заказать сделать это у разработчиков было дорого, потому что пришлось бы оплатить предыдущие лицензии на поддержку, на которых комдир сэкономил много денег (чем особенно гордился)
премии лишить хотя-бы частично того, кто организовал процесс эксплуатации ИТ-системы без защиты от элементарных вообще-то вещей
Даже интересно стало, как бы вы решили задачу о хакере в столовой? Где проходит граница между здравым смыслом и паранойей?
Задача о хакере в столовой
Хакер приходит в общественную столовую и с возмущением обнаруживает, что солонку на столе может открутить кто попало и насыпать туда что угодно. Хакер приходит домой и пишет гневное письмо директору столовой: «Я, meG@Duc, обнаружил уязвимость солонки в Вашей столовой. Злоумышленник может вскрыть солонку и насыпать туда яду! Примите меры срочно!»
В задаче не указано что делает муравей достигнув края палки. Может падает, может вверх головой по нижней стороне ползет, может просто обратно ползет, а может в ступоре замирает.
Итого имеем задачу на сообразительность при нечетко поставленном ТЗ. Вы точно всё ещё хотите работать в нашей компании?
А откуда у Пети с Мухосрани какой-нибудь уникальный опыт?
Не знаю, но Пете регулярно написывают московские рекрутеры с предложениями по релокации на московскую зарплату. Наверное совсем в своей Москве отчаялись, раз готовы без опыта на большую зарплату звать.
Потому что у «обычных» людей либо вообще не будет зашифрованных файлов, либо они будут зашифрованы «обычными» паролями, которые в N-цать раз короче размера шифруемых данных.
Конечно необходимости нет. Пока однажды не отстрелите себе ногу из-за того, что инициализация почему-то не прошла либо метод вызвался до инициализации.
Может быть фрагмент сразу после создания в мусорку отправился, может быть переход слишком быстрым был, может быть ещё куча всяких условий.
lateinit не стоит бездумно лупить куда попало, обязательно нужно держать в голове порядок инициализации и использования переменной, иначе потом будет больное ой в виде UninitializedPropertyAccessException.
Ставим фильтр «Всё что не в вайтлисте — в /dev/null». Вы великолепны (нет)
А с перекупами и майнерами имеем что?
* Затраты на эти фичи не отбиваются, это раз.
*
Пока ты спишь, враг качаетсяПока карт нет в продаже, индустрия уходит на решения конкурента, это два.Осталось только подсчитать, программист больше времени потратит на починку багов или на написание тестов?
Что будет больше, зп программиста+зп тестировщика при починке багов или только зп программиста который обмазывается тестами по самое нехочу?
Ну и не всегда тестировщик возвращает только баги. Зачастую это и результат двусмысленности в поставленном ТЗ которое потом доуточняется продукт-овнером и спускается обратно программисту.
От такого вас тесты точно не спасут, т.к. проблема в восприятии задачи программистом, а не в коде.
Назовём это цеховой солидарностью, поскольку
Дети есть? Есть.
Гены передались? Передались.
Гарантия уже вышла, извините.
А вот если бы проджекты никаких упоминаний не оставили кроме плашки «все совпадения случайны» — был бы как раз похожий случай.
Итого имеем задачу на сообразительность при нечетко поставленном ТЗ. Вы точно всё ещё хотите работать в нашей компании?
Вот вы не пойдете за 60к работать удаленно, а Петя с Мусохрани пойдет. Или вы хотите поехать этому штрейкбрехеру морду лица портить?
А то новички потом с квадратными глазами прибегают «я стянул, а мои коммиты вжжух и потёрлись».
Посмотрим кто кого в патентовании имени заборет.
Потому что у «обычных» людей либо вообще не будет зашифрованных файлов, либо они будут зашифрованы «обычными» паролями, которые в N-цать раз короче размера шифруемых данных.