Странно, я всегда считал это адекватным поведением - когда ты запрещаешь любую фоновую активность приложению и оно реально не работает в фоне, если не свернуто. А если свернул и зашел в список последних приложений, после нажатия кнопки закрытия - они все закрываются и перестают работать. Сейчас на Realme, несмотря на все запреты, после перезагрузки устройства - все приложения начинают работать в фоне и присылать уведомления. Приходится заходить в список приложений и принудительно останавливать их. Аналогично и после использования какого-либо и закрытия всех последних - они все еще работают в фоне и шлют уведомления до прожатия "force stop". Очень раздражает.
В опросе мы просили указать ежемесячный доход в той валюте, в какой получаете зарплату, после вычета налогов и с учётом всех премий и надбавок.
Какой-то странный вариант. Премию могут не выплатить, т.к. не были достигнуты цели и т.д. Соответственно доход сократится. Если рассматривается "теоретический" доход, то он не соответствует реальности. Да и размеры премий у людей очень уж разный.
Как учитываются бонусы от компании - спортзал, ДМС, оплата связи, оборудование и т.п.?
и рассчитали медианные значения по нужным срезам
Как был произведен расчет с разбивкой по территориальным признакам? Если з/п в ₽, то это Россия или другие страны? А если проживаешь в Тайланде? Если з/п в $, проживаешь в Нигерии, работаешь удаленно в компании из РФ, то в куда относится зарплата?
Тэг на сервисе не должен говорить, как он это делает (file/rabbit/postgres), а должен говорить, какой бизнес-сценарий работает.
Согласен. В таком случае мы реализуем любую логику для конкретной ответственности (контроллера) независимо от других ответственностей. Так же это позволяет использовать внутри конкретных методов дополнительные зависимости для тех же логов.
Это отличное решение, на самом деле. Я пытался это объяснить, но, возможно, некорректно это сделал.
Но будем честны — это не решает проблему. Проще сразу поставить в зависимости конкретные типы.
Почему не решает? Потому что нужно будет один раз отредактировать нужные контроллеры?
Поставив конкретные типы вы обрекаете себя на необходимость изменять эти типы, если для какого-то сервиса вдруг понадобится подменить провайдер логирования, например для тестов. В случае именованной регистрации сервисов - достаточно будет подменить реализацию только в Startup.cs.
А именованные зависимости ещё и создают видимость какой-то правильности, хотя по существу являются нарушением инверсии зависимостей и требуют точно такой же конкретики, только каким-то очень извилистым образом.
Почему? Под именем "file" может скрываться создание файла с описанием ошибки и отправки его на почту разработчику, а может скрываться реализация записи данных в стандартный журнал ОС или что-то еще.
Да, вы зависите от конкретного именованного сервиса, но при этом не знаете какая реализация скрыта за этим именем, т.е. вы все еще зависите от абстракции (чуть более конкретной, но все еще абстракции), что и является определением инверсии зависимостей.
SOLID - это рекомендации по разработке ПО, а не конкретные требования. Иначе можем дойти до того, что нужны разные DTO и контроллеры для каждого действия CRUD над моделью данных из-за принципа единственной ответственности.
когда кто-то запрашивает зависимость, то он может предоставить поставщику критерий, в соответствии с которым тот может резолвить зависимости для него.
передав что именно запрашивается и кто именно запрашивает.
Ну т.е. конкретному поставщику зависимостей нужно будет знать о существовании всех контроллеров и на основе наименования/содержания/типа определять какой именно провайдер логирования нужен. В итоге, мы получим необходимость изменять +- тот же объем кода, просто в одном конкретном файле, а не в разных, при его добавлении в систему. В дальнейшем нам будет недостаточно сконфигурировать сервис в конструкторе, т.к. необходимо будет его добавить в поставщика зависимостей. А самый главный вопрос: какая именно реализация будет подставлена в контроллер, если мы забудем добавить его в список поставщика зависимостей? Как-то сложно, нет?
Да и именно этот вариант уже нарушает инверсию зависимостей, т.к. "модули должны зависеть от абстракций", а в вашем примере поставщик зависит от конкретного типа контроллера.
предоставить поставщику критерий, в соответствии с которым тот может резолвить зависимости для него.
Так вы и так предоставляете критерий при именованных зависимостях - имя.
Довольно много клавиатур умеют подключаться по 2.4 ГГц. Если китай не пугает и готовы ждать, то можете посмотреть на Akko и FL Esports, например. У них и для самостоятельной сборки были отдельные компоненты. Подсветки всякие разные - отключаются естественно.
Нет одного какого-то языка на все случаи жизни. Что-то удобнее делать на одном, что-то на другом. И упираться в "я пишу только на С/С++" непродуктивно. Разработчик - это прежде всего подходы к решению задач. А язык - инструмент. Знаешь несколько языков - можешь выбирать наиболее подходящий инструмент для решения конкретной задачи.
В целом, я согласен с этим утверждением.
Но, для некоторых задач может быть несколько оптимальных инструментов достижения поставленной цели. И здесь необходимо следовать регламентам и правилам, установленным в команде, в том числе и по стеку.
Специфика в том, что "будет работать быстрее" здесь является абсолютным приоритетом.
Технологический стек жестко определен. Кроме того, есть достаточно объемные "нефункциональные требования" - что можно что нельзя. На самом деле правил очень много.
Так в этом и суть - у вас есть правила и ограничения на стек, которые необходимы именно вашей команде. Эти правила были обоснованы, а не придуманы с потолка. Они призваны решать множество вопросов связанных с разработкой продукта, его приоритетов, кодовой базой и т.д. И если кто-то решит написать кусок проекта на Python, даже если он будет работать быстрее аналогичного кода на IBM RPG и С/С++ - это будет порицаться, надо будет переделывать на имеющийся стек, потому что есть ограничения.
В статье же прямо говорится, что подобное ограничение - "неразумно" и нуждается в переосмыслении. Прочитайте пункт 4 ("Мы пишем только натаком-то языке") в статье.
Дальше идет не менее важный кусок:
Если это опытный программист, и в большинстве случаев поступает разумно, то может и не надо его ограничивать всякой фигнёй — это уменьшение эффективности, да еще и снижение мотивации
И ежу понятно, что вникнуть в суть вашего стека и сделать задачу, в сравнении с реализацией этой задачи на известном кандидату стеке - менее эффективно по скорости разработки и меньше мотивирует кандидата, т.к. вместо написания кода и получения плюшек за сделанную задачу - придется потратить больше времени, лазить по документации в поисках нужных функций и только когда-то потом сделать задачу. Но несмотря на это, ограничения стека разумны и необходимы, чтобы итоговый продукт не превращался во франкенштейна.
У вас есть четко установленные рамки. Это разумный подход, без них - проект превратился бы именно в такую мешанину технологий в разных модулях.
Вы определились с ядром системы (IBM RPG, как я понял). Применение С/С++ - обосновано удобством разработки и быстродействием, а значит у вас в команде все (или какая-то часть) понимают и умеют писать на этих языках. И т.д. У вас все равно установлены определенные рамки по разработке, по допустимым технологиям и т.д.
Давайте просто допустим что в вашей команде я новенький и единственный знаю Python, в добавок к текущему стеку. Получаю задачу сделать какую-то фишку и я ее уже делал на Python в другом проекте, и хочу применить его здесь - это будет более эффективно, с точки зрения времени разработки, и более мотивированно, т.к. я смогу закрыть задачу. Правильно? Но что будет если никто не знает Python, или на условном С++ модуль будет работать быстрее?
Вы не можете по своему желанию или просто потому что знаете как что-то сделать на условном Python, использовать именно его для разработки какого-то модуля. Вам так же необходимо, как минимум, обосновать необходимость его применения перед командой и убедиться что есть другие разработчики, которые "умеют в Python". Это и есть те самые "ограничения всякой фигней", которые просто необходимы, дабы кодовая база оставалась в более-менее адекватном виде.
Если нет вообще никаких ограничений, то разработка очень быстро может скатиться в "Повелителя мух"
Если DRY, KISS и иже с ними доведено именно до непреложных правил и заповедей, то тут явно что-то не так. Если все еще и утрируется, как в примерах, то это уже надо звать людей в белых халатах. Можно же и SRP интерпретировать как необходимость создавать отдельное DTO для каждой операции над основным объектом...
Если это опытный программист, и в большинстве случаев поступает разумно, то может и не надо его ограничивать всякой фигнёй — это уменьшение эффективности, да еще и снижение мотивации
Ядро проекта пишем на Java, добавляем кусок на Python, пара кусков на Go, еще один прям микро-микросервис на PHP, обработку данных делаем на С++ и немного макросов в Excel.... Зато все очень эффективно и замотивировано было сделано. А потом разработчик, который был ответственен за вот эти все языковые "причуды", увольняется и вам приходится искать такого "многофункционального", эффективного и замотивированного разработчика на проект с непонятным стеком. Нормальная идея, да.
По факту же, DRY & KISS & другие заголовки - это скорее принципы, концепция, если хотите, которые позволяют держаться в некоторых рамках и с большей вероятностью получить на выходе качественный код, с которым будет удобно дальше работать, независимо от смены состава команды. И их нужно не просто прочитать и запомнить, а именно обдумать почему, что, как, где можно отойти, где нельзя и т.д. Все это приходит только с опытом.
И какие-то минимальные строгие рамки должны быть, иначе есть немалая вероятность, что на выходе получите кусок "продукта", с которым дальше никто не захочет работать, ибо разгребать авгиевы конюшни - неблагодарное дело.
Основная опасность в том, что компилятор не может корректно проверить ошибки при работе с dynamic объектом (вызов несуществующего метода и т.п.), они будут выявлены только во время выполнения программы. В dynamic можно записать все что угодно. Ну а когда тебе возвращается такое аморфное нечто - вероятность ошибки существенно возрастает. Какой бы не была нужда, в типизированных языках программирования - лучше всего возвращать объект конкретного типа или интерфейса.
чтобы в публикации работ не было больших пробелов. GitHub тоже показывает активность кандидата: в какие дни и где кандидат работал.
Большинство компаний запрещает публиковать рабочий код в открытые источники, для этого есть внутренняя система контроля версий. Другие причины даже называть не имеет смысла. Соответственно "пустой GitHub" или "большие пробелы" - никак не характеризуют кандидата.
умеет ли кратко презентовать себя как специалиста
И никаких общих критериев для этого нет. Для одного работодателя ты умеешь в самопрезентацию, рассказав про свой любимый мультфильм детства, для другого - не хватит и подробного описания всех рабочих проектов.
Если я публикую вакансию в этом месте, значит, мои взгляды совпадают с ценностями создателя канала и его аудитории.
А как работодатель смотрит на то, что HR ищет кандидата "под свои взгляды", а не взгляды компании? Одобряет ли тот факт, что HR отрезает добрую часть кандидатов, которые либо не знают про блогера/канал, либо не сходятся с ним во "взглядах"? На мой взгляд, это скорее "звоночек", что с компанией что-то не так. Как минимум, она не заботится о том, что бы сотрудники разделяли рабочие и личные моменты.
Как минимум не хватает третьего типа разработчика, который сочетает в себе черты первого и второго типов. Ибо из первого примера Тип 1 - прав, т.к. большинство людей поймет, если их просто попросить. Но если не понимают, или просто игнорируют, то плавно переходим к рассуждениями Типа 2. А из второго примера - если не получилось сделать интутивно понятный алгоритм выполнения какой-то операции, то ее необходимо задокументировать и каким-то образом гарантировать ознакомление пользователей.
Странно, я всегда считал это адекватным поведением - когда ты запрещаешь любую фоновую активность приложению и оно реально не работает в фоне, если не свернуто. А если свернул и зашел в список последних приложений, после нажатия кнопки закрытия - они все закрываются и перестают работать.
Сейчас на Realme, несмотря на все запреты, после перезагрузки устройства - все приложения начинают работать в фоне и присылать уведомления. Приходится заходить в список приложений и принудительно останавливать их. Аналогично и после использования какого-либо и закрытия всех последних - они все еще работают в фоне и шлют уведомления до прожатия "force stop". Очень раздражает.
Какой-то странный вариант. Премию могут не выплатить, т.к. не были достигнуты цели и т.д. Соответственно доход сократится. Если рассматривается "теоретический" доход, то он не соответствует реальности. Да и размеры премий у людей очень уж разный.
Как учитываются бонусы от компании - спортзал, ДМС, оплата связи, оборудование и т.п.?
Как был произведен расчет с разбивкой по территориальным признакам? Если з/п в ₽, то это Россия или другие страны? А если проживаешь в Тайланде? Если з/п в $, проживаешь в Нигерии, работаешь удаленно в компании из РФ, то в куда относится зарплата?
Согласен. В таком случае мы реализуем любую логику для конкретной ответственности (контроллера) независимо от других ответственностей. Так же это позволяет использовать внутри конкретных методов дополнительные зависимости для тех же логов.
Это отличное решение, на самом деле. Я пытался это объяснить, но, возможно, некорректно это сделал.
Почему не решает? Потому что нужно будет один раз отредактировать нужные контроллеры?
Поставив конкретные типы вы обрекаете себя на необходимость изменять эти типы, если для какого-то сервиса вдруг понадобится подменить провайдер логирования, например для тестов. В случае именованной регистрации сервисов - достаточно будет подменить реализацию только в
Startup.cs.Почему? Под именем
"file"может скрываться создание файла с описанием ошибки и отправки его на почту разработчику, а может скрываться реализация записи данных в стандартный журнал ОС или что-то еще.Да, вы зависите от конкретного именованного сервиса, но при этом не знаете какая реализация скрыта за этим именем, т.е. вы все еще зависите от абстракции (чуть более конкретной, но все еще абстракции), что и является определением инверсии зависимостей.
SOLID - это рекомендации по разработке ПО, а не конкретные требования. Иначе можем дойти до того, что нужны разные DTO и контроллеры для каждого действия CRUD над моделью данных из-за принципа единственной ответственности.
Ну т.е. конкретному поставщику зависимостей нужно будет знать о существовании всех контроллеров и на основе наименования/содержания/типа определять какой именно провайдер логирования нужен. В итоге, мы получим необходимость изменять +- тот же объем кода, просто в одном конкретном файле, а не в разных, при его добавлении в систему. В дальнейшем нам будет недостаточно сконфигурировать сервис в конструкторе, т.к. необходимо будет его добавить в поставщика зависимостей. А самый главный вопрос: какая именно реализация будет подставлена в контроллер, если мы забудем добавить его в список поставщика зависимостей? Как-то сложно, нет?
Да и именно этот вариант уже нарушает инверсию зависимостей, т.к. "модули должны зависеть от абстракций", а в вашем примере поставщик зависит от конкретного типа контроллера.
Так вы и так предоставляете критерий при именованных зависимостях - имя.
Довольно много клавиатур умеют подключаться по 2.4 ГГц. Если китай не пугает и готовы ждать, то можете посмотреть на Akko и FL Esports, например. У них и для самостоятельной сборки были отдельные компоненты. Подсветки всякие разные - отключаются естественно.
Так тут в комплекте идет возможность подключать по проводу, BLE и 2.4 Гц (usb приемник в комплекте). Да и у многих есть подобные возможности.
В целом, я согласен с этим утверждением.
Но, для некоторых задач может быть несколько оптимальных инструментов достижения поставленной цели. И здесь необходимо следовать регламентам и правилам, установленным в команде, в том числе и по стеку.
Так в этом и суть - у вас есть правила и ограничения на стек, которые необходимы именно вашей команде. Эти правила были обоснованы, а не придуманы с потолка. Они призваны решать множество вопросов связанных с разработкой продукта, его приоритетов, кодовой базой и т.д. И если кто-то решит написать кусок проекта на Python, даже если он будет работать быстрее аналогичного кода на IBM RPG и С/С++ - это будет порицаться, надо будет переделывать на имеющийся стек, потому что есть ограничения.
В статье же прямо говорится, что подобное ограничение - "неразумно" и нуждается в переосмыслении. Прочитайте пункт 4 ("Мы пишем только на таком-то языке") в статье.
Дальше идет не менее важный кусок:
И ежу понятно, что вникнуть в суть вашего стека и сделать задачу, в сравнении с реализацией этой задачи на известном кандидату стеке - менее эффективно по скорости разработки и меньше мотивирует кандидата, т.к. вместо написания кода и получения плюшек за сделанную задачу - придется потратить больше времени, лазить по документации в поисках нужных функций и только когда-то потом сделать задачу.
Но несмотря на это, ограничения стека разумны и необходимы, чтобы итоговый продукт не превращался во франкенштейна.
У вас есть четко установленные рамки. Это разумный подход, без них - проект превратился бы именно в такую мешанину технологий в разных модулях.
Вы определились с ядром системы (IBM RPG, как я понял). Применение С/С++ - обосновано удобством разработки и быстродействием, а значит у вас в команде все (или какая-то часть) понимают и умеют писать на этих языках. И т.д. У вас все равно установлены определенные рамки по разработке, по допустимым технологиям и т.д.
Давайте просто допустим что в вашей команде я новенький и единственный знаю Python, в добавок к текущему стеку. Получаю задачу сделать какую-то фишку и я ее уже делал на Python в другом проекте, и хочу применить его здесь - это будет более эффективно, с точки зрения времени разработки, и более мотивированно, т.к. я смогу закрыть задачу. Правильно? Но что будет если никто не знает Python, или на условном С++ модуль будет работать быстрее?
Вы не можете по своему желанию или просто потому что знаете как что-то сделать на условном Python, использовать именно его для разработки какого-то модуля. Вам так же необходимо, как минимум, обосновать необходимость его применения перед командой и убедиться что есть другие разработчики, которые "умеют в Python". Это и есть те самые "ограничения всякой фигней", которые просто необходимы, дабы кодовая база оставалась в более-менее адекватном виде.
Если нет вообще никаких ограничений, то разработка очень быстро может скатиться в "Повелителя мух"
Если DRY, KISS и иже с ними доведено именно до непреложных правил и заповедей, то тут явно что-то не так. Если все еще и утрируется, как в примерах, то это уже надо звать людей в белых халатах. Можно же и SRP интерпретировать как необходимость создавать отдельное DTO для каждой операции над основным объектом...
Ядро проекта пишем на Java, добавляем кусок на Python, пара кусков на Go, еще один прям микро-микросервис на PHP, обработку данных делаем на С++ и немного макросов в Excel.... Зато все очень эффективно и замотивировано было сделано. А потом разработчик, который был ответственен за вот эти все языковые "причуды", увольняется и вам приходится искать такого "многофункционального", эффективного и замотивированного разработчика на проект с непонятным стеком. Нормальная идея, да.
По факту же, DRY & KISS & другие заголовки - это скорее принципы, концепция, если хотите, которые позволяют держаться в некоторых рамках и с большей вероятностью получить на выходе качественный код, с которым будет удобно дальше работать, независимо от смены состава команды. И их нужно не просто прочитать и запомнить, а именно обдумать почему, что, как, где можно отойти, где нельзя и т.д. Все это приходит только с опытом.
И какие-то минимальные строгие рамки должны быть, иначе есть немалая вероятность, что на выходе получите кусок "продукта", с которым дальше никто не захочет работать, ибо разгребать авгиевы конюшни - неблагодарное дело.
Основная опасность в том, что компилятор не может корректно проверить ошибки при работе с dynamic объектом (вызов несуществующего метода и т.п.), они будут выявлены только во время выполнения программы.
В dynamic можно записать все что угодно. Ну а когда тебе возвращается такое аморфное нечто - вероятность ошибки существенно возрастает.
Какой бы не была нужда, в типизированных языках программирования - лучше всего возвращать объект конкретного типа или интерфейса.
Большинство компаний запрещает публиковать рабочий код в открытые источники, для этого есть внутренняя система контроля версий. Другие причины даже называть не имеет смысла.
Соответственно "пустой GitHub" или "большие пробелы" - никак не характеризуют кандидата.
И никаких общих критериев для этого нет. Для одного работодателя ты умеешь в самопрезентацию, рассказав про свой любимый мультфильм детства, для другого - не хватит и подробного описания всех рабочих проектов.
А как работодатель смотрит на то, что HR ищет кандидата "под свои взгляды", а не взгляды компании? Одобряет ли тот факт, что HR отрезает добрую часть кандидатов, которые либо не знают про блогера/канал, либо не сходятся с ним во "взглядах"?
На мой взгляд, это скорее "звоночек", что с компанией что-то не так. Как минимум, она не заботится о том, что бы сотрудники разделяли рабочие и личные моменты.
А на IOS разве можно использовать что-то кроме WebKit для браузеров?
Как минимум не хватает третьего типа разработчика, который сочетает в себе черты первого и второго типов.
Ибо из первого примера Тип 1 - прав, т.к. большинство людей поймет, если их просто попросить. Но если не понимают, или просто игнорируют, то плавно переходим к рассуждениями Типа 2.
А из второго примера - если не получилось сделать интутивно понятный алгоритм выполнения какой-то операции, то ее необходимо задокументировать и каким-то образом гарантировать ознакомление пользователей.