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

Изначально этот материал планировался как урок в PHP-курсе по полиморфизму. Но он, в конце концов, перерос сам урок, и я решил сделать из него отдельную статью. В ней практически ничего PHP-специфичного, поэтому рекомендуется для прочтения всем без исключения.

Напомню, что модель классов PHP взята из Java. Наличие интерфейсов и всех сопутствующих элементов очень сильно влияет на способ организации кода в PHP. Этот способ часто отличается от того, как организуется код в JavaScript, Ruby или Python. И ещё больше отличается от таких языков, как Clojure или Elixir. И всё это на фоне того, что в каждом из этих языков есть ООП.

ООП в этих языках настолько разное, что PHP-программисты, попадающие в Ruby или JavaScript, не понимают, как так можно писать, ведь многие подходы противоречат их представлениям о мире. То же самое происходит и в обратной ситуации.

Так где же правда? Правда в том, что есть вещи, которые действительно определяют архитектуру кода. И это не структура классов, не наличие интерфейсов и не использование полиморфизма.

Возьмём тот же MVC. В нём говорится о слоях, об их задачах (зонах ответственности) и способе взаимодействия друг с другом. Это крайне важно для модульности. В модульной системе отсутствуют циклические зависимости. В MVC ничего не говорится про классы и ООП в целом, потому что между этими понятиями нет связи. Реализовать MVC можно в любом языке общего назначения, каким бы он ни был. То же самое можно сказать обо всех других архитектурных шаблонах.

Архитектура опирается на особенности среды, в рамках которой она применяется, а не на конструкции языка. Например, в вебе господствует HTTP, который построен вокруг концепции "запрос-ответ". Именно поэтому микрофреймворки разных языков выглядят так похоже, независимо от того, есть там ООП или нет: в каждом микрофреймворке есть запрос, ответ и обработчик ответа.

Подробнее о разработке я пишу в своем телеграм-канале организованное программирование. Присоединяйтесь если статья понравилась :)

О, таблица merchants2? Да, у нас закончились столбцы в merchants, поэтому мы сделали merchants2.

Привет, хабравчане!

В серии статей расскажу, что такое DDD (domain-driven design) и какие у него преимущества и недостатки. Разберемся, когда применять подход и как сочетать его с FastAPI, популярным ASGI фреймворком на Python.

В этой части рассмотрим паттерны проектирования Repository и Unit of Work. С их помощью мы работаем через интерфейсы. Паттерны помогают в разделении кода на слои: основная логика приложения представляется внутренними слоями, а используемые технологии - внешними.

Я прочитал замечательную статью за авторством @rplacroixи загорелся идеей воплотить механики окружающей среды, подобные линейке игр Divinity: разлитую нефть можно поджечь, огонь можно потушить водой, а яд неожиданно взрывается от огня. Здесь я буду больше обращать внимание на реализацию в коде, чем на достоверную копию механик из игр Divinity. Я покажу некоторые кусочки кода с пояснениями, а в конце будет небольшая демонстрация прототипа игры с этой системой.

Сегодня я программирую на Raku. Raku — это молодой язык с длинной историей, сестринский язык к языку Perl. Я хочу продемонстрировать самые сильные стороны этого языка в контексте прототипирования игры и частично сравнить их с оригинальной статьей, языком имплементации которой был выбран Python. В течение статьи я буду оставлять раскрывающиеся блоки с объяснением тех или иных особенностей языка Raku, если вам интересно.

Всем привет! Меня зовут Дмитрий, я Frontend-разработчик в VK. В этой статье расскажу немного о том, как мы знакомились с замечательной архитектурой FSD (Feature-Sliced Design), как мы рефакторили свои проекты под неё. И, самое главное, что  из этого вышло. Постараюсь заинтересовать  вас, чтобы и вы смело её внедряли в свои проекты. FSD — это, пожалуй, то, чего так не хватало в Frontend-мире.

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

Подход к задачам

• Разные задачи, проекты и команды требуют разных подходов. Например, сделать пейсмейкер без автоматических тестов было бы безответственным решением – кто-то может от этого пострадать. И вместе с тем, глупо изводиться по поводу автоматических тестов на геймджеме, куда вы отправились на выходных. Содержание понятия «хороший код» меняется в зависимости от контекста, и нужно адаптировать свой подход под конкретную ситуацию.
• Делайте марш-броски. Бывает, что я ставлю себе цель довести какую-то функциональность до готовности в кратчайшие сроки, пусть даже срезая углы где только можно, с кодом ужасного качества и TODO на каждом шагу. Когда у меня появится что-то рабочее, тогда и буду приводить всё в должный вид. Я пришел к выводу, что это хороший способ обозначить для себя проблемные зоны, а также неплохой путь к ускорению процесса разработки. На эту тему есть статья «Выбросьте первый набросок кода».
• Если я бьюсь головой об задачу и никак не могу сдвинуться с мертвой точки, значит, необходимо оторваться от нее на какое-то время.
• Прежде чем начать работу над сложной задачей, я задаю себе вопрос: «А что если вообще этого не делать?» Как правило, вопрос оказывается глупым и выполнять задачу все-таки приходится. Но примерно в пяти процентах случаев я осознаю, что определенную часть работы можно спокойно пропустить.

Недавно попробовали со своим проектом пройти на акселератор. Создали еще давно очень простое решение: "Разработка отечественной платформы Умного дома и Интернета вещей на базе платы ESP32, а также создание соответствующего образовательного курса"

