Программисты много говорят про сложность решений. Мы можем часами размышлять о правильных шаблонах, красивых абстракциях и цепочках зависимостей. Однако, давайте поговорим открыто, всегда ли сложность обусловлена решаемой проблемой? Не оказываемся ли мы в плену наших стереотипов и убеждений?
Рубрика «архитектура приложений» - 3
Имитация Сложности — Антиномия Простого и Сложного
2020-03-23 в 19:47, admin, рубрики: Анализ и проектирование систем, архитектура приложений, практика программирования, Программирование, проектирование, Проектирование и рефакторинг, проектирование систем, Промышленное программирование, размышления, сложность, философия программированияFramework vs Platform: в чём разница?
2020-02-23 в 12:01, admin, рубрики: архитектура приложений, инженерия программного обеспечения, качество по, процесс разработки, сложные системы, управление разработкойПривет! Представляю вашему вниманию перевод статьи "Framework Vs. Platform What’s The Difference?" автора G. Harris.
Исповедуюсь: я педант. Несмотря на личные неудачи на этом поприще, я глубоко верю, что использование правильного языка добавляет множество преимуществ. Процитирую афоризм Марка Твена:
Разница между почти правильным словом и правильным словом действительно много значит. Это разница между светлячком (lightning bug) и молнией (lightning).
Ввиду этой разницы я вижу смысл в том, что время от времени меня раздражает недостаток ясности вокруг двух концепций фреймворк и платформа. Какая-нибудь платформа есть у любой компании в мире, которая имеет отношение к разработке. В мире опенсорса полно фреймворков. Но мало кто может определить эти концепции, будучи спрошен. Если я не способен дать чёткие опрделения базовой терминологии, могу ли я претендовать на полное понимание предмета обсуждения?
Я хотел бы предложить одно из возможных определений по аналогии.
Роутинг для iOS: универсальная навигация без переписывания приложения
2020-01-14 в 12:14, admin, рубрики: iOS, swift, архитектура приложений, Блог компании Badoo, разработка мобильных приложений, разработка под iOS, разработка приложений для iosВ любом приложении, состоящем более чем из одного экрана, существует необходимость реализовать навигацию между его компонентами. Казалось бы, это не должно быть проблемой, ведь в UIKit есть достаточно удобные компоненты-контейнеры вроде UINavigationController и UITabBarController, а также гибкие методы модального показа экранов: достаточно использовать нужную навигацию в нужное время.
Однако, как только в приложении появляется переход на какой-то экран по push-уведомлению или ссылке, всё становится несколько сложнее. Сразу появляется масса вопросов:
- что делать с view-контроллером, который сейчас находится на экране?
- как переключить контекст (например, активную вкладку в UITabBarController)?
- есть ли в текущем стеке навигации нужный экран?
- когда следует игнорировать навигацию?
Мы из другого теста — тестируем базу данных на MSTest
2019-12-21 в 17:57, admin, рубрики: .net, C#, core 3.1, ef, mstest, sql, архитектура приложений, Тестирование IT-систем, тестирование приложенийТестирование как универсальный принцип
Уже почти четверь века празднуем миллениум, а тестирование ещё только входит в нашу жизнь… Сложно убедить начинающих разработчиков использовать эту потрясающую технику в своей работе… Да чего уж там говорить о разработчиках, простым смертным и то не всегда доступно понимание того, что тестирование — основа устойчивых систем! Как сложно бывает убедить продавщицу в том, что протестировать новый продукт — не значит съесть его! Даже бывалые охранники явно работают по старинке — пытаются догнать и отобрать тестируемое. И не докажешь им, что если уж сам Господь Бог не гнушается использовать TDD в своей работе (вспомним Великий Потоп), то нам как говорится сам бог велел…
Количество разводов растёт — почему? Да всё потому же! TDD! Сначала тестируй — потом женись! Нет, доверчивые мужички в расхристанных тулупах, падкие на эксплуатирующую секс рекламу, выкатывают молодую жену прямо в продакшн…
Ну мы то с вами из другого теста, сначала тестирование — потом всё остальное!
Я тестировщика узнаю по походке…
И вот когда я начал писать очередную базу данных code first то задумался, а почему бы не сделать автоматическое тестирование своего DAL слоя прямо на встроенных в VisualStudio тестах?
И у меня получилось! Прозрачно для EntityFramework, без всякой ловкости рук под одеялом и мошенничества с fake-объектами. Кому интересно — расчехляем VS, одеваемся как тестировщики и вперёд! (я всегда одеваюсь как тестировщик)

