#проектирование_и_рефакторинг — Public Fediverse posts

Flutter-дайджест: март 2026

Март выдался… немного тише, чем февраль . Без громких релизов уровня Flutter 3.x — но это не значит, что было скучно 😉 Наоборот — месяц получился про практику, реальные кейсы и прокачку навыков 💪 А ещё… несмотря ни на что — мы продолжаем работать. Да, даже несмотря на блокировки Telegram — ❌ мы никуда не уходим ❌ в MAX не переезжаем ✅ и продолжаем делать лучший Flutter-контент для вас 👉 Подписка на канал сейчас — это реальная поддержка проекта ❤️ https://t.me/flutterpulse

https://habr.com/ru/articles/1018402/

#разработка_мобильных_приложений #управление_разработкой #проектирование_и_рефакторинг #качество_кода #тестирование_мобильных_приложений #облачные_сервисы #вебразработка #open_source #искусственный_интеллект #учебный_процесс_в_it

Flutter-дайджест: март 2026

Март выдался… немного тише, чем февраль . Без громких релизов уровня Flutter 3.x — но это не значит, что было скучно 😉 Наоборот — месяц получился про практику, реальные кейсы и прокачку навыков 💪 А ещё… несмотря ни на что — мы продолжаем работать. Да, даже несмотря на блокировки Telegram — ❌ мы никуда не уходим ❌ в MAX не переезжаем ✅ и продолжаем делать лучший Flutter-контент для вас 👉 Подписка на канал сейчас — это реальная поддержка проекта ❤️ https://t.me/flutterpulse

https://habr.com/ru/articles/1018402/

#разработка_мобильных_приложений #управление_разработкой #проектирование_и_рефакторинг #качество_кода #тестирование_мобильных_приложений #облачные_сервисы #вебразработка #open_source #искусственный_интеллект #учебный_процесс_в_it

Flutter-дайджест: март 2026

Март выдался… немного тише, чем февраль . Без громких релизов уровня Flutter 3.x — но это не значит, что было скучно 😉 Наоборот — месяц получился про практику, реальные кейсы и прокачку навыков 💪 А ещё… несмотря ни на что — мы продолжаем работать. Да, даже несмотря на блокировки Telegram — ❌ мы никуда не уходим ❌ в MAX не переезжаем ✅ и продолжаем делать лучший Flutter-контент для вас 👉 Подписка на канал сейчас — это реальная поддержка проекта ❤️ https://t.me/flutterpulse

https://habr.com/ru/articles/1018402/

#разработка_мобильных_приложений #управление_разработкой #проектирование_и_рефакторинг #качество_кода #тестирование_мобильных_приложений #облачные_сервисы #вебразработка #open_source #искусственный_интеллект #учебный_процесс_в_it

Flutter-дайджест: март 2026

Март выдался… немного тише, чем февраль . Без громких релизов уровня Flutter 3.x — но это не значит, что было скучно 😉 Наоборот — месяц получился про практику, реальные кейсы и прокачку навыков 💪 А ещё… несмотря ни на что — мы продолжаем работать. Да, даже несмотря на блокировки Telegram — ❌ мы никуда не уходим ❌ в MAX не переезжаем ✅ и продолжаем делать лучший Flutter-контент для вас 👉 Подписка на канал сейчас — это реальная поддержка проекта ❤️ https://t.me/flutterpulse

https://habr.com/ru/articles/1018402/

#разработка_мобильных_приложений #управление_разработкой #проектирование_и_рефакторинг #качество_кода #тестирование_мобильных_приложений #облачные_сервисы #вебразработка #open_source #искусственный_интеллект #учебный_процесс_в_it

[Перевод] Энди Хант «Говори, а не спрашивай»

В своем кратком тексте 1998 года Энди Хант, отталкиваясь от закона Деметры и принципа разделения команд и запросов, просто и понятно излагает один из важных принципов объектно-ориентированного проектирования — «говори, а не спрашивай». Этот принцип учит делегировать объектам ответственность за их данные, что позволяет создавать слабосвязанные и устойчивые к изменениям системы.

https://habr.com/ru/articles/990790/

