Так можно не только про микросервисы сказать, но и про сам DDD. В темах посвященных тактике DDD комментариев сильно больше и, по моему, ни одна тема не обходится без
DDD - это полная лажа, так как куча абстракций и ненужных сложностей и невозможно отделить бизнеслогику от инфраструктуры
Меня, как разработчика на тактическом уровне, такие комментарии вымораживают куда больше.
Удивительно, что под статьями посвященными стратегии в DDD практически нет комментариев. Сомневаюсь, что к этой тем нет интереса. Тогда что? Настолько мало специалистов, что прочитанное кажется дикими дебрями? Может потому что, люди видят рядом с упоминанием об ограниченных контекстах упоминание о микросервисах, прикидывают, что в микросервисную архитектуру лезть нет желания и закрывают статью? Но никто же не говорит, что ограниченные контексты не могут быть в монолите в виде отдельных хорошо изолированных модулей.
Совершенно не имею причин спорить со сказанным вами. Вот только проблемы с быстродействием в мобильных устройствах не так остро стоят, как проблемы быстродействия центров обработки информации. И вот там они будут готовы хоть гробы поставить, лишь бы по меньше энергии тратить и при этом получить больше производительности. Проблема снабжения электроэнергией, отвода тепла и защита от электромагнитного излучения - все это очень и очень острые проблемы. Вот если бы еще сделать компьютеры, которые вообще без энергии работали! (шутка с отсылкой на юмористическую статью про энергонезависимую программу) Edit: нашел статью: https://habr.com/ru/articles/146730/
Но разве нельзя просто делать процессоры побольше? Электронные процессоры делают меньше для энергоэффективности и для борьбы с переходными процессами. В оптике можно не экономить на размере. Ну будет процессор в 10 или даже в 50 раз больше - для стационарных компьютеров это вообще не проблема. Или есть нюансы кроме теплоемкости большого по объему процессора?
Полагаю, что идея кроется в том, что оптоэлементы при пропуске через себя света не прогреваются таким же образом как транзисторы при пропуске через себя электронов. Так же полагаю, что оптоэлементы не на столько подвержены переходным процессам, как транзисторы, которым нужно время, чтобы перейти из одного состояния в другое. Но на практике, ведь, свет нужно и излучать и принимать на датчики, чтобы считать сигнал. Выглядит это как что-то, что должно требовать больше времени. Так что тоже интересно познакомиться с теорией. Быть может тут некий аналог пневмопроцессоров, который, если проводить аналогию, не требует нескольких этапов поглощения излучения и излучения его обратно для следующих этапов.
Я не слишком погружен в тематику реверс инжиниринга байткода. Можете объяснить зачем вообще была проведена такая работа? Спортивный интерес или какой-то другой смысл?
Мой личный опыт говорит, что сенсоры - зло. Человеку нужны тактильные ощущения для комфорта управления механизмами. Иначе сенсорные клавиатуры уже получили бы большое распространение - они же дешевле. Но вместо этого все мои знакомые, как и я, покупаем механическую клавиатуру для набора текста. Многие даже дорогие гаджеты с сенсорным управлением больше бесят, чем помогают из-за ложных срабатываний и отсутствия тактильных ощущений.
возможность вводить в эксплуатацию новые экземпляры микросервиса буквально в пару кликов мышкой
возможность использовать один микросервис разными продуктами одной организации
возможность отдать разработку микросервисов разным командам с различным техническим стеком, что позволяет в свою очередь решить проблему с наймом кадров, когда достаточно квалифицированных программистов приверженных к определенному техническому стеку на рынке просто нет, а так же позволяет использовать более специализированные технические стеки для задач, возложенных на микросервис
...
А минусов... Их перечислять можно устать!
Просадка по быстродействию, так как ни одна микросервисная архитектура не сравнится по быстродействию с монолитом, выполненным на том же уровне качества. Причина тут в потере времени на распространении информации между микросервисами и/или на прямом общении между микросервисами. Так же часто появляются лишние абстракции такие как APIGateway и прочие, что жрут деньги как не в себя. И не нужно говорить, что мощности монолита не масштабируются - еще как масштабируются!
Разделение на множество микросервисов увеличивает общую сложность архитектуры. Нужно продумывать взаимодействие между сервисами, их границы и зависимости.
Труднее отследить и устранить ошибки, которые проявляются в связях между микросервисами.
Возможность использовать разные технологии в микросервисах может усложнить поддержку из-за необходимости владения множеством инструментов - потеря специалистов может ударить фатально по всей организации, несмотря на то, что штат уменьшится незначительно.
Необходимы сложные системы для централизованного мониторинга, трассировки запросов и анализа логов.
Нужен целый штат девопсов, чтобы следить за всем созданным зверинцем микросервисов, который рано или поздно превратится в закрытый Ктулху клан, а потом ему нужно будет приносить разнообразные и многочисленные жертвы.
Любая неполадка внутренней сетевой коммуникации приводит к тому, что проект не просто тормозит, а приводит проект к неконсистентному состоянию БД. Это, конечно, решается и есть механизмы, но нужны специалисты и нужно время на поддержку или даже реализацию этих механизмов.
Если разные команды отвечают за разные микросервисы, потребуется налаженная коммуникация и четкое разделение ответственности. Но обычно с этим справляются не сразу, так как это не только про "программисты пообщались", а про деньги.
Микросервисы должны согласовывать контракты (API для OpenHost микросервисов и облако доменных событий для остальных) для взаимодействия. Изменения в одном сервисе могут повлиять на другие. В мире не так уж много специалистов, кто сможет спроектировать контракты и еще меньше тех, кто сможет их поддерживать длительное время не допуская мешанины, которая приведет к тому, что некоторые сервисы станут либо закрытыми для доработки, либо опасными для использования. И посмотрел бы я на то, кто именно решится на пересмотр доменных событий после года проектировки микросервисов - даже небольшое изменение событий ядра может привести к созданию новых версий большей части микросервисов, что привнесет на ровном месте столько когнитивной нагрузки, что проще уволиться.
При развитии системы требуется поддерживать обратную совместимость между различными версиями микросервисов. А так же бояться увольнять тех людей, которые знают почему микросервис был таким, а стал таким и какие мины в нем зарыты.
Буквально всех разработчиков придется вводить в курс как работает оркестрация микросервисов, какие этапы CI/CD в целом у всех микросервисов и какие у отдельных в частности. А ведь у нас есть как минимум три программных окружения: DEV, Staging/testing, prod и каждый обязательно заимеет свою специфику.
...
Часто общаюсь на тему микросервисов с разработчиками и рассказываю, что почти всё, что они хотят от микросервисов, доступно и в монолите. А что недоступно, то можно вынести в небольшие OpenHost микросервисы, требующие к себе минимальное внимание и даже не требующие себя разворачивать в DEV окружении. И зачастую разработчики отказываются потом менять шило на мыло, когда достаточно поднять свою квалификацию и решить все проблемы здесь и сейчас. Нужно знать зачем именно нужны вам микросервисы и знать - перевешивают ли плюсы все получаемые минусы. Сейчас я за смешанную архитектуру, где основной код в монолите.
Комментарий появился потому что я не увидел убедительных аргументов за переход от монолита к микросервисам, а не потому что, я захотел открыть новый холивар. Повторюсь - микросервисы могут быть полезными. Но очень многие неосмотрительно перепрыгнули на микросервисную архитектуру, когда им в действительности хватало и монолита или в крайнем случае распределенного монолита. В итоге они забывали про микросервисы, понимали плюсы монолита, но делали уже распределенный монолит из-за невозможности вернуть время вспять, чтобы откатиться обратно. И скорее я писал комментарий не для автора статьи - он уже все для себя решил, а для романтически настроенных программистов и их менеджеров, которые могут вдохновиться статьей.
Почему в топе постоянно появляются статьи, написанные на одних только эмоциях, людьми не имеющими достаточной квалификации, чтобы говорить авторитетно на затронутые темы?
Знает ли автор, что такое вообще управление?
Управленец руководит кадрами, способствует распространению нужной информации и пресекает паразитную информацию.
Управленец видит тенденции и умеет вычленять частное из общего, чтобы понять, кто действительно играет ключевую роль в функционировании организации, а кто выполняет лишь декоративные функции или даже препятствует прогрессу.
Руководитесь умеет декомпозировать и делегировать задачи, в чем опирается на предыдущие два пункта. Техническое знание в таком процессе бывает даже вредно, так как может сделать руководителя предвзятым.
Автор статьи, наверное, пропустил целый поезд статей по всему миру, где хорошо раскрывалось, что даже архитекторы IT проектов не обязаны уметь программировать - от них требуются другие навыки. Кто-то даже замахивался на то, что и тимлиды не обязаны программировать, но говорить, что не должны быть техническими специалистами, еще не решаются. Но я таких тимлидов видел. И они вполне успешны, ведь никого не волнует - умеешь ты настраивать софт или программировать, если вне зависимости от этого твой результат соответствует ожиданиям. Например, в организации, где я работаю тимлидом, много команд кроме моей и технический уровень тимлидов разнится как пропасть и небо, но при этом все команды эффективны примерно одинаково, так как каждый тимлид знает где и чьи компетенции из его команды закрывают его потребности.
Умение руководить - это быть аналитиком и специалистом по работе с людьми, а не все то, что вы написали. Попробуйте вникнуть, например, в ДОТУ (Достаточно общая теория управления). Возможно многое там вам покажется пропагандой, но основные тезисы работают в практике руководителей как математика в физике.
Руководитель прислушается, так как руководитель будет вникать в специфику подконтрольного ему объекта. Он найдет и источники правды, и авторитетов, и слабые места. Технарем для этого быть не обязательно - нужен лишь пытливый ум и умение управлять. А человек лишь с биркой руководителя - нет, не прислушается, так как не имеет соответствующих личностных качеств или навыков управления. Как много механиков среди начальников железных дорог?
Считаю уместным Ваше замечание про застой. В своей организации при собеседовании я на вопрос "А как вы справляетесь с легаси кодом" отвечаю кандидату на вакансию: "Мы справляемся путем найма тех, кто может это исправить". Очень интересно смотреть в этот момент на кандидата. Если загораются глаза, да еще и озвучиваются какие-то хотя бы обобщенные идеи - это уже наш сотрудник.
Спасибо! В реальных проектах почти не встречаются значения . На Земле вообще нет ничего, что можно было бы измерять такими числами при автоматизации бизнеса, кроме Big Data. Такие числа встречаются в астрономии, но астрономам, предполагаю, нет дела до fusc последовательности и ее рекордсменов. Думаю, единственное их место применения - теория чисел и комбинаторика. Причем прикладной смысл будут иметь только производные формулы и числовые последовательности. Так что полностью согласен с вашими словами.
Ничего в них сложного нет. Как и в фотошопе. Но, почему-то, для работы в фотошопе нанимают соответствующих специалистов, чтобы получать именно тот результат, на который рассчитываешь, а не поделки из детского сада.
Это математически обоснованная закономерность, когда в социуме люди стремятся к общей выгоде в ущерб краткосрочной личной выгоде. На выходе каждый в социуме получает многократно большую выгоду.
По сути, вы кратко и иносказательно изложили дилемму заключённого. А точнее - её обобщение: дилемму общих ресурсов (tragedy of the commons). Там показано, что совместное сотрудничество ради общей пользы в долгосрочной перспективе может обеспечить значительно лучшие результаты для всех участников, чем краткосрочная индивидуальная выгода.
Эта идея активно исследовалась также в рамках эволюционной теории и моделей коллективного поведения. Одним из важных трудов в этой области является работа Элинор Остром, которая изучала механизмы успешного управления общими ресурсами, доказывая, что люди способны организовываться и достигать общей выгоды.
Большим опытом в олимпиадном программировании похвастаться не могу, но в энтерпрайз проектах я уже скоро пятнадцатилетие отмечу. На этом фоне могу сказать, что навыки из олимпиадного программирования важны и в реальных проектах.
Все пригодилось:
анализ сложности алгоритма - как не удивительно, но часто помогает уменьшить когнитивную нагрузку, которой нагружает код своего читателя
понимание комбинаторики - пригождается при анализе сложности интерфейса микросервиса/модуля/библиотеки
понимание теории вероятностей - часто пригождается при проверке на нарушение SRP из SOLID (выявление вероятности изменения части кода, которая может подвергнуться изменениям при изменении требований к проекту) и при организации работы с брокером сообщений
...
Конечно, применяются эти навыки не так как при решении олимпиадных задач. Тут больше работает понимание принципов. Но один раз был случай и прямого применения, когда нужно было сопоставить две масштабные базы данных продуктов из разных магазинов с разными структурами определяющими свойства продуктов и объединить в единую систему категоризации с единой структурой свойств - чем не олимпиадное программирование?
Просто хотел сказать, что с ростом навыков можно не только олимпиадные задачи пересмотреть, но и боевые проекты.
Уверен, что упомянутый вами способ имеется. Я потратил много времени пытаясь пройти вашим путем решения задачи. Из-за этого даже завидую вам. Возможно и я бы на него наткнулся, если бы не начал анализировать бинарное представление промежутков между рекордсменами. В итоге у меня максимально высокая производительность программы и скорее я упрусь в переполнение числовых типов данных, чем в то, что превышу данное время на исполнение в 1 секунду при увеличении зоны поиска. Примечательно, что в вашей задаче дается всего 64MB ОЗУ при еще большем диапазоне поиска максимума. Такие ограничения выглядят еще более суровыми. Каким языком программирования вы воспользовались?
Вульгарное (не оскорбление) у вас восприятие всех перечисленных принципов. Конечно же SRP достижим даже в условиях, когда фреймворк диктует агрегацию функционала в нескольких классах. В больших проектах для соблюдения SOLID зачастую происходит абстрагирование от фреймворка на любых платформах. Когда же вы абстрагировались от фреймворка, то можете соблюдать любые принципы, в том числе и SOLID.
OCP - вообще не про расширение классов, а про расширение функционала без изменения уже ранее написанного. Могу дать самые очевидные отсылки: декорация, проксирование, адаптирование, Chain of Responsibility, композиция и прочее, прочее...
LS - опять же про полиморфизм и контракты, которые ничего не рушат. Та же самая композиция зачастую только выигрывает от данного принципа. Если вам зачем-то нужно реализовать кучу всего лишнего в предках, то у вас нарушения архитектуры и SRP. Добавьте сюда еще и ISP поймете, что, например, те же репозитории (шаблон проектирования) могут реализовывать методы нескольких интерфейсов не нарушая SRP, но клиентский код получает этот функционал посредством небольших интерфейсов, в которых есть только нужный в конкретном месте применения функционал. Противоречия нет вообще.
SRP - цветет и пахнет именно в больших проектах, которые без него вообще невозможны. В микро проектах - наоборот часто его нарушают, так как не всегда архитектура и чистота кода требуется в мобильном проекте с одной кнопкой. Так что вы тут все перевернули с ног на голову.
И вообще, в конце‑концов любая объектная программа представляет собой дерево, которое сходится к буквально нескольким классам, которые и представляют собой программу и потому никакая «единственная ответственность» даже теоретически не достижима.
Это вообще не связано с реальностью. В ООП по большей части наследование - скорее исключение чем правило. Почитайте почему чаще используется композиция и агрегация вместо наследования. К тому же нужно понимать, что большая программа - никак не дерево, а набор слоев абстракций, что с древообразной структурой имеет мало общего.
О да! Сколько проблем при проектировке это бы решило!
Так можно не только про микросервисы сказать, но и про сам DDD. В темах посвященных тактике DDD комментариев сильно больше и, по моему, ни одна тема не обходится без
Меня, как разработчика на тактическом уровне, такие комментарии вымораживают куда больше.
Удивительно, что под статьями посвященными стратегии в DDD практически нет комментариев. Сомневаюсь, что к этой тем нет интереса. Тогда что? Настолько мало специалистов, что прочитанное кажется дикими дебрями? Может потому что, люди видят рядом с упоминанием об ограниченных контекстах упоминание о микросервисах, прикидывают, что в микросервисную архитектуру лезть нет желания и закрывают статью? Но никто же не говорит, что ограниченные контексты не могут быть в монолите в виде отдельных хорошо изолированных модулей.
Совершенно не имею причин спорить со сказанным вами. Вот только проблемы с быстродействием в мобильных устройствах не так остро стоят, как проблемы быстродействия центров обработки информации. И вот там они будут готовы хоть гробы поставить, лишь бы по меньше энергии тратить и при этом получить больше производительности. Проблема снабжения электроэнергией, отвода тепла и защита от электромагнитного излучения - все это очень и очень острые проблемы. Вот если бы еще сделать компьютеры, которые вообще без энергии работали! (шутка с отсылкой на юмористическую статью про энергонезависимую программу)
Edit: нашел статью: https://habr.com/ru/articles/146730/
Но разве нельзя просто делать процессоры побольше? Электронные процессоры делают меньше для энергоэффективности и для борьбы с переходными процессами. В оптике можно не экономить на размере. Ну будет процессор в 10 или даже в 50 раз больше - для стационарных компьютеров это вообще не проблема. Или есть нюансы кроме теплоемкости большого по объему процессора?
Полагаю, что идея кроется в том, что оптоэлементы при пропуске через себя света не прогреваются таким же образом как транзисторы при пропуске через себя электронов. Так же полагаю, что оптоэлементы не на столько подвержены переходным процессам, как транзисторы, которым нужно время, чтобы перейти из одного состояния в другое. Но на практике, ведь, свет нужно и излучать и принимать на датчики, чтобы считать сигнал. Выглядит это как что-то, что должно требовать больше времени. Так что тоже интересно познакомиться с теорией. Быть может тут некий аналог пневмопроцессоров, который, если проводить аналогию, не требует нескольких этапов поглощения излучения и излучения его обратно для следующих этапов.
Я не слишком погружен в тематику реверс инжиниринга байткода. Можете объяснить зачем вообще была проведена такая работа? Спортивный интерес или какой-то другой смысл?
Мой личный опыт говорит, что сенсоры - зло. Человеку нужны тактильные ощущения для комфорта управления механизмами. Иначе сенсорные клавиатуры уже получили бы большое распространение - они же дешевле. Но вместо этого все мои знакомые, как и я, покупаем механическую клавиатуру для набора текста. Многие даже дорогие гаджеты с сенсорным управлением больше бесят, чем помогают из-за ложных срабатываний и отсутствия тактильных ощущений.
Микросервисы обладают своими плюсами, такими как:
возможность вводить в эксплуатацию новые экземпляры микросервиса буквально в пару кликов мышкой
возможность использовать один микросервис разными продуктами одной организации
возможность отдать разработку микросервисов разным командам с различным техническим стеком, что позволяет в свою очередь решить проблему с наймом кадров, когда достаточно квалифицированных программистов приверженных к определенному техническому стеку на рынке просто нет, а так же позволяет использовать более специализированные технические стеки для задач, возложенных на микросервис
...
А минусов... Их перечислять можно устать!
Просадка по быстродействию, так как ни одна микросервисная архитектура не сравнится по быстродействию с монолитом, выполненным на том же уровне качества. Причина тут в потере времени на распространении информации между микросервисами и/или на прямом общении между микросервисами. Так же часто появляются лишние абстракции такие как APIGateway и прочие, что жрут деньги как не в себя. И не нужно говорить, что мощности монолита не масштабируются - еще как масштабируются!
Разделение на множество микросервисов увеличивает общую сложность архитектуры. Нужно продумывать взаимодействие между сервисами, их границы и зависимости.
Труднее отследить и устранить ошибки, которые проявляются в связях между микросервисами.
Возможность использовать разные технологии в микросервисах может усложнить поддержку из-за необходимости владения множеством инструментов - потеря специалистов может ударить фатально по всей организации, несмотря на то, что штат уменьшится незначительно.
Необходимы сложные системы для централизованного мониторинга, трассировки запросов и анализа логов.
Нужен целый штат девопсов, чтобы следить за всем созданным зверинцем микросервисов, который рано или поздно превратится в закрытый Ктулху клан, а потом ему нужно будет приносить разнообразные и многочисленные жертвы.
Любая неполадка внутренней сетевой коммуникации приводит к тому, что проект не просто тормозит, а приводит проект к неконсистентному состоянию БД. Это, конечно, решается и есть механизмы, но нужны специалисты и нужно время на поддержку или даже реализацию этих механизмов.
Если разные команды отвечают за разные микросервисы, потребуется налаженная коммуникация и четкое разделение ответственности. Но обычно с этим справляются не сразу, так как это не только про "программисты пообщались", а про деньги.
Микросервисы должны согласовывать контракты (API для OpenHost микросервисов и облако доменных событий для остальных) для взаимодействия. Изменения в одном сервисе могут повлиять на другие. В мире не так уж много специалистов, кто сможет спроектировать контракты и еще меньше тех, кто сможет их поддерживать длительное время не допуская мешанины, которая приведет к тому, что некоторые сервисы станут либо закрытыми для доработки, либо опасными для использования. И посмотрел бы я на то, кто именно решится на пересмотр доменных событий после года проектировки микросервисов - даже небольшое изменение событий ядра может привести к созданию новых версий большей части микросервисов, что привнесет на ровном месте столько когнитивной нагрузки, что проще уволиться.
При развитии системы требуется поддерживать обратную совместимость между различными версиями микросервисов. А так же бояться увольнять тех людей, которые знают почему микросервис был таким, а стал таким и какие мины в нем зарыты.
Буквально всех разработчиков придется вводить в курс как работает оркестрация микросервисов, какие этапы CI/CD в целом у всех микросервисов и какие у отдельных в частности. А ведь у нас есть как минимум три программных окружения: DEV, Staging/testing, prod и каждый обязательно заимеет свою специфику.
...
Часто общаюсь на тему микросервисов с разработчиками и рассказываю, что почти всё, что они хотят от микросервисов, доступно и в монолите. А что недоступно, то можно вынести в небольшие OpenHost микросервисы, требующие к себе минимальное внимание и даже не требующие себя разворачивать в DEV окружении. И зачастую разработчики отказываются потом менять шило на мыло, когда достаточно поднять свою квалификацию и решить все проблемы здесь и сейчас. Нужно знать зачем именно нужны вам микросервисы и знать - перевешивают ли плюсы все получаемые минусы. Сейчас я за смешанную архитектуру, где основной код в монолите.
Комментарий появился потому что я не увидел убедительных аргументов за переход от монолита к микросервисам, а не потому что, я захотел открыть новый холивар. Повторюсь - микросервисы могут быть полезными. Но очень многие неосмотрительно перепрыгнули на микросервисную архитектуру, когда им в действительности хватало и монолита или в крайнем случае распределенного монолита. В итоге они забывали про микросервисы, понимали плюсы монолита, но делали уже распределенный монолит из-за невозможности вернуть время вспять, чтобы откатиться обратно. И скорее я писал комментарий не для автора статьи - он уже все для себя решил, а для романтически настроенных программистов и их менеджеров, которые могут вдохновиться статьей.
Почему в топе постоянно появляются статьи, написанные на одних только эмоциях, людьми не имеющими достаточной квалификации, чтобы говорить авторитетно на затронутые темы?
Знает ли автор, что такое вообще управление?
Управленец руководит кадрами, способствует распространению нужной информации и пресекает паразитную информацию.
Управленец видит тенденции и умеет вычленять частное из общего, чтобы понять, кто действительно играет ключевую роль в функционировании организации, а кто выполняет лишь декоративные функции или даже препятствует прогрессу.
Руководитесь умеет декомпозировать и делегировать задачи, в чем опирается на предыдущие два пункта. Техническое знание в таком процессе бывает даже вредно, так как может сделать руководителя предвзятым.
Автор статьи, наверное, пропустил целый поезд статей по всему миру, где хорошо раскрывалось, что даже архитекторы IT проектов не обязаны уметь программировать - от них требуются другие навыки. Кто-то даже замахивался на то, что и тимлиды не обязаны программировать, но говорить, что не должны быть техническими специалистами, еще не решаются. Но я таких тимлидов видел. И они вполне успешны, ведь никого не волнует - умеешь ты настраивать софт или программировать, если вне зависимости от этого твой результат соответствует ожиданиям. Например, в организации, где я работаю тимлидом, много команд кроме моей и технический уровень тимлидов разнится как пропасть и небо, но при этом все команды эффективны примерно одинаково, так как каждый тимлид знает где и чьи компетенции из его команды закрывают его потребности.
Умение руководить - это быть аналитиком и специалистом по работе с людьми, а не все то, что вы написали. Попробуйте вникнуть, например, в ДОТУ (Достаточно общая теория управления). Возможно многое там вам покажется пропагандой, но основные тезисы работают в практике руководителей как математика в физике.
Руководитель прислушается, так как руководитель будет вникать в специфику подконтрольного ему объекта. Он найдет и источники правды, и авторитетов, и слабые места. Технарем для этого быть не обязательно - нужен лишь пытливый ум и умение управлять. А человек лишь с биркой руководителя - нет, не прислушается, так как не имеет соответствующих личностных качеств или навыков управления. Как много механиков среди начальников железных дорог?
Считаю уместным Ваше замечание про застой. В своей организации при собеседовании я на вопрос "А как вы справляетесь с легаси кодом" отвечаю кандидату на вакансию: "Мы справляемся путем найма тех, кто может это исправить". Очень интересно смотреть в этот момент на кандидата. Если загораются глаза, да еще и озвучиваются какие-то хотя бы обобщенные идеи - это уже наш сотрудник.
Спасибо! В реальных проектах почти не встречаются значения
. На Земле вообще нет ничего, что можно было бы измерять такими числами при автоматизации бизнеса, кроме Big Data. Такие числа встречаются в астрономии, но астрономам, предполагаю, нет дела до fusc последовательности и ее рекордсменов. Думаю, единственное их место применения - теория чисел и комбинаторика. Причем прикладной смысл будут иметь только производные формулы и числовые последовательности. Так что полностью согласен с вашими словами.
Надеюсь, что уволенные из организации автора статьи сотрудники прочитают все эти комментарии.
Ничего в них сложного нет. Как и в фотошопе. Но, почему-то, для работы в фотошопе нанимают соответствующих специалистов, чтобы получать именно тот результат, на который рассчитываешь, а не поделки из детского сада.
Это математически обоснованная закономерность, когда в социуме люди стремятся к общей выгоде в ущерб краткосрочной личной выгоде. На выходе каждый в социуме получает многократно большую выгоду.
По сути, вы кратко и иносказательно изложили дилемму заключённого. А точнее - её обобщение: дилемму общих ресурсов (tragedy of the commons). Там показано, что совместное сотрудничество ради общей пользы в долгосрочной перспективе может обеспечить значительно лучшие результаты для всех участников, чем краткосрочная индивидуальная выгода.
Эта идея активно исследовалась также в рамках эволюционной теории и моделей коллективного поведения. Одним из важных трудов в этой области является работа Элинор Остром, которая изучала механизмы успешного управления общими ресурсами, доказывая, что люди способны организовываться и достигать общей выгоды.
Большим опытом в олимпиадном программировании похвастаться не могу, но в энтерпрайз проектах я уже скоро пятнадцатилетие отмечу. На этом фоне могу сказать, что навыки из олимпиадного программирования важны и в реальных проектах.
Все пригодилось:
анализ сложности алгоритма - как не удивительно, но часто помогает уменьшить когнитивную нагрузку, которой нагружает код своего читателя
понимание комбинаторики - пригождается при анализе сложности интерфейса микросервиса/модуля/библиотеки
понимание теории вероятностей - часто пригождается при проверке на нарушение SRP из SOLID (выявление вероятности изменения части кода, которая может подвергнуться изменениям при изменении требований к проекту) и при организации работы с брокером сообщений
...
Конечно, применяются эти навыки не так как при решении олимпиадных задач. Тут больше работает понимание принципов. Но один раз был случай и прямого применения, когда нужно было сопоставить две масштабные базы данных продуктов из разных магазинов с разными структурами определяющими свойства продуктов и объединить в единую систему категоризации с единой структурой свойств - чем не олимпиадное программирование?
Просто хотел сказать, что с ростом навыков можно не только олимпиадные задачи пересмотреть, но и боевые проекты.
Уверен, что упомянутый вами способ имеется. Я потратил много времени пытаясь пройти вашим путем решения задачи. Из-за этого даже завидую вам. Возможно и я бы на него наткнулся, если бы не начал анализировать бинарное представление промежутков между рекордсменами. В итоге у меня максимально высокая производительность программы и скорее я упрусь в переполнение числовых типов данных, чем в то, что превышу данное время на исполнение в 1 секунду при увеличении зоны поиска.
Примечательно, что в вашей задаче дается всего 64MB ОЗУ при еще большем диапазоне поиска максимума. Такие ограничения выглядят еще более суровыми. Каким языком программирования вы воспользовались?
https://www.amcharts.com/ - тут есть такой функционал и не только такой.
Вульгарное (не оскорбление) у вас восприятие всех перечисленных принципов. Конечно же SRP достижим даже в условиях, когда фреймворк диктует агрегацию функционала в нескольких классах. В больших проектах для соблюдения SOLID зачастую происходит абстрагирование от фреймворка на любых платформах. Когда же вы абстрагировались от фреймворка, то можете соблюдать любые принципы, в том числе и SOLID.
OCP - вообще не про расширение классов, а про расширение функционала без изменения уже ранее написанного. Могу дать самые очевидные отсылки: декорация, проксирование, адаптирование, Chain of Responsibility, композиция и прочее, прочее...
LS - опять же про полиморфизм и контракты, которые ничего не рушат. Та же самая композиция зачастую только выигрывает от данного принципа. Если вам зачем-то нужно реализовать кучу всего лишнего в предках, то у вас нарушения архитектуры и SRP. Добавьте сюда еще и ISP поймете, что, например, те же репозитории (шаблон проектирования) могут реализовывать методы нескольких интерфейсов не нарушая SRP, но клиентский код получает этот функционал посредством небольших интерфейсов, в которых есть только нужный в конкретном месте применения функционал. Противоречия нет вообще.
SRP - цветет и пахнет именно в больших проектах, которые без него вообще невозможны. В микро проектах - наоборот часто его нарушают, так как не всегда архитектура и чистота кода требуется в мобильном проекте с одной кнопкой. Так что вы тут все перевернули с ног на голову.
Это вообще не связано с реальностью. В ООП по большей части наследование - скорее исключение чем правило. Почитайте почему чаще используется композиция и агрегация вместо наследования. К тому же нужно понимать, что большая программа - никак не дерево, а набор слоев абстракций, что с древообразной структурой имеет мало общего.