Неопределённая параметризация как универсальный метод построения архитектуры приложения на C++ и Java за минимальн. цену
2019-11-10 в 22:09, admin, рубрики: c++, java, Анализ и проектирование систем, архитектура приложений, ооп, параметризация кода, паттерны приложений, Проектирование и рефакторинг, статическая параметризация, шаблоны c++, шаблоны проектированияC++ — язык запутанный, и существенным его недостатком является сложность создания изолированных блоков кода. В типовом проекте всё зависит от всего. Эта статья показывает, как писать высокоизолированный код, который минимально зависит от конкретных библиотек (включая стандартные), имплементаций, сведя зависимость любого куска кода к набору интерфейсов. Помимо этого будут предложены архитектурные решения по параметризации кода, которые могут заинтересовать не только программистов на C++, но и программистов на Java. И что важно, предложенное решение весьма экономично по времени разработки.
Читать полностью »
История одного монолита. Часть 2
2019-08-28 в 5:38, admin, рубрики: .net, архитектура приложений, Блог компании 2ГИС, Программирование, Проектирование и рефакторингВ прошлой статье я рассказал краткую историю развития внутренних и внешних продуктов компании ДубльГИС. Сегодня погрузимся в детали развития одного из продуктов, а именно экспорта данных. Я расскажу об архитектуре проекта и отдельных технических решениях, которые позволили нам постепенно развивать проект и адаптировать его под меняющиеся с течением времени требования.
Читать полностью »
Управление зависимостями в Python: сравнение подходов
2019-07-26 в 15:33, admin, рубрики: dependency injection, python, uncle bob, архитектура приложений, ооп, Совершенный кодЯ пишу на питоне лет пять, из них последние три года — развиваю собственный проект. Большую часть этого пути мне помогает в этом моя команда. И с каждым релизом, с каждой новой фичей у нас все больше усилий уходит на то, чтобы проект не превращался в месиво из неподдерживаемого кода; мы боремся с циклическими импортами, взаимными зависимостями, выделяем переиспользуемые модули, перестраиваем структуру.
К сожалению, в Python-сообществе нет универсального понятия «хорошей архитектуры», есть только понятие «питоничности», поэтому архитектуру приходится придумывать самим. Под катом — лонгрид с размышлениями об архитектуре и в первую очередь — об управлении зависимостями применимо к Python.
Читать полностью »
Чистая архитектура решения, тесты без моков и как я к этому пришел
2019-07-09 в 16:50, admin, рубрики: .net, api, ASP, asp.net core, C#, архитектура приложений, веб-приложения, Совершенный код, хороший кодЗдравствуйте, дорогие читатели! В этой статье я хочу рассказать об архитектуре своего проекта, который я рефакторил 4 раза на его старте, так как не был удовлетворен результатом. Расскажу о минусах популярных подходов и покажу свой.
Поваренная книга разработчика: DDD-рецепты (5-я часть, Процессы)
2019-06-04 в 13:48, admin, рубрики: clean architecture, domain-driven design, ruby, ruby on rails, Screaming Architecture, UML, uml-проектирование, use cases, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эвансВведение
В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.
Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.
Отделяем функциональные требования от бизнес требований.
Снова и снова случается так, что многие бизнес-идеи на самом деле не превращаются в конечный, намеченный продукт. Зачастую это происходит из-за неспособности понять разницу между бизнес-требованиями и функциональными требованиями, что в конечном итоге, приводит к несоответствующему сбору требований, ненужной документации, задержкам проекта и крупным проектным сбоям.
Или иногда мы сталкиваемся с ситуациями, в которых, хотя окончательное решение отвечает потребностям клиентов, но каким-то образом бизнес-цели не достигаются.
Поэтому крайне важно разделить бизнес-требования и функциональные требования, до того момента, как вы начнете их определять. Давайте разберем пример.
Лучшие практики Node.js — советы по структуре проектов
2019-06-02 в 11:09, admin, рубрики: best practices, javascript, node.js, server-side javascript, архитектура приложений, разработка
Привет! Представляю вашему вниманию адаптированный перевод первой главы "Node.js Best Practices" автора Yoni Goldberg. Подборка рекомендаций по Node.js размещена на github, имеет почти 30 т. звезд, но до сих пор никак не упоминалась на Хабре. Предполагаю, что эта информация будет полезна, как минимум, для новичков.
Читать полностью »