#история_it #ооп #проектирование_и_рефакторинг #java #eiffel

Паттерны ООП c примерами на Java: порождающие шаблоны

Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на Java, приближёнными к реальным. Всем нам хочется делать больше и тратить на это меньше времени. Браться за новые задачи смелее и выполнять их эффективнее. В этом нам и помогают паттерны: они дают рабочую схему для типовых кейсов, чтобы не выдумывать решение каждый раз с чистого листа. Шаблонизироваться

https://habr.com/ru/companies/ruvds/articles/955604/

#java #ruvds_статьи #паттерны_проектирования #gof #kotlin #javaразработка #ооп #проектирование_и_рефакторинг #проектирование_систем

[Перевод] Карл Либерхер, Иэн Холланд «Обеспечение хорошего стиля объектно-ориентированных программ»

Наверное, каждый программист, работавший с объектно-ориентированными языками, хотя бы раз слышал о законе Деметры. Многие знают его смысл, но мало кто читал оригинальный текст 1989 года, где закон был не только сформулирован, но и подробно обоснован. В этой статье авторы, Карл Либерхер и Иэн Холланд, рассказывают о проекте «Деметра», дают строгие формулировки для разных языков и обсуждают, когда законом можно пренебречь.

https://habr.com/ru/articles/975956/

#ооп #история_it #проектирование_и_рефакторинг #с++ #lisp

Делаем нативное мобильное приложение с ИИ и бэкендом (Туториал)

В этой статье мы рассмотрим тонкости создания Proof of Concept (PoC) мобильного приложения, построенного с помощью фреймворка SwiftUI и бэкенда с использованием FastAPI и OpenAI API. Дополнительно я продемонстрирую эффективные архитектурные паттерны для SwiftUI-приложений, в частности MVVMP в сочетании с принципами SOLID и Dependency Injection (DI). Для андроид код можно легко перевести на Kotlin с помощью Jetpack Compose Framework.

https://habr.com/ru/articles/816345/

#мобильная_разработка #swiftui #разработка_на_андроид #искусственный_интеллект #туториал #открытый_код #совершенный_код #проектирование_и_рефакторинг #разработка #принципы_проектирования

Диаграмма классов (англ. Class diagram)

Каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На этом пути будут поджидать множество сложных вопросов, от решения которых зависит успех. Неверные ответы могут значительно усложнить проект, а правильные сделать эту дорогу легкой. Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования). В качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы. Проектируемая программа не только позволит читать книги, но и делать их конспекты, цитируя и добавляя собственные комментарии. ------------- Текущая статья завершает цикл статей по теме проектирования. Ниже описывается, пожалуй, самый трудный этап. Переход от абстрактных рассуждений к конкретной реализации в виде исходного кода. Сложность заключается, в необходимости иметь значительные знания по теории программирования и опыта разработки программного обеспечения, и эти два пункта тесно связаны между собой. Теоретические основы описывают, как и почему необходимо применять тот или иной приём проектирования, а практические навыки позволяют принимать правильные решения, снижая количество допущенных ошибок. Настоящая статья описывает последовательность действий и разъясняет, почему были приняты те или иные решения. Однако, к сожалению, формат статьи не может вместить всё разнообразие вариантов и подходов к проектированию, и поэтому не является инструкцией. Она скорее послужит небольшим примером, для того чтобы самому попробовать разобраться в этой теме.

https://habr.com/ru/articles/907820/

#проектирование #проектирование_систем #проектирование_по #проектирование_и_рефакторинг

Диаграмма последовательности (англ. Sequence diagrams)

Каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На этом пути будут поджидать множество сложных вопросов, от решения которых зависит успех. Неверные ответы могут значительно усложнить проект, а правильные сделать эту дорогу легкой. Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования). В качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы. Проектируемая программа не только позволит читать книги, но и делать их конспекты, цитируя и добавляя собственные комментарии. ------------- В настоящей статье будет описано применение диаграммы последовательности как промежуточного этапа между предшествующими диаграммами, которые в большей степени служили для согласования и оптимизации бизнес-процессов, и сугубо техническими, описывающими построение программного продукта. На мой взгляд, диаграмма последовательности является самой недооцененной диаграммой из всего набора диаграмм UML. В основном, разработчики используют ее для моделирования сетевых или меж платформенных соединений, то есть внешних по отношению к разрабатываемому продукту, однако область ее применения значительно шире. В бизнесе, подобные используются для описания последовательности действий, движения товаров, информации и документов, то есть хорошо иллюстрируют документооборот компаний. В этой статье мы рассмотрим как с помощью такой диаграммы можно выстраивать внутреннюю структуру приложения.

