Исходное сообщение
"Бэкдор в 93 плагинах и темах оформления AccessPress, применя..." Отправлено Ordu, 24-Янв-22 07:52
Типа нереально. При попытке сделать так возникает куча проблем организационного и экономического толка. Например, привязка к этой гомогенности. Пройдёт лет пять, и железо потребуется обновлять или расширять, но в случае заточенного под конкретную железку кода, вариант со сменой железа станет гораздо дороже. То есть, сильно затачиваясь на что-то, мы приносим в жертву будущую гибкость принятия решений. Стоит ли оно того? А тут мы подходим к проблеме бюрократии и разделения ответственности за принятие решений. Это в принципе большая и сложная организационная проблема: часто при принятии решения основные риски берёт на себя не тот, кто квалифицирован в достаточной мере, чтобы принимать такое решение. Например, рискующим больше всех может быть инвестор. А достаточно квалифицированным может быть менеджер среднего звена. И как? На этого менагера невозможно свалить финансовые риски, связанные с решением. А попытка вынудить инвестора принять риски будет связана с тем, что инвестор должен будет _поверить_ специалистам, что риск стоит того. А если решение окажется неудачным? Доверию придёт конец. CEO уволят, а может не только его. Кому это надо? Или другая проблема: кто будет оптимизировать так код? Крутой спец, этт понятно, но каким будет его положение в организации? Рядовой девелопер? Чем он будет заниматься после окончания деятельности по созданию такой оптимизированной реализации? Если мы не найдём ему полезной (aka приносящей денег) деятельности, то он будет висеть на организации мёртвым грузом: зарплату получает, денег не приносит. Если же мы его уволим, то что будем делать в случае проблем с его кодом? В каких-то специальных случаях может быть выгодно так оптимизировать. В криптомайнинге, например. Но во многих-многих других проще (и дешевле, и надёжнее) купить больше железа. > Типа нереально? Хорошей эвристикой реальности или нереальности какого-то замысла являются примеры успешной реализации этого замысла. Настолько хорошей, что когда какой-то замысел кажется удачным, но ты не видишь примеров его реализации, то дефолтным выводом твоим должен быть вывод о нереальности замысла. Дефолтным -- это в том смысле, что другой вывод возможен только после того, как ты нашёл объяснение наблюдаемому отсутствию реализаций замысла.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Типа нереально. При попытке сделать так возникает куча проблем организационного и экономического > толка. Например, привязка к этой гомогенности. Пройдёт лет пять, и железо > потребуется обновлять или расширять, но в случае заточенного под конкретную железку > кода, вариант со сменой железа станет гораздо дороже. То есть, сильно > затачиваясь на что-то, мы приносим в жертву будущую гибкость принятия решений. > Стоит ли оно того? > А тут мы подходим к проблеме бюрократии и разделения ответственности за принятие > решений. Это в принципе большая и сложная организационная проблема: часто при > принятии решения основные риски берёт на себя не тот, кто квалифицирован > в достаточной мере, чтобы принимать такое решение. Например, рискующим больше всех > может быть инвестор. А достаточно квалифицированным может быть менеджер среднего звена. > И как? На этого менагера невозможно свалить финансовые риски, связанные с > решением. А попытка вынудить инвестора принять риски будет связана с тем, > что инвестор должен будет _поверить_ специалистам, что риск стоит того. А > если решение окажется неудачным? Доверию придёт конец. CEO уволят, а может > не только его. Кому это надо? > Или другая проблема: кто будет оптимизировать так код? Крутой спец, этт понятно, > но каким будет его положение в организации? Рядовой девелопер? Чем он > будет заниматься после окончания деятельности по созданию такой оптимизированной реализации? > Если мы не найдём ему полезной (aka приносящей денег) деятельности, то > он будет висеть на организации мёртвым грузом: зарплату получает, денег не > приносит. Если же мы его уволим, то что будем делать в > случае проблем с его кодом? > В каких-то специальных случаях может быть выгодно так оптимизировать. В криптомайнинге, > например. Но во многих-многих других проще (и дешевле, и надёжнее) купить > больше железа. >> Типа нереально? > Хорошей эвристикой реальности или нереальности какого-то замысла являются примеры успешной > реализации этого замысла. Настолько хорошей, что когда какой-то замысел кажется удачным, > но ты не видишь примеров его реализации, то дефолтным выводом твоим > должен быть вывод о нереальности замысла. Дефолтным -- это в том > смысле, что другой вывод возможен только после того, как ты нашёл > объяснение наблюдаемому отсутствию реализаций замысла.
	Введите код, изображенный на картинке: