Проектирование и рефакторинг *

Конечно, каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На пути будут поджидать множество сложных вопросов, неверные ответы на которые, могут значительно усложнить проект или вообще завести вас в тупик.

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

В качестве сквозного примера для всего цикла статей будет идея создать библиотеку электронных книг для обучения и научной работы. Выбор книги из каталога. Чтение электронного текста. Возможность создания конспекта книги, как набора цитат и собственных комментариев. Сохранение рабочего пространства и загрузка его при входе.

1. Руководители жалуются на недостаточно высокую скорость разработки. "Я просто хочу показывать день рождения пользователя на странице настроек. Почему на это уходит целый год?"
2. Инженеры говорят, что техдолг мешает им двигаться вперед.
3. Руководство поручает менеджерам «разобраться с техдолгом», чтобы повысить скорость разработки.
4. Менеджеры начинают искать крупные проекты с технологическим долгом, чтобы добавить их в роадмап

Статей по теме, в том числе с примерами «потенциально плохого» кода, написано довольно много — в том числе и на Хабре. Мы в beeline cloud решили посмотреть, что на этот счет говорят научные работы и подтверждают ли они актуальность проблемы.

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

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

К написанию этой статьи меня подтолкнуло изучение архитектурных подходов для Vue.js-проектов, а вдохновила - детально описанная методология Feature-Sliced Design.

К сожалению, PHP-сообществу не хватает подобных развернутых рекомендаций, да и вообще, каких-то общепризнанных стандартных подходов в структуре проекта.

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

Системный аналитик как термин в США почти не используется. Если вы просто наберёте "System Analyst", то в 9 из 10 случаев увидите совсем не то. Либо вакансии из финансового сектора, либо вообще нечто около-административное.

Так кто же тогда делает ту работу, которую в России выполняет системный аналитик?

Спросил свою 3070ti «Как думаешь, что важнее – процесс или результат?», а он мне отвечает, чтобы я сам выбирал. И зачем эти нейросети, если они даже не могут выбрать, что для меня важнее и лучше…

Конечно, каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На пути будут поджидать множество сложных вопросов, неверные ответы, поиск оптимальных решений, принятие компромиссных решений, все это значительно усложняет проект или вообще может завести вас в тупик.

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

Статья которую вы читаете в данный момент, описывает начальное положение в проекте, когда есть только идея и большое желание создать программный продукт. Именно в этот момент принимается большинство решений ограничивающих наш выбор в дальнейшем. Чтобы исправить это, помочь разработчикам принимать более взвешенные решения и начат текущий цикл статей. Вообще-то в статье не описаны какие-то уникальные знания. Все приемы известны давно и упоминаются в различной литературе. Просто в статьи будут включены те, которые принесли максимальную пользу при практической работе над различными проектами. Стоит упомянуть, что большинство завершенных проектов выполнялись по заказу от бизнес партнеров, но и те которые делались для свободного использования не выходят за рамки описываемого.

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

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

Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.

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

Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.

В этой статье я хочу поделиться своим взглядом на то, как каждый из принципов SOLID может быть применен в разработке React-приложений. Здесь не будет революционных идей, особенно для опытных разработчиков, но, возможно, эта информация окажется полезной для начинающих разработчиков, стремящихся писать более качественный и поддерживаемый код.

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Здравствуйте, меня зовут Дмитрий Карловский и я.. придерживаюсь следующей парадигмы мышления: всякое определение должно иметь чёткую границу между тем, что ему соответствует, и тем, что не соответствует.

К сожалению, часто можно встретить споры о пересекающихся определениях, словно они взаимоисключают друг друга. Не менее часто можно встретить ложную дилемму между двумя терминами не покрывающими всё множество сущностей.

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

Представьте: в компании работает Алексей — senior-разработчик, который за пять лет стал незаменимым. Он знает каждый уголок legacy-кода, помнит, почему десять лет назад выбрали именно эту базу данных, и умеет чинить критические баги за минуты. Но Алексей увольняется. Руководство в панике: как передать его опыт? Проводят митинги, заставляют его записать всё в Confluence, а через месяц новый разработчик смотрит на эти документы и не понимает ни строчки. Знания Алексея ушли вместе с ним, а компания теряет клиентов из-за растущих багов.

Рассказываю чем заменить Swashbuckle, который убрали из .Net 9, для создания страницы похожей на Swagger UI.

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

Многие из этих ошибок происходят не на уровне кода, а гораздо раньше - в момент, когда аналитик формулирует требования. Непродуманная логика, отсутствие контракта, игнорирование сбоев - всё это закладывает возможную нестабильность в сам фундамент архитектуры.

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

Не поверхностно, а с разбором боевых кейсов, с примерами и выводами, которые можно вполне себе использовать, как чек-лист. Чтож! Щас выскажусь!)

И это решит 95% проблем типичного стартапа. Как-то так повелось, что по всему СНГ и его окрестностям на работу набирают зумеров с колоссальным опытом в три года, и они начинают создавать идеальные архитектуры. Да, каждый из вас, как только получает возможность взять на себя хоть малейшую ответственность, сразу вспоминает все прочитанные и не прочитанные книги и пилит свою уникальную архитектуру, непохожую ни на что.

В предыдущей статье я попросил — «Расскажите, зачем вам DI‑контейнер в golang». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода. Получается, мы все таки «тащим» Di‑контейнер в проект. Ну, хорошо....

Вероятно, это будет uber‑fx, ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»?

Мой ответ — нет, uber‑fx не «тащим», потому что можно еще проще и понятнее.

В статье обсудим антипаттерн Primitive obsession, разберём на примерах способы его устранения в разных языках программирования.

Если вы считаете, что принципы SOLID — это что-то из учебника по ООП и к вашему проекту они не имеют отношения, у меня для вас плохие новости. Так думали и мы, пока один «божественный» класс не положил прод на сутки. А всё потому, что его писали с мыслью «зачем разбивать, всё и так работает».

В этой статье — без академической воды: как SOLID спасает архитектуру, ускоряет команду и помогает не утонуть в легаси. С примерами, с типичными фейлами и с тем, что действительно работает в продакшене.

Я старый фуллстек-разработчик и не знаю слов любви, но около полугода назад при очередной итерации сервера почувствовал себя утомленным путником, который узрел нежную красоту wr-обработчика нативного net/http! Вот раньше всё было ужасно - а теперь красиво, приятно читать и интересно показать! За несколько месяцев я переделал свои сотни обработчиков на новый стиль - и всё еще доволен! Почистил авгиевы конюшни слоев логики - теперь там царит запах фиалок! Также у меня была возможность посмотреть как пилят http профессионалы бэкенда - далеко не как фуллстеки, о чем тоже хочется рассказать!
Для ленивых читать - пора вернуть логику в обработчики! Но я расскажу подробно о той красоте, которая скрывается за этими многими восклицательными знаками, и о том, как её можно испортить. Структура такова:
- сначала чем фуллстек отличается от нативного бэкенда,
- потом пройдемся по API-стилю а-ля РЕСТ,
- прочтем оду нативному http-модулю, расковыряем пару болячек фреймворков,
- почитаем мои слова, почему wr-обработчик хорош сразу из коробки,
- и посмотрим пример того, как превратить обработчик в простой вид "задача-дано-решение-ответ".

Внимание, это мнение. В статье поднимаю холиварные темы, при этом я могу быть не прав, но буду настаивать! И фотка из личного фотоархива на тему "Люблю лето!", потому что уже надоели сгенерированные картинки.