https://habr.com/ru/articles/907816/

#проектирование #проектирование_систем #проектирование_по #проектирование_и_рефакторинг

Диаграмма Деятельности и Диаграмма Состояний (англ. Activity diagram & State machine diagram)

Каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На этом пути будут поджидать множество сложных вопросов, от решения которых зависит успех. Неверные ответы могут значительно усложнить проект, а правильные сделать эту дорогу легкой. Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования). В качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы. Проектируемая программа не только позволит читать книги, но и делать их конспекты, цитируя и добавляя собственные комментарии. ------------- Те кто читал предшествующие статьи, не удивится утверждению, что проектирование начинается с маркетинга. Даже если программа заказана в рамках одного предприятия, подход описанный в книгах о маркетинге поможет сделать первые шаги в правильном направлении. Программы пишутся для пользователей, и никакие прорывные или модные IT технологии не сделают её удачной. Приложение должно решать проблемы пользователя, делая его жизнь проще. Рассматриваемые в данной статье диаграммы Деятельности и Состояний, показывают, действительно ли вы проектируете, что-то ценное или просто повторяете существующий порядок вещей. Как и в предыдущем случае, проектирование с помощью этих диаграмма начинается не с пустого места. Диаграмма Прецедентов разделила планируемый функционал на отдельные модули, и теперь, можно приступить к описанию того как они будут работать.

https://habr.com/ru/articles/907808/

#проектирование #проектирование_систем #проектирование_и_рефакторинг #проектирование_по

Диаграмма Прецедентов (англ. Use Case Diagram)

Конечно, каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На пути будут поджидать множество сложных вопросов, неверные ответы на которые, могут значительно усложнить проект или вообще завести вас в тупик. Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования). В качестве сквозного примера для всего цикла статей будет идея создать библиотеку электронных книг для обучения и научной работы. Выбор книги из каталога. Чтение электронного текста. Возможность создания конспекта книги, как набора цитат и собственных комментариев. Сохранение рабочего пространства и загрузка его при входе.

https://habr.com/ru/articles/907804/

#проектирование #проектирование_систем #проектирование_и_рефакторинг #проектирование_по

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

Книга: «Математика и архитектура глубокого обучения»

Привет, Хаброжители! Узнайте, что происходит внутри черного ящика! Для использования глубокого обучения вам придется подготовить данные, выбрать правильную модель, обучить ее, оценить качество и точность и предусмотреть обработку неопределенности и изменчивости в выходных данных развернутого решения. Эта книга шаг за шагом знакомит с основными математическими концепциями, которые пригодятся вам как специалисту по данным, – с векторным исчислением, линейной алгеброй и байесовским выводом, представляя их с точки зрения глубокого обучения.

https://habr.com/ru/companies/piter/articles/957226/

#книга #глубокое_обучение #проектирование_и_рефакторинг

Мультиплексирование: от основ до сложных сценариев

Мультиплексирование — это технология, позволяющая передавать несколько независимых потоков данных через одно физическое соединение. Представьте официанта в ресторане, который несёт один поднос с заказами для десяти разных столиков, вместо того чтобы делать десять отдельных ходок.

https://habr.com/ru/articles/979818/

#веб_разработка #программирование #мультиплексирование #frontend #backend #проектирование_и_рефакторинг

«Верните всё как было», или Как большие корпорации делают редизайн

