Был кейс. Выкатили релиз на прод 5 микросервисов, один с межсервисным запросом на старте. Запрос упал из-за некоторых невалидных элементов, тупо не получали ответ. Какие-то элементы невалидны непонятно какие. Разраб попробовал хотфикс, вытягивая по одному элементу и игноря упавшие. На этот раз упало по времени - деплой имеет ограничение по времени. Клиент нервничает, висит угроза отката всех микросервисов. Это репутационная потеря и штрафы, времени нет. Пришлось влезть. Решилось алгоритмом на дихотомии. Это легло в основу практического задания на собеседование. Никто за полтора года не решил, но интересно наблюдать за вариантами решений - хватаются за батч запросы, кеширование, многопоточку. Причем, времени у кандидатов больше, чем было в реальности, а давления меньше. Но на курсах этому не учили.
В другой раз был релиз, где мне пришлось писать генетический алгоритм для решения NP задачи. И это обычный Enterprise проект. Компетенции решать такие задачи не было ни у кого, потому что это далеко от перегона json. Не раз за карьеру приходилось решать NP задачи. На гитаре от удивлённых коллег узнал, что они тоже сталкивались, но просто даже не знали, что это за класс задач до митапа и не решили.
ЗЫ. По сей день разгребаю оптимизации за антиалгоритмистами, которые в попытке продемонстрировать знание фреймворков не спешат оттачивать когнитивные способности.
Инвестор платит за результат. Если риски не описаны для него, то это очень безответственно. Об этом в том числе писал дядя Боб долго и нудно, подчёркивая что в ином случае это не профессионал. Действительно, это так безответственно и непрофессионально вводить в заблуждение или не сообщить о рисках и цене рисков для инвестора, который тратит огромные деньги. Это похоже на неопытность и неспособность просчитать риски. Именно просчитать, а не просто нудеть, что это нехорошо. Что значит просчитать ? Сообщить, что стоимость фичи через год будет стоить в ~3 раза дороже, что поддержка кода в течение 3 месяцев станет равна стоимости разработки с нуля. В цифрах, в деньгах. Если это сложно посчитать, скорее всего нет опыта.
Техдолг бывает разный, но неправильная архитектура, несоблюдение паттернов - это не про тех долг, это отсутствие опыта. Для сеньора с опытом это все не требует значительных затрат времени, он попросту не умеет по другому уже.
Ну вот опять, "алгоритмы не нужны". Сколько бы раз до оптимизации не доходило ещё никто на могу памяти за 15 лет так и не смог применить алгоритм. Дайбох, понимают когда какую структуру данных применить - и то, в большинстве случаев просто динамический массив там где можно мап для быстрого доступа. Чтобы поменять алгоритмы надо уметь идентифицировать задачу, свести ее к модифицированной известной задаче. В бизнес проблемах никто не ставит задачу типа "дан двудольный граф", нужно уметь ИДЕНТИФИЦИРОВАТЬ задачу, а без опыта, навыков, фундамента это невозможно. У этих товарищей всегда "алгоритмы не нужны", потому что они даже не видят эти моменты когда нужно включиться в алгоритмику. Каждый раз, когда возникает проблема с производительностью, они начинают искать способы, гуглят, применяют ИИ чтобы найти новый фреймворк, натягивают кэширование, гуглят многоточку или тупо увеличивают тайм-аут. Они видят проблему в таймауте, в нехватке памяти и решают проблему с инфраструктурой а не бизнес логикой через алгоритмы. И это чаще чем вы думаете, проблема в том, что неправильно идентифицируют проблему!
Снова уже знакомый автор со знакомым почерком... Сначала объявил войну самой логике, выкатив статью о том, что алгоритмы не нужны. А теперь против ООП, причем так и не смог самостоятельно привести примеры для аргументации, а просто привёл утрированные примеры. Вероятно побоялся привести реальные примеры, в которых его вкусовщина выдала бы в нем некомпетентность. Против алгоритмов, против ООП - зачем полез в университет? Стыдно за таких коллег. Основная проблема таких борцунов и проливателей света в том, что они абсолютно не владеют темой, против которого борятся.
Создаётся впечатление по статьям, что в России есть силы, которые хотят уничтожить некогда сильную индустрию через ложные постулаты и борьбу с искусством программирования. Новое поколение разработчиков не способно уже конкурировать с индусами. Примерная история у всех: вайти курсы, проскочить собесы вызубрив ненавистные паттерны и алгоритмы, никогда не применять паттерны и алгоритмы(потому что не поняли вызубренное) и кричать на каждом углу "они не нужны". Мало того ,что вайтишник за эти годы доросли до сеньоров и тимлидов по выслугу лет, так теперь ещё и до вузов добрались...
Это те же люди, которые гневно реагируют на элементарные, казалось бы, вещи типа тернарный оператор "а как же kiss! ? : это непонятно читается!" А там буквально 10 символов. То есть тупо простые конструкции не знают, не говоря об ООП, паттернах и т.д. Но всегда чинно парируют "а как же kiss?"
Все верно. Комментарии выше показывают их слабую компетенцию, вероятно джуны. Все эти знания важны, проблема именно в том, что олдскулл разработчики не знают названия своим навыкам, паттернам, которые применяют. А вайтишник наоборот, знают все названия паттернов, даже определения и даже (!) примеры могут привести. Однако, по комментариям выше видно, что не понимают смысл выученных слов совсем и считают, что никогда не пригодилось.
Но есть одно НО. Даже став победителем конкурса Старт, это не гарантирует, что получите деньги от этой структуры)) Уже на подписании контракта просто кинули нас студентов, которые открыли ООО для подписания. Влетели в копеечку. Сотрудники фонда бортника предложили нам формальное участие в следующем конкурсе год спустя и они нам отдадут победу, чтобы мы всё-таки забрали свой выигрыш.
Но, естественно, они обманули снова - на этот раз апеллировали к тому что мы подали второй раз тот же проект (а какой ещё подавать? Они же нам должны за этот проект, а не новый). Попросили нас на третий год подать, но с другим названием проекта, чтобы якобы не было повтора. Естественно, обманули снова)) 3-4 года мурыжили, не отдавая выигрыш. А у нас были уже договора с компаниями, заинтересованными в продукте. Все кончилось благодаря не вороватой и честной организации.
Столько времени, сил, нервов и денег впустую. Так что просьба не насмехаться высокомерно над командами, которые резонно считают, что эта организация полна договорняков.
Все зависит от позиции. Если Джун Data Scientist то 150 легко на старте. Если речь о html специалисте Джун или QA Джуниор, то на старте меньше конечно, в среднем. Наша компания в регионе, java junior без+ попадает в эту вилку. Так что зря ерничаете.
Тема разжевана на Хабре многократно за последние лет 15-20.
К чему очередная статья и довольно скупая? Возможно, нашлось новое применение? Нет, снова и снова задача коммивояжера. Возможно, новые результаты на бенчмарках? Нет, снова пустой звук без результатов.
В реализации и в целом в статье грубейшая ошибка, которая лишает всякого смысла генетический алгоритм - отсутствует оператор отбора/редукции. Отбор - основная движущая сила эволюции. Не путать с селекцией. В итоге получаем абсолютно хаотичный алгоритм, который никуда не движется.
С точки зрения Java также все очень грустно. Хромосома/особь не выделен в отдельную структуру/класс/сущность. Использование коллекций сожрал эффективность. Постоянная реаллокация одинаковых по смыслу коллекций на каждой итерации убьет сборщик мусора. Но на таких микрозадачах это не заметно.
Кажется, пост не понят. Автор рассказывает, что интернет и монопольные сервисы сейчас обслуживают интересы крупного бизнеса, а не пользователей. Движущая сила эволюции - корпорации, а не наши с вами. Эволюция произошла для бизнеса, а поиск для пользователей стал дерьмом собачьим. То, что я мог легко найти в нулевые, сейчас либо невозможно либо нужно приложить нереальные усилия, даже пользуясь повсюду запрещённым в угоду медиамагнатам торрентом. И если вдруг нашелся опальный сайтик, мне нужно кучу рекламы просмотреть, отклонить уведомления, подписки и т.д. Это все потребности бизнеса, это все инструменты монетизации бизнеса. Вот о чем пост - эволюция произошла, но в сфере маркетинга и защиты бизнеса.
Кажется, восприятие позиции тимлида просто чересчур романтизировано. Описанные проблемы имеют место быть, но я воспринимаю их как конъюнктурные вводные условия задачи. Если конъюнктура не устраивает, значит не поняли свою позицию и задачу.
Очевидно, раз сравнение идёт с молодыми, имеется в виду найм джунов. 100% преимущество у молодых. 40-50 летние вайтишники - это боль. Я видел, как 20 летние грузчики и другие люди из разных профессий успешно вошли в IT. Видел как 40-летний вайтишник проскочил собес на джуна, но не осилил далее. Сложно в большом возрасте переформатировать мышление, получить новые навыки в совершенно другой сфере.
Но 40-летний сеньор имеет колоссальное преимущество перед 25-летним сеньором. Бэкграунд у них, как правило, несопоставим.
В найме склоняюсь использовать возрастной ценз для различных грейдов. Чем выше грейд, тем выше возрастной потолок.
Используем codestyle от intellij с форматированием на основе ОБЩЕПРИНЯТОГО google style. А в качестве плагина для проверки билда для CI - checkstyle. Codestyle с проектом в git.
Не понимаю, разговоров об отсутствии конвенции. Есть два варианта: олдскульный oracle java code style convention и google java code style convention.
Был кейс. Выкатили релиз на прод 5 микросервисов, один с межсервисным запросом на старте. Запрос упал из-за некоторых невалидных элементов, тупо не получали ответ. Какие-то элементы невалидны непонятно какие. Разраб попробовал хотфикс, вытягивая по одному элементу и игноря упавшие. На этот раз упало по времени - деплой имеет ограничение по времени. Клиент нервничает, висит угроза отката всех микросервисов. Это репутационная потеря и штрафы, времени нет. Пришлось влезть. Решилось алгоритмом на дихотомии. Это легло в основу практического задания на собеседование. Никто за полтора года не решил, но интересно наблюдать за вариантами решений - хватаются за батч запросы, кеширование, многопоточку. Причем, времени у кандидатов больше, чем было в реальности, а давления меньше. Но на курсах этому не учили.
В другой раз был релиз, где мне пришлось писать генетический алгоритм для решения NP задачи. И это обычный Enterprise проект. Компетенции решать такие задачи не было ни у кого, потому что это далеко от перегона json. Не раз за карьеру приходилось решать NP задачи. На гитаре от удивлённых коллег узнал, что они тоже сталкивались, но просто даже не знали, что это за класс задач до митапа и не решили.
ЗЫ. По сей день разгребаю оптимизации за антиалгоритмистами, которые в попытке продемонстрировать знание фреймворков не спешат оттачивать когнитивные способности.
Все, можете минусовать)
Люто плюсую
А что не так с сервисной (не микро) архитектурой? SOA. Почему промежуточные решения выпиливаются сразу или игнорируются их существование?
Инвестор платит за результат. Если риски не описаны для него, то это очень безответственно. Об этом в том числе писал дядя Боб долго и нудно, подчёркивая что в ином случае это не профессионал. Действительно, это так безответственно и непрофессионально вводить в заблуждение или не сообщить о рисках и цене рисков для инвестора, который тратит огромные деньги. Это похоже на неопытность и неспособность просчитать риски. Именно просчитать, а не просто нудеть, что это нехорошо. Что значит просчитать ? Сообщить, что стоимость фичи через год будет стоить в ~3 раза дороже, что поддержка кода в течение 3 месяцев станет равна стоимости разработки с нуля. В цифрах, в деньгах. Если это сложно посчитать, скорее всего нет опыта.
Техдолг бывает разный, но неправильная архитектура, несоблюдение паттернов - это не про тех долг, это отсутствие опыта. Для сеньора с опытом это все не требует значительных затрат времени, он попросту не умеет по другому уже.
Абсолютно согласен. Главное тут - после сотен упражнений в голове формируются четкие паттерны что и когда гуглить.
Ну вот опять, "алгоритмы не нужны". Сколько бы раз до оптимизации не доходило ещё никто на могу памяти за 15 лет так и не смог применить алгоритм. Дайбох, понимают когда какую структуру данных применить - и то, в большинстве случаев просто динамический массив там где можно мап для быстрого доступа. Чтобы поменять алгоритмы надо уметь идентифицировать задачу, свести ее к модифицированной известной задаче. В бизнес проблемах никто не ставит задачу типа "дан двудольный граф", нужно уметь ИДЕНТИФИЦИРОВАТЬ задачу, а без опыта, навыков, фундамента это невозможно. У этих товарищей всегда "алгоритмы не нужны", потому что они даже не видят эти моменты когда нужно включиться в алгоритмику. Каждый раз, когда возникает проблема с производительностью, они начинают искать способы, гуглят, применяют ИИ чтобы найти новый фреймворк, натягивают кэширование, гуглят многоточку или тупо увеличивают тайм-аут. Они видят проблему в таймауте, в нехватке памяти и решают проблему с инфраструктурой а не бизнес логикой через алгоритмы. И это чаще чем вы думаете, проблема в том, что неправильно идентифицируют проблему!
А что не так с sonar, code smells и старой книжкой Мартина "Чистый Код"? Похоже на велосипед.
Снова уже знакомый автор со знакомым почерком... Сначала объявил войну самой логике, выкатив статью о том, что алгоритмы не нужны. А теперь против ООП, причем так и не смог самостоятельно привести примеры для аргументации, а просто привёл утрированные примеры. Вероятно побоялся привести реальные примеры, в которых его вкусовщина выдала бы в нем некомпетентность. Против алгоритмов, против ООП - зачем полез в университет? Стыдно за таких коллег. Основная проблема таких борцунов и проливателей света в том, что они абсолютно не владеют темой, против которого борятся.
Создаётся впечатление по статьям, что в России есть силы, которые хотят уничтожить некогда сильную индустрию через ложные постулаты и борьбу с искусством программирования. Новое поколение разработчиков не способно уже конкурировать с индусами. Примерная история у всех: вайти курсы, проскочить собесы вызубрив ненавистные паттерны и алгоритмы, никогда не применять паттерны и алгоритмы(потому что не поняли вызубренное) и кричать на каждом углу "они не нужны". Мало того ,что вайтишник за эти годы доросли до сеньоров и тимлидов по выслугу лет, так теперь ещё и до вузов добрались...
Это те же люди, которые гневно реагируют на элементарные, казалось бы, вещи типа тернарный оператор "а как же kiss! ? : это непонятно читается!" А там буквально 10 символов. То есть тупо простые конструкции не знают, не говоря об ООП, паттернах и т.д. Но всегда чинно парируют "а как же kiss?"
Все верно. Комментарии выше показывают их слабую компетенцию, вероятно джуны. Все эти знания важны, проблема именно в том, что олдскулл разработчики не знают названия своим навыкам, паттернам, которые применяют. А вайтишник наоборот, знают все названия паттернов, даже определения и даже (!) примеры могут привести. Однако, по комментариям выше видно, что не понимают смысл выученных слов совсем и считают, что никогда не пригодилось.
Участвовал в старте и не раз. И даже выиграл.
Но есть одно НО. Даже став победителем конкурса Старт, это не гарантирует, что получите деньги от этой структуры)) Уже на подписании контракта просто кинули нас студентов, которые открыли ООО для подписания. Влетели в копеечку. Сотрудники фонда бортника предложили нам формальное участие в следующем конкурсе год спустя и они нам отдадут победу, чтобы мы всё-таки забрали свой выигрыш.
Но, естественно, они обманули снова - на этот раз апеллировали к тому что мы подали второй раз тот же проект (а какой ещё подавать? Они же нам должны за этот проект, а не новый). Попросили нас на третий год подать, но с другим названием проекта, чтобы якобы не было повтора. Естественно, обманули снова)) 3-4 года мурыжили, не отдавая выигрыш. А у нас были уже договора с компаниями, заинтересованными в продукте. Все кончилось благодаря не вороватой и честной организации.
Столько времени, сил, нервов и денег впустую. Так что просьба не насмехаться высокомерно над командами, которые резонно считают, что эта организация полна договорняков.
Все зависит от позиции. Если Джун Data Scientist то 150 легко на старте. Если речь о html специалисте Джун или QA Джуниор, то на старте меньше конечно, в среднем. Наша компания в регионе, java junior без+ попадает в эту вилку. Так что зря ерничаете.
Такие алгоритмы хорошо использовать для генерации начальной популяции в генетическом алгоритме или колонии муравьев или пчел.
Тема разжевана на Хабре многократно за последние лет 15-20.
К чему очередная статья и довольно скупая? Возможно, нашлось новое применение? Нет, снова и снова задача коммивояжера. Возможно, новые результаты на бенчмарках? Нет, снова пустой звук без результатов.
В реализации и в целом в статье грубейшая ошибка, которая лишает всякого смысла генетический алгоритм - отсутствует оператор отбора/редукции. Отбор - основная движущая сила эволюции. Не путать с селекцией. В итоге получаем абсолютно хаотичный алгоритм, который никуда не движется.
С точки зрения Java также все очень грустно. Хромосома/особь не выделен в отдельную структуру/класс/сущность. Использование коллекций сожрал эффективность. Постоянная реаллокация одинаковых по смыслу коллекций на каждой итерации убьет сборщик мусора. Но на таких микрозадачах это не заметно.
Что хотел сказать автор, так и не стало ясно.
Кажется, пост не понят. Автор рассказывает, что интернет и монопольные сервисы сейчас обслуживают интересы крупного бизнеса, а не пользователей. Движущая сила эволюции - корпорации, а не наши с вами. Эволюция произошла для бизнеса, а поиск для пользователей стал дерьмом собачьим. То, что я мог легко найти в нулевые, сейчас либо невозможно либо нужно приложить нереальные усилия, даже пользуясь повсюду запрещённым в угоду медиамагнатам торрентом. И если вдруг нашелся опальный сайтик, мне нужно кучу рекламы просмотреть, отклонить уведомления, подписки и т.д. Это все потребности бизнеса, это все инструменты монетизации бизнеса. Вот о чем пост - эволюция произошла, но в сфере маркетинга и защиты бизнеса.
Кажется, восприятие позиции тимлида просто чересчур романтизировано. Описанные проблемы имеют место быть, но я воспринимаю их как конъюнктурные вводные условия задачи. Если конъюнктура не устраивает, значит не поняли свою позицию и задачу.
То чувство, когда оставлять комментарии опасно. Ведь теперь ОНИ - большинство))
Очевидно, раз сравнение идёт с молодыми, имеется в виду найм джунов. 100% преимущество у молодых. 40-50 летние вайтишники - это боль. Я видел, как 20 летние грузчики и другие люди из разных профессий успешно вошли в IT. Видел как 40-летний вайтишник проскочил собес на джуна, но не осилил далее. Сложно в большом возрасте переформатировать мышление, получить новые навыки в совершенно другой сфере.
Но 40-летний сеньор имеет колоссальное преимущество перед 25-летним сеньором. Бэкграунд у них, как правило, несопоставим.
В найме склоняюсь использовать возрастной ценз для различных грейдов. Чем выше грейд, тем выше возрастной потолок.
Про муравьиные алгоритмы, да и ещё для решения задачи коммивояжера, в Хабре полно статей. Эта, увы, одна из самых бедных.
Используем codestyle от intellij с форматированием на основе ОБЩЕПРИНЯТОГО google style. А в качестве плагина для проверки билда для CI - checkstyle. Codestyle с проектом в git.
Не понимаю, разговоров об отсутствии конвенции. Есть два варианта: олдскульный oracle java code style convention и google java code style convention.
Проблема реально высосана из пальца.