S0ER

думаю многое станет понятнее

Интересное обсуждение случилось в дискорде по поводу правила "не используйте -er в именах классов". И тут, видимо, нужны какие-то развернутые пояснения, но лучше чем автор, этого никто не сделает, поэтому посмотрите объяснения у Егора - https://www.yegor256.com/2015/03/09/objects-end-with-er.html

С остальными советами не согласен, некоторые нужно доработать, некоторые просто странные.

- Максимум 5 публичных методов в классе (помните про комбинатоную сложность, чем больше публичных методов, тем больше комбинаций между классами, использующих эти методы) - Не используйте статические методы - Не используйте синглтоны - Избегайте NULL

Некоторые интересные моменты, которые стоит зафиксировать из книги Бугаенко "Elegant Objects": - Не используйте "er" в имени классов (runner, doer и т.д.) - "Тонкие конструкторы класса" - только инициализации, без логики - Мелкие классы, лучше крупных (при рефакторинге объединять проще чем делить)

Яндекс продолжает набор на оплачиваемую летнюю стажировку. Важно: отлично проявившие себя стажеры получат шанс перейти в штат! Направления: фронтенд- и бэкенд-разработка, машинное обучение, аналитика, мобильная разработка и другие — ознакомиться с ними можно здесь. Особый формат стажировки — Deep Dive в Яндекс.Маркете. Сколько длится: от трех до 6 месяцев. Где: в Москве, Санкт-Петербурге, Екатеринбурге, Нижнем Новгороде, Новосибирске, Сочи, Симферополе и Минске. Если вы из другого города — Яндекс оплатит дорогу и проживание в Москве. Что нужно уметь: ждут отличного знания базовых алгоритмов и уверенных навыков программирования на одном из языков. Как проходит отбор: зависит от направления, но в большинстве случаев нужно будет выполнить тестовое задание, пройти два-три технических интервью, а затем выбрать команду. Подавайте заявку до 31 мая: https://clck.ru/TgiBN

У себя в телеграмме Senior Software Vlogger размышляет о том, как мы медленно и верно обучаем роботов делать работу человек. Каптча от Гугл заставляет нас распознавать знаки, светофоры, используя эти знания для обучения своих нейронных сетей и создавая автопилоты. Уже появляются проекты по автоматизации написания кода, они вроде как созданы помогать нам, но параллельно обучаются у нас же. То что искусственный интеллект научится писать код это даже не вопрос, а вопрос "когда" он научится это делать. Я как-то уже рассуждал о том, что генерация программы путем полного перебора всех перестановок - это теоретически рабочий вариант, но слишком затратный по ресурсам и времени. Но если задача разрешима за конечное, пусть даже очень большое время, то остается вопрос можно ли ее оптимизировать. И пока складывается ощущение, что возможно. Наиболее логичным шагом на ближайшее время мне видится замена юнит тестирования нейронными сетями. Например property-based тесты на базе AI. Почему нет? Без решения задачи по "проверке" корректности программы, задача по созданию кода мне кажется сомнительной. Так что ждем бум решений в области тестирования с помощью AI. Пост Димы - https://t.me/seniorsoftwarevlogger/650

Процесс цикличен и важно его осуществлять постепенно. Во-вторых, цена перехода на микросервисы как правило очень высока, и если бизнес испытывает финансовые трудности, то переход только ухудшит ситуацию. В-третьих, необходимо четко разделять обратимые и необратимые изменения, желательно планировать переход так, чтобы уменьшить количество необратимых изменений, хорошо продумать стратегию «отката» (касается технических решений). Конкретные шаги для перехода: 1. Внедрение Domain Driver Design 2. Разделение работы на разумные части (знать когда стоит остановиться) 3. Понять сущности своего дизайна и его границы (Event Storming – техника bottom-up анализа при которой определяется доменные события и обсуждается их влияние на систему) 4. Приоритезация задач на основе доменной модели (самые «востребованные» части не следует брать в работу первыми) 5. Проработать «комбинированные» состояния (часть имеющегося в монолите передается на откуп микросервисам) 6. Реорганизация команды 7. Перевод структур 8. Вносите изменения, а не просто копируйте функциональность 9. Развивайте профессиональные навыки 10. Определите контрольные точки (по которым будем понятно, что движение идет в нужном направлении) 11. Определите качественные характеристики (должны быть измеримыми и достижимыми) 12. Проводите регулярные оценки качества 13. Старайтесь рассматривать варианты решений беспристрастно. #monlith

