А что именно вам здесь незнакомо с точки зрения синтаксиса? Пространства имён? Лямбды? Auto? Чтобы их читать, необязательно даже С++ знать. Код как код.
Первый сомнительный: в Грузии легчайший режим для мигрантов из России. Ему вы посвятили один абзац.
Второй аргумент: язык. Ему вы посвятили девять абзацев, потому то это ваша персональная фобия, у вас слишком большие ожидания от языка. В любой стране от вас требуется (а) поздороваться, попрощаться, сказать спасибо (б) обозначить, что вы иностранец (в) договориться о цене, времени, средстве оплаты, поздравить, улыбнуться. Всё что сверх этого вы всё равно не будете делать на своём уровне, допустим А2. Да это и не нужно. Для всего, что сверх этого, вам всё равно до поры до времени понадобится локальный нейтив, будь то редкий грузинский или популярный испанский. Даже если вы живёте в этой стране, зачем вам смотреть сериалы и петь песни на венгерском? Извините, на грузинском? Вы что, забыли русский и английский и не можете смотреть сериалы на них?
Речь не о том, что надо всё бросить и ехать в Кутаиси. А просто это не ограничение.
А в какие сроки вы оцениваете "изучение разработки умных контрактов", кои вы поленились осуществить, если год ожидания и "приличная цена" всё-таки не перекрывают их?
Я не специалист в разработке умных контрактов , но скорость обучения взрослого человека, способного к интеллектуальному труду, оценить могу. За год можно овладеть чрезвычайно сложной технологией, неужели умные контракты по сложности превышают пару семестров какого-нибудь условного матана?
Перечитал статью и не нашёл там объяснения про инверсию зависимостей (хотя есть его вполне валидная формулировка). Само по себе выделение интерфейса (например, абстрактного класса) это не инверсия. Инверсия возникает в тот момент, когда вы определяете, ГДЕ у вас определён интерфейс.
Вот у вас есть ваш интерфейс AbstractAuthUser. Если вы его определите в модуле, заведующем его конкретными реализациями, то у вас будет прямая зависимость: его клиенты, модули более высокого уровня, будут зависеть от модулей низкого уровня, содержащих детали. Это плохо!
Однако если вы определите AbstractAuthUser В МЕСТЕ ЕГО ИСПОЛЬЗОВАНИЯ, в модуле высокого уровня, то зависимости инвертируются: модули более низкого уровня будут вынуждены узнать о модуле высокого уровня (чтобы узнать про интерфейс, который они реализуют), но модуль высокого уровня будет независимым и самодостаточным.
Ура, ваши зависимости инвертированы! Вы можете разрабатывать модуль высокого уровня, вообще не зная, какие бывают конкретные реализации (и даже бывают ли они вообще). Зависимость была туда - стала сюда. Она инвертирована! И тут уже становятся важны опен-клоз, лисков и всё такое.
Вот этого объяснения, в чём именно заключается инверсия (в переносе интерфейса из модулей низкого уровня в модули высокого уровня и соответствующем развороте зависимостей), я в статье и не нашёл. А выделение абстрактного интерфейса, конечно, хорошая практика, но не составляет сущности этого принципа.
Поскольку прогнозируемое время выполнения исчислялось днями, а не минутами, можно предположить, что работодатель не подразумевал использование ИИ.
А если так, но офер был выставлен, то задание и методы его проверки не решают задачу отбора кандидатов. Это не проблема кандидата, разумеется. Просто плохо поставлен процесс.
Если вы уже всё равно взялись за ужасные решения, извращающие саму суть ооп, почему бы в тестах не сделать копию определения тестируемого класса без ключевого слова private (например, кодогенерацией) и в тестах просто не реинтерпретировать указатель/ссылку на объект к этому типу? И вот все поля доступны без магии, и исходный код не страдает
(за такое, конечно, увольняют, но за описанное в статье вообще расстреливают)
В вольфе нереалистичные проекции, так что вестибулярный аппарат сходит с ума и человека тошнит. Такова моя версия, как человека с точно такой же историей.
Вот когда потом это произойдет, тогда и отрефакторите.
Это так не работает. Рефакторинг это не только красивое слово, но и очень противное дело.
Когда вы захотите отрефакторить, вам понадобятся уже готовые тесты, чтобы убедиться, что нет деградации.
А когда вы захотите писать тесты, вам понадобятся интерфейсы для моков, чтобы количество тестов не росло экспоненциально
А интерфейсов вы не завезли, поэтому, собственно, и нужен рефакторинг. Собака съела свой хвост. Рефакторинг отменяется, всё переписываем с нуля, но, видимо, уже не вы.
Со всей любовью к Маску, это тоже форма рубки правды-матки, не так ли? Свобода слова всех касается, и правдорубов тоже.
Более того, эти перекосы всем на пользу. На критиков приходится реагировать, машины исправляются, меньше горят, все счастливы. Да здравствует матка и особенно правда.
Соотношение спроса и предложения не берётся из воздуха и вполне зависит от профессии.
В случае айти с определённого уровня предложение ограничивается сложностью профессии и таким образом не может расти быстрее, чем население планеты (с поправкой на проблемы образования). Спрос, спасибо прогрессу, растёт заведомо быстрее. Так что что чему чета в данном случае вполне уместная мерка.
У бьюти-блогеров, конечно, свои проблемы, но отреагировать на давление со стороны спроса значительно проще.
А что именно вам здесь незнакомо с точки зрения синтаксиса? Пространства имён? Лямбды? Auto? Чтобы их читать, необязательно даже С++ знать. Код как код.
То есть всё, что не укладывается в вашу теорию, вы просто называете другим словом, и сразу теория оказывается верной.
Ну ок)
Вы привели два аргумента.
Первый сомнительный: в Грузии легчайший режим для мигрантов из России. Ему вы посвятили один абзац.
Второй аргумент: язык. Ему вы посвятили девять абзацев, потому то это ваша персональная фобия, у вас слишком большие ожидания от языка.
В любой стране от вас требуется (а) поздороваться, попрощаться, сказать спасибо (б) обозначить, что вы иностранец (в) договориться о цене, времени, средстве оплаты, поздравить, улыбнуться. Всё что сверх этого вы всё равно не будете делать на своём уровне, допустим А2. Да это и не нужно. Для всего, что сверх этого, вам всё равно до поры до времени понадобится локальный нейтив, будь то редкий грузинский или популярный испанский.
Даже если вы живёте в этой стране, зачем вам смотреть сериалы и петь песни на венгерском? Извините, на грузинском? Вы что, забыли русский и английский и не можете смотреть сериалы на них?
Речь не о том, что надо всё бросить и ехать в Кутаиси. А просто это не ограничение.
А в какие сроки вы оцениваете "изучение разработки умных контрактов", кои вы поленились осуществить, если год ожидания и "приличная цена" всё-таки не перекрывают их?
Я не специалист в разработке умных контрактов , но скорость обучения взрослого человека, способного к интеллектуальному труду, оценить могу. За год можно овладеть чрезвычайно сложной технологией, неужели умные контракты по сложности превышают пару семестров какого-нибудь условного матана?
N-цать успешных шагов к успешному успеху в успешной карьере!
Успешная Бизнес-молодость, торгующая успешным успехом
Успешные статьи, успешные контакты, успешные переговоры
Успешная диета
Всё это классно, но причём здесь программирование, заявленное в заголовке?
проекты разные, и нет единого понимания атомарности, и поэтому нет лучшего или худшего подхода
Размер проекта
Скорость разработки
Сложность изменений
Количество разработчиков и команд
Распределение ответственности между ними
Особенности тестирования
И прочее
Перечитал статью и не нашёл там объяснения про инверсию зависимостей (хотя есть его вполне валидная формулировка). Само по себе выделение интерфейса (например, абстрактного класса) это не инверсия. Инверсия возникает в тот момент, когда вы определяете, ГДЕ у вас определён интерфейс.
Вот у вас есть ваш интерфейс AbstractAuthUser. Если вы его определите в модуле, заведующем его конкретными реализациями, то у вас будет прямая зависимость: его клиенты, модули более высокого уровня, будут зависеть от модулей низкого уровня, содержащих детали. Это плохо!
Однако если вы определите AbstractAuthUser В МЕСТЕ ЕГО ИСПОЛЬЗОВАНИЯ, в модуле высокого уровня, то зависимости инвертируются: модули более низкого уровня будут вынуждены узнать о модуле высокого уровня (чтобы узнать про интерфейс, который они реализуют), но модуль высокого уровня будет независимым и самодостаточным.
Ура, ваши зависимости инвертированы! Вы можете разрабатывать модуль высокого уровня, вообще не зная, какие бывают конкретные реализации (и даже бывают ли они вообще). Зависимость была туда - стала сюда. Она инвертирована! И тут уже становятся важны опен-клоз, лисков и всё такое.
Вот этого объяснения, в чём именно заключается инверсия (в переносе интерфейса из модулей низкого уровня в модули высокого уровня и соответствующем развороте зависимостей), я в статье и не нашёл. А выделение абстрактного интерфейса, конечно, хорошая практика, но не составляет сущности этого принципа.
Удивительно, как можно при объяснении принципа инверсии зависимостей ни полсловом не упомянуть ни зависимости, ни инверсию
Сказать про модули верхнего и нижнего уровня и не придумать примера с абстракциями разного уровня (и их зависимостями)
Какая зависимость инвертируется в итоге? Между чем и чем? Кто верхнего уровня, кто нижнего, какую проблему решили? Да бог его знает
"Программисту не надо знать алгоритмы, можно открыть Эксель и посчитать"
Эмм, а Эксель кто пишет, не программисты?
Можно ещё написать статью: инженерам автомобильной промышленности не надо изобретать автомобили: можно вызвать такси и поехать.
Поскольку прогнозируемое время выполнения исчислялось днями, а не минутами, можно предположить, что работодатель не подразумевал использование ИИ.
А если так, но офер был выставлен, то задание и методы его проверки не решают задачу отбора кандидатов. Это не проблема кандидата, разумеется. Просто плохо поставлен процесс.
Прекратилась или завершилась?
Define private public тоже ужасно, но оно ещё и аффектит тестируемый код.
Где нет правильных шашечек, со временем перестаёт ехать. Потому что это не просто так шашечки.
Если менеджмент за программистов выбирает инженерные решения, то зачем нужны программисты?
Если вы уже всё равно взялись за ужасные решения, извращающие саму суть ооп, почему бы в тестах не сделать копию определения тестируемого класса без ключевого слова private (например, кодогенерацией) и в тестах просто не реинтерпретировать указатель/ссылку на объект к этому типу? И вот все поля доступны без магии, и исходный код не страдает
(за такое, конечно, увольняют, но за описанное в статье вообще расстреливают)
Примером кода из стандартной библиотеки автор опровергает собственные слова про говорящие имена переменных и даже не замечает этого.
Ну замените __alloc_traits::construct на какое-нибудь неговорящее at::crt. Что, неужели не стало менее понятно? Не повлияла читаемость на понимание?
Саттер уже пилит cpp2.
В вольфе нереалистичные проекции, так что вестибулярный аппарат сходит с ума и человека тошнит. Такова моя версия, как человека с точно такой же историей.
Это так не работает. Рефакторинг это не только красивое слово, но и очень противное дело.
Когда вы захотите отрефакторить, вам понадобятся уже готовые тесты, чтобы убедиться, что нет деградации.
А когда вы захотите писать тесты, вам понадобятся интерфейсы для моков, чтобы количество тестов не росло экспоненциально
А интерфейсов вы не завезли, поэтому, собственно, и нужен рефакторинг. Собака съела свой хвост. Рефакторинг отменяется, всё переписываем с нуля, но, видимо, уже не вы.
Из России могут туда на заработки гонять, получается
Со всей любовью к Маску, это тоже форма рубки правды-матки, не так ли? Свобода слова всех касается, и правдорубов тоже.
Более того, эти перекосы всем на пользу. На критиков приходится реагировать, машины исправляются, меньше горят, все счастливы. Да здравствует матка и особенно правда.
Соотношение спроса и предложения не берётся из воздуха и вполне зависит от профессии.
В случае айти с определённого уровня предложение ограничивается сложностью профессии и таким образом не может расти быстрее, чем население планеты (с поправкой на проблемы образования). Спрос, спасибо прогрессу, растёт заведомо быстрее. Так что что чему чета в данном случае вполне уместная мерка.
У бьюти-блогеров, конечно, свои проблемы, но отреагировать на давление со стороны спроса значительно проще.