S0ER

На прошлых выходных участвовал в митапе по обсуждению архитектуры, такое ощущение, что все специально делают одни и те же ошибки.

Рома Труфанов написал хороший пост в тему: Trufanov Roman — Сегодня, в 13:18 Вброшу немного своего мнения xD Вообще про суффиксы все сказанное кажется немного вырванным из контекста. Тут нужно строго зафиксировать несколько моментов. - Мы говорим про ООП, то бишь про объекты и их взаимодействия. - Также нужно учитывать возможность языка программирования. - И также нужно учитывать контекст в котором приходится работать. Если говорить чуть точнее, то нету ничего плохого в использовании каких бы то не было суффиксов. Как по мне, основная проблема это неправильно подобранная абстракция. К примеру если у нас в коде есть класс с названием Manager, то совсем непонятно что это за менеджер такой. Это может быть роль, тогда в таком названии нету ничего особенного. Также это может быть название какой то сущности, о которой говорит заказчик, тут надуманно конечно, но к примеру менеджер = система, которая управляет заказами. А вот что недопустимо, это придумывать класс Менеджер, которого нету в бизнес домене совсем. Ну к примеру у нас есть какая то логика и где же ее нужно разместить, вот и придумывают Менеджеров, Процессеров и прочие -еров. Что касается использования названий паттернов, то также не обязательно писать суффикс (Adapter, Factroy и т.д.). Помним, что паттерн это не цель, а это то, что уже проявляется в коде. К паттерну приходят либо во время проектирования, когда понимают, что взаимодействие объектов похоже на определенный паттерн. Либо во время рефакторинга, когда получившаяся структура начинает быть похожа на опять определенный паттерн. Вот не разу не было качественного решения, где бы брали и стали пытаться насильно достичь использования конкретных паттернов. Это всегда связано с решаемой задачей и текущей ситуацией в коде.

Ну а мое отношение такое - я считаю, что паттерны (например, Observer) и "поведение" могут быть реализованы через класс, но нужно быть осторожным, так как лучше придерживаться максимально "чистого" ООП и создавать объекты, которые действительно являются объектами, а не абстрактной логикой.

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

Интересное обсуждение случилось в дискорде по поводу правила "не используйте -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. Институциализировать новые подходы (формализуя правила поведения; выстраивая взаимосвязь между результатами и вознаграждениями; создавая условия развития для новых качеств сотрудников).