Продолжаю конспект "Monolith to Microservices" Три важных вопроса при переходе на микросервисную архитектуру: - Какие цели вы хотите достигнуть благодаря переходу? - Какие альтернативы для микросервисов существуют? - Как вы поймете, что с микросервисами стало лучше? Возможные цели: - повышение автономности команд Одно из преимуществ микросервисной архитектуры – повышение автономности команд разработки. Но так же автономность команд можно повысить за счет разделения обязанностей в рамках модульного монолита. - уменьшение выхода на рынок За счет того, что нет необходимости координировать релиз одним монолитным обновлением микросервисы позволяет быстрее выводить на рынок новую функциональность, но так же можно попытаться найти и устранить «ботлнеки», мешающие быстро выводить продукт на рынок. - возможность гибко масштабировать нагрузку Микросервисная архитектура изначально задумывалась под задачи, требующие гибкого мастштабирования, но прежде чем переходить на новую архитектуру, следует понять, а исчерпаны ли возможности масштабирования в текущем решении. Вертикально и горизонтальное масштабирование могут выполняться не только в микросервисной архитектуре. - повышение работы на отказ Время вынужденного простоя – неприятная для бизнеса вещь, микросервисы идеально решают эту задачу, но так же стоит рассмотреть иные варианты – резервные узлы монолитной системы, горячая и холодная замена, балансировка нагрузки. - внедрение новых технологий В рамках микросервиса внедрять новые технологии значительно проще, и делать переход можно плавнее, в монолиты возможно внедрение новых технологий, если свести архитектуру к модульному монолиту. Ситуации, в которых точно не стоит идти в сторону микросервисов: - размытые границы домена - любые «стартапы» (есть исключения, но они лишь подтверждают правила) - продукты, распространяемые в виде пакетов установки - недостаточное понимание проблем и способов их решения в микросервисной архитектуре, микросервисы – это сложная архитектура, переход на нее очень дорогой и длительный. Идея слайдеров для принятия решения - мы не можем улучшить все параметры, улучшая что-то одно, мы уменьшаем другие показатели (находящиеся в противовесе), мы должны найти оптимальное распределение этих параметров. Если приняли решение переходить на микросервисы, то следует учесть следующее: Во-первых, внедрение микросервисов требует изменения кадровой политики и структуры организации. 8 шагов управления изменениям по Дж. Коттеру 1. Создать атмосферу безотлагательности действий (изучив рыночную ситуацию, конкурентные позиции компании; выявив и проанализировав реальные и потенциальные кризисы, благоприятные возможности) 2. Сформировать влиятельные команды реформаторов (объединив усилия влиятельных сотрудников, агентов перемен; поощряя деятельность участников сформированной команды). Развернуто и наглядно о том, как выполнять данный шаг написано в статье “Как создать команду реформаторов”. 3. Создать видение (создавая образ желаемого будущего с целью повышения активности сотрудников; разработав стратегию достижения видения). О том, как советует Дж. Коттер формулировать видение и определять стратегию читайте в отдельной заметке. 4. Пропагандировать новое видение (используя доступность изложения, метафоры, аналогии, примеры моделей нового поведения команды реформаторов) 5. Создать условия для претворения нового видения в жизнь (устраняя блокирующие новое поведение препятствия; изменяя структуры и обязанности, противоречащие новому видению; поощряя творческий подход и готовность рисковать) 6. Спланировать и достичь ближайшие результаты (планируя обязательные первые шаги; вознаграждая и пропагандируя первые успехи) 7. Закрепить достижения и расширить преобразования (создавая атмосферу доверия к новым подходам; меняя кадровый состав и проводя кадровые перестановки; распространяя успешный опыт по всей организации) 8. Институциализировать новые подходы (формализуя правила поведения; выстраивая взаимосвязь между результатами и вознаграждениями; создавая условия развития для новых качеств сотрудников).

Для иллюстрации монолитных и модульных архитектур интересно разобрать аналогию с человеком, очевидно, что человек - это монолит, но при этом это модульный монолит, так как у нас есть органы, которые отвечают за конкретные функции организма, но при этом замена и разделение на части - это очень проблематичная задача, которая в большинстве случаев приводит к плачевным результатам. Но когда несколько "монолитных людей" объединяются и решают задачу (например, строители на стройке), то они образуют более сложную структуру, которая является модульной, но для такой структуры нужна возможность управления (на стройке это прораб). Один человек может решать простые задачи, но при возрастании сложности поставленной задачи, требуется больше людей. Это по сути и есть уход от монолитности к модульности. В модульных системах - отдельные части это монолиты, но их тогда называют "атомарными" элементами, чтобы подчеркнуть, что это наименьшая функциональная единица архитектуры. #monlith #архитектурные_стримы

Идея монолитности в этой книге представляется как монолитность на уровне процесса развертывания. Если есть единый процесс развертывания, который всегда повторяется, то приложение которое лежит внутри цикла является монолитом. #monolith

Конспект по монолитам, зацеплению и связности из "Monolith to Microservices": - Single-process monolith – приложение которое разворачивается в одном цикле развертывания, как правило имеет один пакет развертывания и сильную связь внутри пакета - modular monolith – приложение, которое имеет несколько модулей с четко разделенными границами и низким зацеплением модулей, но так же развертывается в рамках одного цикла развертывания - distributed monolith – приложение которое состоит из нескольких сервисов, но развёртывается в едином цикле развертывания. “Delivery contention” – проблема монолитов при которой слишком много разработчиков хотят работать над одним и тем же кодом проекта. Но при этом монолиты гораздо проще разрабатывать, сопровождать, мониторить и развертывать. Связность (cohesion) и зацепление (coupling) – Связность должна быть высокой, зацепление низким. В монолитах это часто не так. Идея связности – код который имеет общую причину для изменения должен храниться в одно месте. В противном случае усиливается зацепление. Зацепление реализации (Implementation coupling) – компонент А так связан с компонентом Б, что при изменении Б необходимо изменить А. Временное зацепление (Temporal coupling) – это такое зацепление, которое возникает во время работы системы и зависит от порядка действий (их синхронности), например, такое зацепление возникает во время синхронных запросов в распределенных системах, на все время синхронизации компоненты становятся зацепленными. Временное зацепление можно ослабить за счет кэширования или использования брокера сообщений. Зацепление развертывание (Deployment coupling) – зацепление возникающих из-за единого цикла развертывания. Если изменения возникли в одном модуле, мы все равно должны повторно развернуть все модули, так как цикл развертывания един. Решение Hot reload. Доменное зацепление (Domain coupling) – зацепление между реальным (бизнес) доменом и реализацией сервисов. Если для решения бизнес-задачи нужно задействовать несколько сервисов (или микросервисов) они считаются доменно зацепленными. Решается (по возможности) сокрытием информации. Чем меньше информации нужно для решения поставленной задачи, тем меньше зацепление. #monolith