Звучит как, "мне под 60 и я не буду учить что то новое. Нас и так не плохо кормят".
Скорее так: "Есть библиотека на другом языке, использование которой приводит к критическим ошибкам из-за кода самой библиотеки - кто, когда и как исправит ее?"
Т.е. вам либо нужно изучать другой язык, что бы самостоятельно внести нужные изменения, либо искать человека, который уже знает этот язык и сможет внести необходимые изменения, кооперироваться, тестировать и т.д. А если что-то сломалось в другой части проекта из-за этого изменения - начинать сначала? Если же все написано на одном языке - можно спокойно самостоятельно внести необходимые изменения, протестировать и т.д. И если что-то сломалось в другой части проекта - другой разработчик сможет самостоятельно внести изменения. По скорости и удобству, последний вариант - выигрывает.
Изучение другого языка требует времени, при этом никто не даст гарантий того, что потраченный год (условно) позволит писать хороший код на новом языке. Но есть и дополнительные проблемы - отсутствие свободного времени (все же взрослые люди, семья, дети, банальная усталость), потеря скорости обучения с возрастом и т.д. Т.е. для перехода старых разработчиков на новый стек потребуется неизвестное кол-во времени и это без какой-либо гарантии результата.
Вообще есть три вопроса, на которые нужно ответить перед написанием документации:
Для кого пишется документ?
Если документ пишется для себя, то формат, используемые фичи и т.п. вещи - не имеют значения. Делайте так, как вам будет удобно потом воспринимать текст. Если пишите для команды, пользователей, руководства и т.д., то следует использовать те инструменты, с которыми они знакомы и которые им будет удобно воспринимать. Я, например, периодически использую plantuml в markdown файлах, но для многих без "итоговых картинок" - это будет не читаемо.
Где будут читать документ наиболее часто?
Удаленный терминал с низким разрешением экрана - строгие ограничения под него. 128к монитор - ограничения под него. Сайт - ограничения под сайт. И т.д.
В каком формате будут читать документ?
Сам исходный файл - тогда делаем его максимально понятным для чтения, таблицы только небольшие, однострочные и т.д. и т.п. Сгенерированный документ PDF или предпросмотр - хоть смайлик розового слона верхом на единороге используй для выделения заголовков вместо #, главное чтоб в итоговом виде было читабельно.
Как видно, восприятие таблицы в PDF значительно ухудшается: три страницы против одной.
О нет, используя таблицы в документации вы провоцируете производить больше виртуальной бумаги и тем самым лишаете домика множество индексов БД!
А вообще это отличный пример того, как автор нарушает собственный же совет (не перегружать ячейки содержимым) для доказательства своей точки зрения :)
Скрытый текст
Конвертировал через VSCode Markdown-PDF со стандартными настройками
Поиграться со шрифтами убрать колонтитулы и глядишь все уместится на один лист. Если выкинуть допустимые значения NGINX_GZIP_PROXIED в отдельную таблицу и поставить на нее ссылку, то будет еще лучше. Цветовая схема не очень, да, правится в конфиге.
К сожалению, я не нашел явных преимуществ использования таблиц в данном контексте
У меня RG35XX обычная с Garlic OS. Характеристики похуже (quad-core ARM Cortex-A9, 256мб ОЗУ DDR3 и т.д.). Тянет все до PS1 без особых нареканий. У модели RG35XX H добавлены эмуляторы PSP/Dreamcast/N64, возможно NDS (точно не помню), и стоит Allwinner H700 (в целом, характеристики идентичны новой консоли). Насколько знаю, проблемы с играми на добавленных эмуляторах встречаются только на "тяжелых" играх. Но там хотя бы стики имеются, а тут этого нет.
Использовать "Теги", которые есть в Outlook - да не, бред. Уведомления о доставке и прочтении - так же бред.
Что посоветуете?
Для начала, в случае игнора на первое письмо - использовать фишки почты, о которых написал выше. И использовать правильную нумерацию, ибо у вас один пункт пропущен:
Конкретика. В письме не должно быть воды. Вопросы должны быть простыми, понятными, без додумываний, двойных смыслов и т. п. «Подскажите по срокам» — это непонятно, т.к. можно подсказать «адекватные ли сроки», «уложимся ли мы в них», «будет ли готово день в день или раньше» и т. д. Конкретный вопрос — залог успеха. Простой конкретизированный вопрос - проще дать ответ сразу. Сложный вопрос с неопределенным смыслом - надо обдумать и потом как-нибудь отвечу.
По остальным пунктам уже критика:
Да
Бред. Почему именно 2 минуты? У меня может не быть сейчас 2х минут на болтовню с кем-либо. У меня может вообще не быть времени на разговоры с этими "эээээээм, амммммммм, хммм". Так же полностью нарушает первый пункт - на тему чего разговаривать то собралась? Видео с котиками обсудить? Может разговор затянется, т.к. к вашим вопросам необходимо подготовиться, подняв кипу документов или задач. В 99% случаях подобные запросы на "беседу" будут игнорироваться. Кроме того, устный ответ - это ответ без явного подтверждения, так что все равно будете повторно запрашивать ответ в письме, т.е. придется делать двойную работу и тратить заметно больше времени.
Это добавляет плюсов в пользу нежелания с вами общаться. Стандартные способы выделения - полужирный, курсив и подчеркивание - ничем не хуже, при этом вызывают меньше гнева и никак вообще не страдают от настроек почтового клиента или ОС.
Первый раз просто пишете письмо человеку, от которого нужен ответ. Второй раз пишете такое же письмо с тегами "важно, срочно и т.д.". В третий раз уже добавляете руководителей. Если сразу добавляете руководителя - идете нафиг, еще и руководитель подкинет пару крепких слов для ускорения движения в заданном направлении. Исключения - прям очень срочные письма, но такие встречаются крайне редко.
Есть ощущение, что вы не понимаете куда вообще надо писать и пишете случайному разработчику команды, которая ответственна за задачу. В первую очередь необходимо найти к кому непосредственно обращаться.
Дефолт
Никак не влияет.
Рабочее письмо - это не курсовая, нир или вкр, тут не нужно воды вообще. Максимально кратко и понятно описали что вам нужно - получили ответ. Налили воды - ваше письмо будет в числе последних, на которое будут тратить свое время.
Странно, я всегда считал это адекватным поведением - когда ты запрещаешь любую фоновую активность приложению и оно реально не работает в фоне, если не свернуто. А если свернул и зашел в список последних приложений, после нажатия кнопки закрытия - они все закрываются и перестают работать. Сейчас на 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. А из второго примера - если не получилось сделать интутивно понятный алгоритм выполнения какой-то операции, то ее необходимо задокументировать и каким-то образом гарантировать ознакомление пользователей.
Пробовали Markor?
Скорее так: "Есть библиотека на другом языке, использование которой приводит к критическим ошибкам из-за кода самой библиотеки - кто, когда и как исправит ее?"
Т.е. вам либо нужно изучать другой язык, что бы самостоятельно внести нужные изменения, либо искать человека, который уже знает этот язык и сможет внести необходимые изменения, кооперироваться, тестировать и т.д. А если что-то сломалось в другой части проекта из-за этого изменения - начинать сначала?
Если же все написано на одном языке - можно спокойно самостоятельно внести необходимые изменения, протестировать и т.д. И если что-то сломалось в другой части проекта - другой разработчик сможет самостоятельно внести изменения.
По скорости и удобству, последний вариант - выигрывает.
Изучение другого языка требует времени, при этом никто не даст гарантий того, что потраченный год (условно) позволит писать хороший код на новом языке. Но есть и дополнительные проблемы - отсутствие свободного времени (все же взрослые люди, семья, дети, банальная усталость), потеря скорости обучения с возрастом и т.д. Т.е. для перехода старых разработчиков на новый стек потребуется неизвестное кол-во времени и это без какой-либо гарантии результата.
Вообще есть три вопроса, на которые нужно ответить перед написанием документации:
Для кого пишется документ?
Если документ пишется для себя, то формат, используемые фичи и т.п. вещи - не имеют значения. Делайте так, как вам будет удобно потом воспринимать текст.
Если пишите для команды, пользователей, руководства и т.д., то следует использовать те инструменты, с которыми они знакомы и которые им будет удобно воспринимать.
Я, например, периодически использую plantuml в markdown файлах, но для многих без "итоговых картинок" - это будет не читаемо.
Где будут читать документ наиболее часто?
Удаленный терминал с низким разрешением экрана - строгие ограничения под него. 128к монитор - ограничения под него. Сайт - ограничения под сайт. И т.д.
В каком формате будут читать документ?
Сам исходный файл - тогда делаем его максимально понятным для чтения, таблицы только небольшие, однострочные и т.д. и т.п.
Сгенерированный документ PDF или предпросмотр - хоть смайлик розового слона верхом на единороге используй для выделения заголовков вместо #, главное чтоб в итоговом виде было читабельно.
О нет, используя таблицы в документации вы провоцируете производить больше виртуальной бумаги и тем самым лишаете домика множество индексов БД!
А вообще это отличный пример того, как автор нарушает собственный же совет (не перегружать ячейки содержимым) для доказательства своей точки зрения :)
Скрытый текст
Поиграться со шрифтами убрать колонтитулы и глядишь все уместится на один лист.
Если выкинуть допустимые значения
NGINX_GZIP_PROXIEDв отдельную таблицу и поставить на нее ссылку, то будет еще лучше.Цветовая схема не очень, да, правится в конфиге.
Оно ровно такое же, как и везде - наглядность.
У меня RG35XX обычная с Garlic OS. Характеристики похуже (quad-core ARM Cortex-A9, 256мб ОЗУ DDR3 и т.д.). Тянет все до PS1 без особых нареканий.
У модели RG35XX H добавлены эмуляторы PSP/Dreamcast/N64, возможно NDS (точно не помню), и стоит Allwinner H700 (в целом, характеристики идентичны новой консоли). Насколько знаю, проблемы с играми на добавленных эмуляторах встречаются только на "тяжелых" играх. Но там хотя бы стики имеются, а тут этого нет.
Использовать "Теги", которые есть в Outlook - да не, бред. Уведомления о доставке и прочтении - так же бред.
Для начала, в случае игнора на первое письмо - использовать фишки почты, о которых написал выше. И использовать правильную нумерацию, ибо у вас один пункт пропущен:
Конкретика. В письме не должно быть воды. Вопросы должны быть простыми, понятными, без додумываний, двойных смыслов и т. п. «Подскажите по срокам» — это непонятно, т.к. можно подсказать «адекватные ли сроки», «уложимся ли мы в них», «будет ли готово день в день или раньше» и т. д. Конкретный вопрос — залог успеха. Простой конкретизированный вопрос - проще дать ответ сразу. Сложный вопрос с неопределенным смыслом - надо обдумать и потом как-нибудь отвечу.
По остальным пунктам уже критика:
Да
Бред. Почему именно 2 минуты? У меня может не быть сейчас 2х минут на болтовню с кем-либо. У меня может вообще не быть времени на разговоры с этими "эээээээм, амммммммм, хммм". Так же полностью нарушает первый пункт - на тему чего разговаривать то собралась? Видео с котиками обсудить? Может разговор затянется, т.к. к вашим вопросам необходимо подготовиться, подняв кипу документов или задач. В 99% случаях подобные запросы на "беседу" будут игнорироваться. Кроме того, устный ответ - это ответ без явного подтверждения, так что все равно будете повторно запрашивать ответ в письме, т.е. придется делать двойную работу и тратить заметно больше времени.
Это добавляет плюсов в пользу нежелания с вами общаться. Стандартные способы выделения - полужирный, курсив и подчеркивание - ничем не хуже, при этом вызывают меньше гнева и никак вообще не страдают от настроек почтового клиента или ОС.
Первый раз просто пишете письмо человеку, от которого нужен ответ. Второй раз пишете такое же письмо с тегами "важно, срочно и т.д.". В третий раз уже добавляете руководителей. Если сразу добавляете руководителя - идете нафиг, еще и руководитель подкинет пару крепких слов для ускорения движения в заданном направлении. Исключения - прям очень срочные письма, но такие встречаются крайне редко.
Есть ощущение, что вы не понимаете куда вообще надо писать и пишете случайному разработчику команды, которая ответственна за задачу. В первую очередь необходимо найти к кому непосредственно обращаться.
Дефолт
Никак не влияет.
Рабочее письмо - это не курсовая, нир или вкр, тут не нужно воды вообще. Максимально кратко и понятно описали что вам нужно - получили ответ. Налили воды - ваше письмо будет в числе последних, на которое будут тратить свое время.
Странно, я всегда считал это адекватным поведением - когда ты запрещаешь любую фоновую активность приложению и оно реально не работает в фоне, если не свернуто. А если свернул и зашел в список последних приложений, после нажатия кнопки закрытия - они все закрываются и перестают работать.
Сейчас на 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.
А из второго примера - если не получилось сделать интутивно понятный алгоритм выполнения какой-то операции, то ее необходимо задокументировать и каким-то образом гарантировать ознакомление пользователей.