Группировка Java/Scala, конечно, корявая. Логичнее говорить, о разработчиках энтерпрайзовых бэкендов на JVM. Это Java, Koltin, Scala именно в таком порядке популярности. При этом Java/Kotlin это еще и Андроид.
Согласитесь, что всё хреначить в контроллере получается быстрее
Не соглашусь. Как я уже писал выше, когда ты в течение карьеры написал уже штук 500 этих рест-контроллеров (если вы о них), то на автомате пишешь как надо. Если видел данный архитектурный паттерн множество раз, то заложить точки расширения - вообще не рокет-саенс ни разу.
По-моему дело в том, что многие разработчики оказались "скрытыми" девопсерами. Я знаю много девелоперов на позициях сеньор или техлид, которых просто прет от всей это контейнерно-деплойной темы, а от кода не прет вот вообще никак. В итоге ни там ни там на полную катушку не работают.
При нехватке ресурсов (то есть почти всегда) часто возникает вопрос, как решать в данный момент возникшую проблему, быстро или качественно
Формально вы правы, но после 10 лет в отрасли я не представляю ситуацию, когда я скажу "ок, времени нет, давайте напишем тут спагетти-функцию на 2к строк без всякой структуры и с всратным неймингом". Все эти DRY, KISS, YAGNI, GRASP, SOLID после какого-то порога опыта уже на кончиках пальцев. Сразу пишешь программу как набор элементарных блоков. Изменяются требования - пересобираешь блоки. Косямба на проде - по одному мессаджу уже понимаешь, в каком блоке проблема, 9 из 10 багфиксов готовятся за час максимум. Да, есть проблемы, когда заказчику утром нужно одно, а вечером другое - но опять же, рефлекс подстилания соломки уже сам собой срабатывает. В конце концов, если тебя наняли сеньором-помидором, то надо уровень показывать и перед самим собой и перед теми, кто после тебя будет твой код поддерживать. Для сеньора компромиссное решение наговнокодить должно быть исключительно редким и обоснованным.
Моя “любимая” история — постановка задач методом развести тред на 150 сообщений в чате. Или в личке
Это не так уж и плохо. Альтернатива - это когда заказчик ставит вас перед фактом, что священные скрижали ТЗ у него уже есть, и, кроме того, они уже подписаны и одобрены всем "уполномоченными органами". А вы, мартышки, теперь танцуйте с этим как хотите.
После обсуждения в чате всегда можно подбить и зафиксировать резюме для будущей самообороны.
Потому что написание плохого кода по-быстрому в начальном этапе обходится дешевле
Давайте уточним. Не написание плохого кода, а найм говнокодеров. Нет такого принципиального закона природы, согласно которому писать говнокод быстрее, чем писать по-человечески. Профессионал пишет чисто и быстро даже в условиях недостатка информации - на то он и профессионал. А вот нанять вместо профессионала черт знает кого - это у стартаперов всегда пожалуйста.
Информация с камеры будет обрабатываться алгоритмом для анализа выражения лица, который определит, какие эмоции испытывает пассажир. Если алгоритм выявит страх или дискомфорт...
Ну как сказать. Иногда как раз игры или фильмы делают некий период истории или некую культуру интересной. Как говорится, никто не сделал для популярности немецкого языка в РФ больше, чем Rammstein.
loadCLass у класслоадера таки возвращает класс, построенный из байткода.
Так-то оно так, но если у меня спросят "как создаются классы", то я сначала отвечу "руками пишутся". Потом возможно вспомню про какое-нибудь метапрограммирование.
Требование консистентности (Consistency) является вторым к транзакционным системам и логически вытекает из требования атомарности, т.е. каждая выполненная транзакция фиксирует только допустимые результаты
На самом деле вы тут повторяете принцип атомарности, только другими словами. Потому вам и кажется, что вытекает. СУБД вкладывает в понятие допустимости совсем не то, что можете вкладывать вы, как владелец продукта или разработчик.
Да, значению банковского счета нельзя присвоить отрицательное число, если так указано в схеме. А вот сделать что-то вроде update account set money_amount = 0 where 1=1 джвижок СУБД вам не запретит, несмотря ни на какой ACID. Потому есть мнение, что буква C была добавлена в акроним "чтобы красивее было". А в действительности задача поддержания согласованности лежит на бизнес-логике приложения, а не на СУБД.
спрашивать на собеседованиях и преподавать в ВУЗах
Мне так никто и не может объяснить, что в этом плохого.
Допустим, есть задача, когда один источник отправляет данные нескольким получателям. Число получателей растет и иногда даже в рантайме. Стандартное ее решение это паттерн паб-саб. Костыльно-велосипедное решение это при появлении новых получателей снова и снова дописывать строки кода в какой-то бесконечный метод, который по очереди вызывает получателей. Вопрос: что криминального, если я хочу на собесе услышать суть данного паттерна и его применение в реальных условиях?
Оказалось, что положительно влияя на одни характеристики, паттерны оказывают негативное влияние на другие составляющие качества кода.
"Оказалось"... Чтобы сделать такой вывод, исследование не нужно. Топор тоже гораздо проще бензопилы в устройстве и обслуживании. А полуторка АМО проще, чем современный дизельный тягач. А отвар из ивовой коры проще, чем синтез и производство аспирина.
Давайте что ли напишем статью "есть ли польза от бензопил на лесоповале"? Не, таких статей мы почему-то не пишем. Всем как-то интуитивно понятно, что чем больше плюшек приносит технология, тем она замороченнее. Тем более парадоксально, что когда программистам предлагают писать более замороченный, но более надежный код (кстати, писать по готовым рецептам), то сразу поднимается дискуссия "а надо ли", "а не слишком ли сложно", "мой брат писал по паттернам и заболел".
но разум разработчика нужен, чтобы доработать и проверить код
В общем вы сознательно внедряете в свой рабочий процесс то, что из любого процесса обычно всеми силами стараются убрать: доработки за других и многократные проверки.
Группировка Java/Scala, конечно, корявая. Логичнее говорить, о разработчиках энтерпрайзовых бэкендов на JVM. Это Java, Koltin, Scala именно в таком порядке популярности. При этом Java/Kotlin это еще и Андроид.
Зато как раз после такого опыта и начинаешь задавать правильные вопросы на собесах. В смысле, когда ты в качестве кандидата.
Мальчик: восторженно вопрошает как у вас на проекте докеры кубернесятся и реактивщина асинхронится
Мужчина: аккуратно прощупывает на предмет галиматьи вроде микроменеджмента, "дежурств", созвонов, пипец-дривен девелопмента, джуновых команд и пр.
Сперва подумал про Синглтон Ужаса, Фабрику Кошмаров и Прокси В Ад.
Не понял, зачем ее броадкастить постоянно. Я думал такие вещи или вшиты в прошивку или загружаются типа раз в день.
Ну почему же. Мне вот в последний заход HR обещал всего 2 алгоритмические секции.
И эцилопп меня не имеет права бить по ночамРаньше 3 было.Если рутина разработчика не закрывается такими приемами, как создание библиотеки или кодогенерация, то я не знаю, что у них там за рутина.
Не соглашусь. Как я уже писал выше, когда ты в течение карьеры написал уже штук 500 этих рест-контроллеров (если вы о них), то на автомате пишешь как надо. Если видел данный архитектурный паттерн множество раз, то заложить точки расширения - вообще не рокет-саенс ни разу.
По-моему дело в том, что многие разработчики оказались "скрытыми" девопсерами. Я знаю много девелоперов на позициях сеньор или техлид, которых просто прет от всей это контейнерно-деплойной темы, а от кода не прет вот вообще никак. В итоге ни там ни там на полную катушку не работают.
Формально вы правы, но после 10 лет в отрасли я не представляю ситуацию, когда я скажу "ок, времени нет, давайте напишем тут спагетти-функцию на 2к строк без всякой структуры и с всратным неймингом". Все эти DRY, KISS, YAGNI, GRASP, SOLID после какого-то порога опыта уже на кончиках пальцев. Сразу пишешь программу как набор элементарных блоков. Изменяются требования - пересобираешь блоки. Косямба на проде - по одному мессаджу уже понимаешь, в каком блоке проблема, 9 из 10 багфиксов готовятся за час максимум. Да, есть проблемы, когда заказчику утром нужно одно, а вечером другое - но опять же, рефлекс подстилания соломки уже сам собой срабатывает. В конце концов, если тебя наняли сеньором-помидором, то надо уровень показывать и перед самим собой и перед теми, кто после тебя будет твой код поддерживать. Для сеньора компромиссное решение наговнокодить должно быть исключительно редким и обоснованным.
Это не так уж и плохо. Альтернатива - это когда заказчик ставит вас перед фактом, что священные скрижали ТЗ у него уже есть, и, кроме того, они уже подписаны и одобрены всем "уполномоченными органами". А вы, мартышки, теперь танцуйте с этим как хотите.
После обсуждения в чате всегда можно подбить и зафиксировать резюме для будущей самообороны.
Давайте уточним. Не написание плохого кода, а найм говнокодеров. Нет такого принципиального закона природы, согласно которому писать говнокод быстрее, чем писать по-человечески. Профессионал пишет чисто и быстро даже в условиях недостатка информации - на то он и профессионал. А вот нанять вместо профессионала черт знает кого - это у стартаперов всегда пожалуйста.
Гарольд, давай лучше поездом?
Ну как сказать. Иногда как раз игры или фильмы делают некий период истории или некую культуру интересной. Как говорится, никто не сделал для популярности немецкого языка в РФ больше, чем Rammstein.
Так-то оно так, но если у меня спросят "как создаются классы", то я сначала отвечу "руками пишутся". Потом возможно вспомню про какое-нибудь метапрограммирование.
Поскольку я по JVM, то попробую ответить
SAGA, двухфазный коммит, reactor. Кстати, при чем здесь джава?
При чем тут джава опять же?
Можно недостроить объект. Конструктор в положительном сценарии точно достроит.
Предполагаю, как-то в кишках JVM. Откуда джуну это знать?
Без поллитры не разберешься. Речь про класслоадер что ли? Что вообще такое "создание класса"?
Ну пусть говорит. У нас не ЕГЭ и не тестирование. Вопрос открытый, все ответы принимаются.
На самом деле вы тут повторяете принцип атомарности, только другими словами. Потому вам и кажется, что вытекает. СУБД вкладывает в понятие допустимости совсем не то, что можете вкладывать вы, как владелец продукта или разработчик.
Да, значению банковского счета нельзя присвоить отрицательное число, если так указано в схеме. А вот сделать что-то вроде
update account set money_amount = 0 where 1=1джвижок СУБД вам не запретит, несмотря ни на какой ACID. Потому есть мнение, что буква C была добавлена в акроним "чтобы красивее было". А в действительности задача поддержания согласованности лежит на бизнес-логике приложения, а не на СУБД.Мне так никто и не может объяснить, что в этом плохого.
Допустим, есть задача, когда один источник отправляет данные нескольким получателям. Число получателей растет и иногда даже в рантайме. Стандартное ее решение это паттерн паб-саб. Костыльно-велосипедное решение это при появлении новых получателей снова и снова дописывать строки кода в какой-то бесконечный метод, который по очереди вызывает получателей. Вопрос: что криминального, если я хочу на собесе услышать суть данного паттерна и его применение в реальных условиях?
"Оказалось"... Чтобы сделать такой вывод, исследование не нужно. Топор тоже гораздо проще бензопилы в устройстве и обслуживании. А полуторка АМО проще, чем современный дизельный тягач. А отвар из ивовой коры проще, чем синтез и производство аспирина.
Давайте что ли напишем статью "есть ли польза от бензопил на лесоповале"? Не, таких статей мы почему-то не пишем. Всем как-то интуитивно понятно, что чем больше плюшек приносит технология, тем она замороченнее. Тем более парадоксально, что когда программистам предлагают писать более замороченный, но более надежный код (кстати, писать по готовым рецептам), то сразу поднимается дискуссия "а надо ли", "а не слишком ли сложно", "мой брат писал по паттернам и заболел".
В общем вы сознательно внедряете в свой рабочий процесс то, что из любого процесса обычно всеми силами стараются убрать: доработки за других и многократные проверки.