Забавно, что ни один из примеров в статье не относится конкретно к Java. Разве что пример с кешем, хотя не уверен, что больше нет ЯП имеющих подобный кеш и аналог рефлексии.
Человек, который любит заниматься электроникой и программированием собственных устройств всегда ищет идеи, которые интересно было бы воплотить в жизнь. По себе знаю.
Иногда у этой идеи есть готовая альтернатива или аналог, но все же хочется создать это самому.
Иногда идея уникальна, но на самом деле полезна она только для автора и вероятно, небольшой группы людей.
И очень редко идея полезна широкому кругу людей и при этом коммерчески выгодна. Некоторые из таких со временем превращаются в бизнес.
Поэтому вопрос к DIY проектам типа "зачем" так часто возникает :)
Я не встречал, чтобы на собеседовании просили повторить реализацию паттерна. Но перечислить их и описать, какой для чего нужен, мне кажется, вполне нормально. Дело в том, что чтобы распознать ситуацию, когда можно применить какой-то паттерн, их в любом случае нужно помнить, хотя бы условно.
Я немного о другом. Довольно часто требуется создать механизм, задачи которого выходят за рамки классических паттернов. Иногда можно собрать его из 4+ паттернов, но результат получается сложным и запутанным. Вот как раз в таких ситуациях эффективнее спроектировать уникальный механизм под конкретную задачу. И сами идеи, которые стоят за паттернами, помогли мне создавать такие механизмы, которые обладают нужными свойствами.
Самое ценное в книгах дядюшки Боба – это ход его мыслей. Да, безусловно, неокрепший разум сразу пытается следовать его идеям точь в точь. Но это не проблема книги или автора.
Лично начал знакомиться с его книгами на третьем году коммерческого опыта разработки. И для меня стало открытием то, как автор рассуждает о каждой строке кода.
Если до этого я писал код, чтобы он работал (ну и выглядел симпатично), то после я начал прорабатывать множество вариантов реализации в попытках достичь определённых свойств написанного кода.
И вот, спустя 6 лет я могу детально объяснить почему конкретную строку или выражение написал именно так. Да, я не следую его рекомендациям. Я даже смутно помню их. Но способ мыслить оказался бесценен.
P. S. То же самое с паттернами проектирования. Знакомство с ними объяснило саму суть ООП и для чего все это нужно. Я вряд ли смогу по памяти повторить один в один какой-либо паттерн, кроме простейших. Но я понимаю идеи, которые за ними стоят. И реализую решения, которые нужны для конкретной ситуации со всеми её нюансами.
Зачастую, весь процесс от запроса до размещения креатива на сайте должен занимать не более 150 мс, т.е. то время за которое у пользователя с хорошим интернетом загружается web-страница. Чтобы отвечать этому требованию бэк платформ, как правило, пишется на языках под JVM (встречал на своей практике на Java, Scala) или еще на Rust.
Звучит, мягко говоря, странно. Поставить Java и Rust в одну категорию? Если Java справляется за 150 мс, то, скорее всего, за это время справится любой ЯП, кроме Python.
Поэтому лучше было написать так:
Поэтому Python здесь не подходит.
А вообще, то, что JVM часто используется скорее всего не связано с 150 мс. Вывод притянутый за уши.
Это в РФ Java так сильно распространена. В Украине большинство более менее новых проектов на C#. Java в основном там, где так исторически сложилось. Более того, многие работают на забугорные компании, и в основном они на C#.
Не стану утверждать, что проводил глубокий анализ, мои утверждения основываются на кругу знакомых программистов и сайтов поиска работы.
Боже упаси оказаться в одной команде с автором данной статьи. Или же работать с его наследием.
Забавно, что ни один из примеров в статье не относится конкретно к Java. Разве что пример с кешем, хотя не уверен, что больше нет ЯП имеющих подобный кеш и аналог рефлексии.
Человек, который любит заниматься электроникой и программированием собственных устройств всегда ищет идеи, которые интересно было бы воплотить в жизнь. По себе знаю.
Иногда у этой идеи есть готовая альтернатива или аналог, но все же хочется создать это самому.
Иногда идея уникальна, но на самом деле полезна она только для автора и вероятно, небольшой группы людей.
И очень редко идея полезна широкому кругу людей и при этом коммерчески выгодна. Некоторые из таких со временем превращаются в бизнес.
Поэтому вопрос к DIY проектам типа "зачем" так часто возникает :)
Очень интересно, но нибуя не понятно.
Я не встречал, чтобы на собеседовании просили повторить реализацию паттерна. Но перечислить их и описать, какой для чего нужен, мне кажется, вполне нормально. Дело в том, что чтобы распознать ситуацию, когда можно применить какой-то паттерн, их в любом случае нужно помнить, хотя бы условно.
Я немного о другом. Довольно часто требуется создать механизм, задачи которого выходят за рамки классических паттернов. Иногда можно собрать его из 4+ паттернов, но результат получается сложным и запутанным. Вот как раз в таких ситуациях эффективнее спроектировать уникальный механизм под конкретную задачу. И сами идеи, которые стоят за паттернами, помогли мне создавать такие механизмы, которые обладают нужными свойствами.
Самое ценное в книгах дядюшки Боба – это ход его мыслей. Да, безусловно, неокрепший разум сразу пытается следовать его идеям точь в точь. Но это не проблема книги или автора.
Лично начал знакомиться с его книгами на третьем году коммерческого опыта разработки. И для меня стало открытием то, как автор рассуждает о каждой строке кода.
Если до этого я писал код, чтобы он работал (ну и выглядел симпатично), то после я начал прорабатывать множество вариантов реализации в попытках достичь определённых свойств написанного кода.
И вот, спустя 6 лет я могу детально объяснить почему конкретную строку или выражение написал именно так. Да, я не следую его рекомендациям. Я даже смутно помню их. Но способ мыслить оказался бесценен.
P. S. То же самое с паттернами проектирования. Знакомство с ними объяснило саму суть ООП и для чего все это нужно. Я вряд ли смогу по памяти повторить один в один какой-либо паттерн, кроме простейших. Но я понимаю идеи, которые за ними стоят. И реализую решения, которые нужны для конкретной ситуации со всеми её нюансами.
Не знаю сколько времени займёт сбор команды QT разработчиков. Но, как десктоп разработчик скажу следующее.
Сейчас 99% вакансий – веб. И лишь 1% десктоп. И, вероятно, во многом, это заслуга таких фреймворков как Electron.
И это прискорбно.
Зачастую, весь процесс от запроса до размещения креатива на сайте должен занимать не более 150 мс, т.е. то время за которое у пользователя с хорошим интернетом загружается web-страница. Чтобы отвечать этому требованию бэк платформ, как правило, пишется на языках под JVM (встречал на своей практике на Java, Scala) или еще на Rust.Звучит, мягко говоря, странно. Поставить Java и Rust в одну категорию? Если Java справляется за 150 мс, то, скорее всего, за это время справится любой ЯП, кроме Python.
Поэтому лучше было написать так:
Поэтому Python здесь не подходит.А вообще, то, что JVM часто используется скорее всего не связано с 150 мс. Вывод притянутый за уши.
Это в РФ Java так сильно распространена. В Украине большинство более менее новых проектов на C#. Java в основном там, где так исторически сложилось. Более того, многие работают на забугорные компании, и в основном они на C#.
Не стану утверждать, что проводил глубокий анализ, мои утверждения основываются на кругу знакомых программистов и сайтов поиска работы.
У нас на заводе весь легаси на VB. Часть даже на VB6... Поэтому многие доработки старого функционала дописываются на нём же.
Количество просмотров зависит в первую очередь от популярности вещающего, и в немного меньшей степени от темы.
Так и не понял, за что заминусовали статью. Как по мне, написаны здравые мысли, материал полезен всем, кто ищет работу.
Понять философию HR - поднять % офферов, всё просто. И нравится тебе это или нет, но есть как есть.
Спасибо за материал, сделал для себя некоторые выводы.