обязан скрыть эту информацию от своего работодателя, иначе ему грозит тюремное заключение
Подходит ли в качестве обхода следующий способ?
Работник компании, которому поступило предложение создать и внедрить бэкдор, идет к начальству и просит его уволить. Его увольняют, причем, для подстраховки можно оформить это по инициативе нанимателя. После чего уже бывший работник обнародует информацию о просьбе создать бэкдор. Технически у него уже нет работодателя и поэтому правило о сокрытии этой информации от своего работодателя уже не нарушено. После этого работника снова берут на работу в эту же компанию.
Сложно назвать эти особенности языка малоизвестными. Они описываются в любом более-менее толковом учебнике по JS, например, у Флэнэгана или Закаса. Скорее тут речь идет о малоиспользуемых возможностях, что неудивительно, посколько многое из перечисленного признано устаревшим подходом или плохой практикой.
Насколько я слышал для Германии, опыт нужен для работодателя, а диплом — для миграционной службы, чтобы меньше вопросов возникало, почему именно этому специалисту нужно открыть рабочую визу. Вместо профильного диплома могут прокатить какие-либо курсы и даже предметы в университетской программе, если основной профиль не ИТ, но есть какие-то ИТ-предметы.
Я понимаю вашу иронию, но в реальной жизни очень часто приходится иметь дело с кодом функции, который до тебя модифицировали в разное время 5 разных разработчиков, и не все это делали хорошо. В такой ситуации проще модифицировать уже имеющуюся функцию. Это еще больше загрязнит код, но позволит выполнить задачу, сделать это, если сроки горят и не уронить всё приложение. Я просто реально смотрю на вещи, поэтому не уверен, что языки со статической сильной типизацией позволили бы так свободно обращаться с доставшейся в наследство функцией.
Функции могут быть с одинаковой сигнатурой (иначе как потом узнать способ их вызова?), вместо false возвращать null, например.
Могут, но если вам достался код, где чья-то функция вызывается много где по коду, и вам нужно внести в нее изменение или дополнить функционал, то проще внести изменение в эту функцию, чем найти все места ее вызова, и с риском для других частей приложения вызывать в некоторых местах другую функцию, которую создали уже вы.
И этим значением будет объект, а не примитив. И уже из объекта нужно доставать значение, обращаясь к его свойству. Это усложняет структуру и понимание кода.
Почему «божественные сущности»? Можно, например, в зависимости от переданных параметров вернуть из функции «а» созданную функцию «b», можно вернуть функцию «с», а можно вернуть «false», если что-то пошло не так.
Точность, достойная тру-разработчика. Просто восхитительно. Надеюсь, вас в жизни не допустят до написания кода систем, имеющих хоть какое-то отношение к человеческому здоровью/жизни.
Спасибо за характеристику меня, как разработчика)) Но я в своем развернутом мнении выше как раз и описал, что это
… неприемлемо в ПО, предназначенном, скажем, для медицины и космоса, но вполне допустимо для показа на карте 10 ближайших баров в округе
Особенно, если приложение для показа баров должно было быть готово «вчера», но узнали об этом, как обычно, сегодня.
Массив содержит данные одного типа (и его подтипов). То, о чем вы говорите, является кортежем.
Спасибо! Вот то, что я имел ввиду. Сказываются различия в терминологии в ЯП)) Значит мое утверждение под номером 5 выше, по крайней мере, для C# неактуально.
Тем, что внутри вашего массива лежит объект, который при итерации выдаст в качестве item именно объект. В моем примере на JS при итерации, скажем, с использованием «forEach» вы получаете доступ сразу к нужному значению массива. Также мне хотелось бы узнать, сможете ли вы передать созданный вами массив в функцию в качестве параметра?
Почему «к сожалению»? Что в этом подходе не так? Он позволяет создавать исключительно гибкие функции, код в которых не будет падать с ошибкой при неправильных или недостаточных входных данных.
Программист, когда писал функцию, рассчитывал что у переданных ему объектов есть вполне конкретные поля. Без этих полей функция будет работать не так, как задумывалось ее автором
Нет, поведение функции может подстраиваться под переданные аргументы и их количество или даже их отсутствие. А способ подстраивания обычно и задумывается автором.
Очень сложно придумать кейс, когда действительно нужна такая вариативность и нет нарушения SRP.
Ну не знаю, может быть, вас это удивит, но в своей работе я практически ежедневно сталкиваюсь с подобным кодом. Именно поэтому эта особенность вспомнилась мне одной из первых.
Подходит ли в качестве обхода следующий способ?
Работник компании, которому поступило предложение создать и внедрить бэкдор, идет к начальству и просит его уволить. Его увольняют, причем, для подстраховки можно оформить это по инициативе нанимателя. После чего уже бывший работник обнародует информацию о просьбе создать бэкдор. Технически у него уже нет работодателя и поэтому правило о сокрытии этой информации от своего работодателя уже не нарушено. После этого работника снова берут на работу в эту же компанию.
Или повесить на бэкдор лэйбл «Do not merge»
Так SRP это подход объектно-ориентированного, но не функционального программирования.
Спасибо! Вот то, что я имел ввиду. Сказываются различия в терминологии в ЯП)) Значит мое утверждение под номером 5 выше, по крайней мере, для C# неактуально.
А чем это тогда отличается от того, что есть в JS по умолчанию?