На сайт Альфа-Банка заходят миллионы посетителей. Кто-то оформит карту или кредит сразу, кто-то пойдёт сравнивать предложения на сайты других банков. Дизайн продаёт продукт и доносит ценность пользователю. Но как визуально выделиться, если за несколько лет дизайн раскопировали конкуренты? В конце 2022 года мы взялись за редизайн. Получилось ли у нас, а главное — как вам подстелить соломку уже на старте проекта, расскажу в статье. Будет интересно не только дизайнерам, но и продактам, UX-исследователям и всем, кто собирал правки дизайна в десятки итераций.

https://habr.com/ru/companies/alfa/articles/803301/

#редизайн_сайта #прототипы #конверсия_сайта #советы_дизайнерам #исследование_пользователей #метрики_сайта #тепловая_карта_сайта #сайты_банков #концепт_сайта #проектирование_и_рефакторинг

Архитектура фронтенд-приложений на React. (Нам не нужен FSD)

Всем привет, меня зовут Павел Рожков, я lead фронтенда в компании

https://habr.com/ru/companies/doubletapp/articles/870236/

#react #архитектура #архитектура_фронтенда #архитектурный_гайдлайн #fsd #разработка #разработка_приложений #разработка_сайтов #проектирование_и_рефакторинг #методология_разработки

«Верните всё как было», или Как большие корпорации делают редизайн

На сайт Альфа-Банка заходят миллионы посетителей. Кто-то оформит карту или кредит сразу, кто-то пойдёт сравнивать предложения на сайты других банков. Дизайн продаёт продукт и доносит ценность пользователю. Но как визуально выделиться, если за несколько лет дизайн раскопировали конкуренты? В конце 2022 года мы взялись за редизайн. Получилось ли у нас, а главное — как вам подстелить соломку уже на старте проекта, расскажу в статье. Будет интересно не только дизайнерам, но и продактам, UX-исследователям и всем, кто собирал правки дизайна в десятки итераций.

https://habr.com/ru/companies/alfa/articles/803301/

#редизайн_сайта #прототипы #конверсия_сайта #советы_дизайнерам #исследование_пользователей #метрики_сайта #тепловая_карта_сайта #сайты_банков #концепт_сайта #проектирование_и_рефакторинг

«Верните всё как было», или Как большие корпорации делают редизайн

На сайт Альфа-Банка заходят миллионы посетителей. Кто-то оформит карту или кредит сразу, кто-то пойдёт сравнивать предложения на сайты других банков. Дизайн продаёт продукт и доносит ценность пользователю. Но как визуально выделиться, если за несколько лет дизайн раскопировали конкуренты? В конце 2022 года мы взялись за редизайн. Получилось ли у нас, а главное — как вам подстелить соломку уже на старте проекта, расскажу в статье. Будет интересно не только дизайнерам, но и продактам, UX-исследователям и всем, кто собирал правки дизайна в десятки итераций.

https://habr.com/ru/companies/alfa/articles/803301/

#редизайн_сайта #прототипы #конверсия_сайта #советы_дизайнерам #исследование_пользователей #метрики_сайта #тепловая_карта_сайта #сайты_банков #концепт_сайта #проектирование_и_рефакторинг

Паттерны ООП c примерами на Java: порождающие шаблоны

Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на Java, приближёнными к реальным. Всем нам хочется делать больше и тратить на это меньше времени. Браться за новые задачи смелее и выполнять их эффективнее. В этом нам и помогают паттерны: они дают рабочую схему для типовых кейсов, чтобы не выдумывать решение каждый раз с чистого листа. Шаблонизироваться

https://habr.com/ru/companies/ruvds/articles/955604/

#java #ruvds_статьи #паттерны_проектирования #gof #kotlin #javaразработка #ооп #проектирование_и_рефакторинг #проектирование_систем

Паттерны ООП c примерами на Java: порождающие шаблоны

Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на Java, приближёнными к реальным. Всем нам хочется делать больше и тратить на это меньше времени. Браться за новые задачи смелее и выполнять их эффективнее. В этом нам и помогают паттерны: они дают рабочую схему для типовых кейсов, чтобы не выдумывать решение каждый раз с чистого листа. Шаблонизироваться

https://habr.com/ru/companies/ruvds/articles/955604/

#java #ruvds_статьи #паттерны_проектирования #gof #kotlin #javaразработка #ооп #проектирование_и_рефакторинг #проектирование_систем