Если кому интересно, здесь актуальная информация.

Проектом заинтересовались в НТИ, понаслышке я слышал, что это дает: отобранные проекты, которые получат хорошие баллы на демо дне, получат субсидию из средств, которыми финансируется НКО организаторов. Нас пригласили в акселератор в рамках программы Архипелаг.

Если преакселерацию с другим проектом мы проходили раньше за 2 недели, а понаслышке я знаю, что в акселераторе могут готовить и месяцами, то здесь сроки были суперсжатые. Когда я получил приглашение по почте, то понял, что где-то уже полторы недели и остается. Я начал со сбора команды, ибо был бардак. Я наивно предполагал, что в такие сроки мы успеем собрать всех, кто заинтересовался на странице проекта какой-либо информацией. Пока я собирал контакты и всем писал, я параллельно привлекал команду из уже знакомых людей, с которыми мы сработались.

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

Техники оптимизации функции авторизации в современных веб-приложениях.

В статье рассматриваются эффективные подходы к управлению точной авторизацией с использованием Amazon Verified Permissions (читай Cedar Engine). Вы узнаете о техниках пакетной авторизации и кэширования ответов, которые помогут значительно повысить производительность и отзывчивость приложений.

Часто задается вопрос: как эффективно и быстро обработать огромные объемы информации? Ответом на этот вызов стала концепция MapReduce, разработанная в недрах Google.

MapReduce — это парадигма программирования, созданная для обработки и генерации больших объемов данных с использованием параллельных распределенных алгоритмов. Основная фича проста: сначала данные разбиваются на небольшие части (фаза Map), а затем результаты этих частей агрегируются в финальный результат (фаза Reduce).

За последние три года размер данных Notion увеличился в 10 раз из‑за роста количества пользователей и объёмов контента, с которым они работают. Удвоение этого показателя происходило каждые 6–12 месяцев. Нам нужно было справиться со стремительным ростом размеров данных, соответствуя при этом постоянно растущим требованиям, которые выдвигали критически важные сценарии использования наших продуктов и аналитических систем. Особенно это справедливо в применении к новым функциям Notion AI. Для того чтобы решить эти задачи нам нужно было создать озеро данных Notion и обеспечить его масштабирование. Вот как мы это сделали.

• “Я дважды проверил код”
• “Код прошел тесты”
• “Ревьюер одобрил мой код”

• Универсальность: Даже если ваш код работает правильно один раз, будет ли он работать так во всех случаях, на всех машинах, во всех ситуациях?
• Ложноположительные результаты: Неудачные тесты указывают на наличие ошибок, но пройденные тесты не обещают их отсутствия.
• Отсутствие уверенности: Вы могли бы написать формальное доказательство корректности вашего кода, но теперь вы должны задаться вопросом, верно ли это доказательство. Вам нужно будет подтвердить доказательство. Эта цепочка проверки доказательств никогда не закончится.

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

Выборы архитектора происходят всегда по‑разному. Это только политиков одинаково выбирают — по принципу лишь бы не этот… А вот с архитекторами везде свой сценарий. Где‑то в половине мест сидят эстеты и предлагают что‑то изобразить да обсудить. Четверть мест явно химики с мензурками в сейфе — спрашивают про правильный код или просят пузырьковую сортировку. Ещё реже циркачи просят пожонглировать стеклянными шариками на башне или погонять трамваи. Остальные просто хотят обсуждения с залом. Как бы намекая, что нельзя вот так просто прийти в училище имени Гнесиных с фамилией Иванов. Кто‑то из гильдии таки должен сказать, что в мальчике что‑то есть.

У нас уже есть пережёванный легаси, набор грабель, методично разложенных под ногами и дальний свет сигнальных огней, к которым надо стремиться. Так что дело за малым — проложить дорогу от кучки легаси до тех самых огней по минному полю из грабель. Это и есть архитектура. Шагать вперёд, сверяться с картой, и быть чародеем.

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

Меня зовут Ерохова Елена и я аналитик.

В моей практике перепроектирование встречалось почти так же часто, как проектирование с нуля.

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

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

Здесь я имею в виду, что «проект» - записанные в документ образ результата прикладного программирования и последовательность этапов по достижению этого результата.

При перепроектировании необходимо создавать новый образ результата и новый план его достижения.

Перепроектирование – это, практически, всегда сложно, затратно и неприятно.

Может быть, можно с самого начала так спроектировать приложение, чтобы потом не перепроектировать его?

Всем привет. Меня зовут Татьяна Цикунова, я работаю системным аналитиком в компании МойСклад, в команде eCommerce. Моя команда специализируется на разработке интеграций сайтов с сервисом МойСклад. Мы помогаем бизнесу автоматизировать процессы: учета, продаж, коммуникаций с клиентами, выход на новые торговые площадки. Также мы разрабатываем интеграции с самыми популярными маркетплейсами на рынке России и зарубежных стран У МоегоСклада уже есть решения для селлеров на Ozon, Wildberries, Яндекс Маркете и Мегамаркете, а также для зарубежных маркетплейсов.

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

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

О проектировании микросервисной архитектуры с использованием фреймворка Single SPA и технологиях, связанных с его использованием.

SaltStack — это целая экосистема, предназначенная для автоматизации сложных процессов и оркестрации множества систем. Сегодня мы рассмотрим, как SaltStack помогает решить задачи оркестрации.