Рубрика «архитектура приложений» - 2

Я 20 лет наслаждаюсь разнообразием архитектур и хочу поделиться мыслями - 1

Сначала хотел написать комментарий к статье "Я десять лет страдал от ужасных архитектур в C#...", но понял две вещи:

  1. Слишком много мыслей, которыми хочется поделиться.
  2. Для такого объёма формат комментария неудобен ни для написания, ни для прочтения.
  3. Давно читаю Хабр, иногда комментирую, но ни разу не писал статей.
  4. Я не силён в нумерованных списках.

Disclaimer: я не критикую @pnovikov или его задумку в целом. Текст качественный (чувствуется опытный редактор), часть мыслей разделяю. Архитектур много, но это нормально (да, звучит как название корейского фильма). 

Однако давайте по порядку. Сначала моё мнение о том, что влияет на архитектуру, потом про спорные моменты в статье об «исправлении архитектур». Ещё расскажу о том, что у нас хорошо работает — может, пригодится кому-нибудь.
Читать полностью »

Я десять лет страдал от ужасных архитектур в C# приложениях — и вот нашел, как их исправить - 1

Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.

Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.

Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.

Читать полностью »

Фрактальная шизофрения - 1

Нет, я не болен. По крайней мере так говорит голос в моей голове. Я наркоман. Вот уже более 15 лет я сижу на игле. Употребляю много, жёстко, до оборочного состояния. Докатился до того, что в последнее время не стесняюсь ни друзей, ни жены, ни детей… Двоих детей! Не люблю бадяженый, люблю чистый, без примесей. За годы перепробовал многое, но в последнее время остановился в поисках. Забавно осознавать, что от одного и того же получаешь одновременно и боль, и радость. Мне бы в лечебку, я даже хочу, я даже знаю в какую. Знаете такие, где продолжаешь употреблять, но под присмотром?

Читать полностью »

Хочу поделиться с вами подходом который я уже много лет использую в разработке приложений, в том числе и веб-приложений. Многим разработчикам настольных, серверных и мобильных приложений этот подход хорошо знаком, т.к. является фундаментальным при построении таких приложений, однако в вебе он представлен очень скудно, хотя желающие использовать такой подход однозначно есть. Кроме того на таком подходе написан редактор VS Code.

Чистая Архитектура

В результате применения этого подхода вы отвяжетесь от конкретного фреймворка. Сможете легко переключать библиотеку представления внутри вашего приложения, например React, Preact, Vue, Mithril без переписывания бизнес логики, а в большинстве случаев даже вьюхи. Если у вас есть приложение на Angular 1, вы без проблем сможете перевести его на Angular 2+, React, Svelte, WebComponents или даже свою библиотеку представления. Если у вас есть приложение на Angular 2+, но нету специалистов для него, то вы без проблем сможете перевести приложение на более популярную библиотеку без переписывания бизнес логики. А в итоге вообще забыть про проблему миграции с фремворка на фреймворк. Что же это за магия такая?
Читать полностью »

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

Имитация Сложности — Антиномия Простого и Сложного - 1

Читать полностью »

Привет! Представляю вашему вниманию перевод статьи "Framework Vs. Platform What’s The Difference?" автора G. Harris.

Исповедуюсь: я педант. Несмотря на личные неудачи на этом поприще, я глубоко верю, что использование правильного языка добавляет множество преимуществ. Процитирую афоризм Марка Твена:

Разница между почти правильным словом и правильным словом действительно много значит. Это разница между светлячком (lightning bug) и молнией (lightning).

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

Я хотел бы предложить одно из возможных определений по аналогии.

Читать полностью »

В любом приложении, состоящем более чем из одного экрана, существует необходимость реализовать навигацию между его компонентами. Казалось бы, это не должно быть проблемой, ведь в UIKit есть достаточно удобные компоненты-контейнеры вроде UINavigationController и UITabBarController, а также гибкие методы модального показа экранов: достаточно использовать нужную навигацию в нужное время.
Роутинг для iOS: универсальная навигация без переписывания приложения - 1
Однако, как только в приложении появляется переход на какой-то экран по push-уведомлению или ссылке, всё становится несколько сложнее. Сразу появляется масса вопросов:

  • что делать с view-контроллером, который сейчас находится на экране?
  • как переключить контекст (например, активную вкладку в UITabBarController)?
  • есть ли в текущем стеке навигации нужный экран?
  • когда следует игнорировать навигацию?

Читать полностью »

Тестирование как универсальный принцип

Уже почти четверь века празднуем миллениум, а тестирование ещё только входит в нашу жизнь… Сложно убедить начинающих разработчиков использовать эту потрясающую технику в своей работе… Да чего уж там говорить о разработчиках, простым смертным и то не всегда доступно понимание того, что тестирование — основа устойчивых систем! Как сложно бывает убедить продавщицу в том, что протестировать новый продукт — не значит съесть его! Даже бывалые охранники явно работают по старинке — пытаются догнать и отобрать тестируемое. И не докажешь им, что если уж сам Господь Бог не гнушается использовать TDD в своей работе (вспомним Великий Потоп), то нам как говорится сам бог велел…

Количество разводов растёт — почему? Да всё потому же! TDD! Сначала тестируй — потом женись! Нет, доверчивые мужички в расхристанных тулупах, падкие на эксплуатирующую секс рекламу, выкатывают молодую жену прямо в продакшн…

Ну мы то с вами из другого теста, сначала тестирование — потом всё остальное!

Я тестировщика узнаю по походке…

И вот когда я начал писать очередную базу данных code first то задумался, а почему бы не сделать автоматическое тестирование своего DAL слоя прямо на встроенных в VisualStudio тестах?

И у меня получилось! Прозрачно для EntityFramework, без всякой ловкости рук под одеялом и мошенничества с fake-объектами. Кому интересно — расчехляем VS, одеваемся как тестировщики и вперёд! (я всегда одеваюсь как тестировщик)

Одежда тестировщика

image

Читать полностью »

C++ — язык запутанный, и существенным его недостатком является сложность создания изолированных блоков кода. В типовом проекте всё зависит от всего. Эта статья показывает, как писать высокоизолированный код, который минимально зависит от конкретных библиотек (включая стандартные), имплементаций, сведя зависимость любого куска кода к набору интерфейсов. Помимо этого будут предложены архитектурные решения по параметризации кода, которые могут заинтересовать не только программистов на C++, но и программистов на Java. И что важно, предложенное решение весьма экономично по времени разработки.
Читать полностью »

История одного монолита. Часть 2 - 1

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js