Паттерны ООП c примерами на Java: порождающие шаблоны

Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на Java, приближёнными к реальным. Всем нам хочется делать больше и тратить на это меньше времени. Браться за новые задачи смелее и выполнять их эффективнее. В этом нам и помогают паттерны: они дают рабочую схему для типовых кейсов, чтобы не выдумывать решение каждый раз с чистого листа. Шаблонизироваться

https://habr.com/ru/companies/ruvds/articles/955604/

#java #ruvds_статьи #паттерны_проектирования #gof #kotlin #javaразработка #ооп #проектирование_и_рефакторинг #проектирование_систем

[Перевод] Невидимые загрузки или о пользе свободно стоящих функций

Довольно долго я тягался с по-настоящему глупой проблемой на C++: мне не нравятся функции экземпляров, но я вынужден их писать, чтобы программисту было хоть немного удобнее работать. Функции экземпляров обеспечивают две вещи: разграничение областей видимости и обнаружимость. Разграничение областей видимости — менее актуальная из этих задач, поскольку в моём коде на C++ я и так не использую модификаторы private/public. Обнаружимость — большая проблема: я могу написать x.F , а IDE предложит x.Func() . Отлично! «Но правильные программисты пользуются только vim и скромными IDE». Что ж, привет вам, воображаемые мифические обычные программеры. Здесь вам ничего не угрожает, но, пожалуйста, уходя — надевайте сразу два беджика: «vim отстой» и «Я ненавижу emacs». Отлично помогает завязать разговор с «настоящими» программистами.

https://habr.com/ru/companies/piter/articles/931010/

#c++ #компиляторы #проектирование_и_рефакторинг #профессиональная_литература

[Перевод] Дэвид Л. Парнас «О критериях для разбиения систем на модули»

Статья Парнаса «О критериях...» давно стала классикой, которую постоянно цитируют, но мало кто реально читает. Высказанные в ней идеи о «сокрытии информации» как основе модульности упоминаются повсеместно, однако оригинальный текст с его тщательной аргументацией и яркими примерами остается для многих терра инкогнита. Данный перевод призван восполнить этот пробел.

https://habr.com/ru/articles/957968/

#история_it #проектирование #проектирование_и_рефакторинг

[Перевод] Обзор книги «Паттерны разработки на Python TDD, DDD и событийно-ориентированная архитектура»

Недавно я прочёл книгу « Паттерны разработки на Python TDD, DDD и событийно-ориентированная архитектура ». Основной акцент в ней сделан на том, как именно нужно структурировать программы, чтобы они по мере роста оставались простыми и удобными в поддержке. Это моя любимая тема из области программирования, поэтому, конечно же, книга мне понравилась. Пожалуй, я не возьмусь использовать именно те приёмы, которые авторы рекомендуют в книге — но они обсуждают классные идеи, напомнившие мне о задачах, встречавшихся в моей практике на предыдущих работах. Кроме того, отмечу, что английская версия книги есть в свободном доступе онлайн , так какие вообще вопросы? В книге рассматривается предметно-ориентированное проектирование и событийно-ориентированная архитектура (в основу которой удобно закладывать микросервисы, но это не обязательно). В этом посте я немного раскрою наиболее понравившиеся мне идеи из книги, но, прежде, чем переходить к этому, хочу артикулировать некоторые детали:

https://habr.com/ru/companies/piter/articles/940566/

#проектирование_и_рефакторинг #ооп #python #перевод

[Перевод] Профессиональная обработка ошибок в TypeScript

Ошибки происходят в любом приложении. Говоря об ошибках, первым делом отметим, что все они делятся на два типа: ожидаемые ошибки, обусловленные бизнес-логикой, и неожиданные ошибки. Это различие очень важное, поскольку стратегии обработки ошибок первого и второго типа значительно отличаются. Ожидаемые ошибки, связанные с бизнес-логикой — это «нормальная» часть эксплуатации системы. О таких ошибках в системе должно быть заранее известно пользователям, а вы должны быть способны эти ошибки исправлять, если они возникнут. Пример ожидаемой ошибки, обусловленной бизнес-логикой — попытка получить объект из хранилища больших неструктурированных данных (blob storage) с последующей необходимостью обработать случай «объект не найден». Другой пример связан с регистрацией пользователя, когда клиент пытается взять себе логин, который уже занят. В принципе, это ожидаемая ситуация и, если она произойдёт, мы вернем пользователю качественное сообщение об ошибке. Неожиданные ошибки — такие, которые можно себе представить, но просто их не ожидаешь в условиях нормальной эксплуатации системы. Теоретически, можно было бы попробовать смоделировать все возможные ошибки, но это титаническая работа, сама по себе не слишком полезная. Как правило, не существует способов качественно обрабатывать такие ошибки или как следует после них восстанавливаться.

https://habr.com/ru/companies/piter/articles/935278/

#javascript #typescript #проектирование_и_рефакторинг

Как эволюционировали архитектурные паттерны и как они будут развиваться дальше

Если вспомнить, что мы проходили в архитектуре за последние десятилетия, вырисовывается любопытная картина. Сначала были монолиты и мэйнфреймы, затем — двух- и трехзвенные архитектуры. Не так давно все активно занимались распиливанием монолита на микросервисы, массово внедряли CQRS. Казалось, нащупан стабильный путь развития. Но что дальше? Как раз об этом сегодняшняя публикация. Мы подготовили ее на основе доклада на True Tech Day от Олега Ивлева — директора по развитию технологий, и Марина Путниковича — руководителя центра практик «Архитектура» в МТС Web Services. Надеемся, получилось интересно!

https://habr.com/ru/companies/ru_mts/articles/933066/

#архитектура #truetechday #архитектурные_паттерны #сервисы #микросервисы #проектирование_и_рефакторинг

Проектирование: Начало

Конечно, каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На пути будут поджидать множество сложных вопросов, неверные ответы, поиск оптимальных решений, принятие компромиссных решений, все это значительно усложняет проект или вообще может завести вас в тупик. Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language) — унифицированный язык моделирования. Статья которую вы читаете в данный момент, описывает начальное положение в проекте, когда есть только идея и большое желание создать программный продукт. Именно в этот момент принимается большинство решений ограничивающих наш выбор в дальнейшем. Чтобы исправить это, помочь разработчикам принимать более взвешенные решения и начат текущий цикл статей. Вообще-то в статье не описаны какие-то уникальные знания. Все приемы известны давно и упоминаются в различной литературе. Просто в статьи будут включены те, которые принесли максимальную пользу при практической работе над различными проектами. Стоит упомянуть, что большинство завершенных проектов выполнялись по заказу от бизнес партнеров, но и те которые делались для свободного использования не выходят за рамки описываемого. Итак, в качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы. Привычные действия при работе с электронной книгой сводятся к загрузке книги на локальный носитель и дальнейшая работа с ней в специализированной программе. Однако, если вы работаете с такой программой, и желаете создать конспект книги, вы столкнетесь с множеством ограничений.

https://habr.com/ru/articles/907794/

#проектирование_систем #проектирование #проектирование_и_рефакторинг

Обзор популярных методологий для аналитики и для архитектуры

Аналитические и архитектурные методологии помогают структурировать процессы анализа данных, проектирования систем и разработки решений. Они используются для повышения эффективности, снижения рисков и обеспечения качества результатов.

https://habr.com/ru/articles/892068/

#tutorial #architecture #анализ_и_проектирование_систем #архитектура #аналитика #system_design #системный_анализ #бизнесанализ #проектирование_и_рефакторинг

Как ускорить загрузку сайта: гайд для разработчиков

Привет! Меня зовут Руслан, и я работаю React-разработчиком в компании SimbirSoft. На одном из моих проектов я столкнулся с проблемой низкой производительности сайта, которую нужно было решить быстро и с минимальными затратами ресурсов. В этой статье я хочу рассказать о том, почему важна производительность сайта и зачем её нужно улучшать, а также поделиться несколькими способами увеличения скорости загрузки веб-страниц.

https://habr.com/ru/companies/simbirsoft/articles/883090/

#вебразработка #javascript #высокая_производительность #программирование #проектирование_и_рефакторинг