Ранее, я несколько раз упоминал об особом типе архитектуры, которую я называю луковой (onion architecture). Эта архитектура идеально подходит для приложений с длительным жизненным циклом и сложной бизнес логикой. Я считаю, что ее использование в подобных проектах приводит к превосходным результатам, в следствии изначально заложенного в архитектуру акцента на разделение различных аспектов приложения. В луковой архитектуре уделяется особое внимание к описанию поведения системы в терминах контрактного программирования и выносу инфраструктурного кода во внешние модули. На диаграмме ниже, вы можете видеть графическое представление традиционной “многослойной” архитектуры. Это очень популярный подход, использующийся в различных вариациях во множестве виденных мной проектов.
Рубрика «Проектирование и рефакторинг» - 61
Луковая архитектура. Часть 1
2014-08-18 в 17:28, admin, рубрики: .net, design patterns, jeffrey palermo, onion architecture, Анализ и проектирование систем, Проектирование и рефакторинг
Рентабельный код
2014-08-13 в 12:43, admin, рубрики: best practices, код, Программирование, проектирование, Проектирование и рефакторинг, разработка, риски, управление проектами, черный властелинЖили-были в двух соседних деревушках Вилларибо и Виллабаджо две команды разработчиков. И те и другие делали ревью кода, писали тесты, приводили рефакторинг, но через год разработки в Вилларибо уже выпустили релиз и вышли в продакшн, а в Виллабаджо все еще проводят рефакторинг и чинят баги. В чем же дело?
Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.
Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.
До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.
Почему об этом следует думать разработчику, если есть менеджер?
- Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
- Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
- Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в пол года отвязаться от «трудного ребенка»
С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.
Читать полностью »
MindStream. Как мы пишем ПО под FireMonkey
2014-08-11 в 14:51, admin, рубрики: Delphi, FireMonkey, FireMonkey mobile, ооп, Проектирование и рефакторингМесяц назад мы решили написать кросс-платформенное приложение, используя FireMonkey. В качестве направления выбрали рисование графических примитивов, с возможностью сохранения и восстановления данных.
Процесс написания приложения мы договорились подробно описывать на Хабре.
В статьях будет показано на практике использования различных техник, таких как: Dependency Injection, фабричный метод, использование контекстов, использование контроллеров и т.д. В ближайшем будущем планируется прикрутить туда тесты Dunit. DUnit’a в данный момент нет для FMX, так что придётся что-то придумывать самим.
Начнем мы с рабочего прототипа который к моменту окончания статьи приобретет такой вид:
Как мы спроектировали и сделали True Image for Mac
2014-08-11 в 10:54, admin, рубрики: c++, GUI, true image, архитектура приложений, Блог компании Acronis, Inc, паттерны проектирования, Проектирование и рефакторинг, разработка, хомяк 
Всем привет. Однажды мы узнали о том, что нам предстоит сделать True Image для Mac OS. Как это обычно бывает, сделать надо быстро и качественно, ага. Сразу возник резонный вопрос, почему бы просто не скомпилировать True Image для Windows под Мак, ведь большинство кода уже кроссплатформенно, в том числе интерфейс, написанный на Qt? Но нам тут же были обозначены рамки:
Интерфейс решено было сделать абсолютно новый, в разы проще чем у большого брата. Также в качестве GUI-фреймворка опытные в Маковых делах ребята из Parallels посоветовали использовать именно нативный Сocoa вместо Qt, а люди из еще одной известной компании подтвердили правильность этого решения. Решили не ставить под сомнение их опыт.
В итоге было решено попытаться написать фронтенд на Cocoa к существующему коду. Продукт мы таки выпустили и уже написали об этом на Хабре, а сегодня я хочу поделиться архитектурно-техническими деталями сего процесса.
Читать полностью »
Ubiquitous Language и Bounded Context в DDD
2014-08-11 в 6:53, admin, рубрики: Bounded Context, DDD, Ubiquitous Language, Программирование, Проектирование и рефакторинг, разработка Domain-Driven Design: Tackling Complexity in the Heart of Software Эванса — лучшая книга о проектировании действительно больших enterprise-приложений, что я читал. Видимо это мнение разделяют многие другие разработчики и проектировщики, потому что Entity и ValueObject, Repository и Specification встречаются почти в каждой большой кодовой базе. Но вот незадача, Ubiquitous Language (единый язык) и Bounded Context (контекст предметной области) в чужом коде я не видел ни разу. И здесь зарыта очень большая собака.
Читать полностью »
Dependency Injection. JavaScript
2014-08-10 в 20:55, admin, рубрики: dependency injection, design patterns, dm.js, inversion of control, javascript, Проектирование и рефакторингПонятия «инверсия управления» и «внедрение зависимостей» не являются новыми, но в сообществе JavaScript, несмотря на его бурный и продолжительный рост, почему-то встречаются довольно редко.
Независимо от контекста исполнения, расширяемое и поддерживаемое javascript-приложение, как и приложение, написанное на любом другом языке, должно соответствовать некоторым архитектурным принципам. Одним из которых является инверсия управления. Читать полностью »
JavaScript to TypeScript — трудности перевода
2014-08-03 в 11:13, admin, рубрики: javascript, TypeScript, Веб-разработка, Программирование, Проектирование и рефакторингНаверно многие в курсе, что у JS достаточно ограниченно реализовано ООП. Одних уровень ООП в JS устраивает, другие не видят необходимости придерживаться правил ООП, другие без ООП не могут писать код. Тут мы попробуем без холивара разобраться в некоторых ньансах перехода с JS на TS.
О мотивации перехода мы поговорим в заключении статьи и скорее для тех, кто понимает важность качества кода. Но пару слов все же скажем вначале. Когда Вы делаете небольшой тестовый код, с неясным коммерческим статусом — то вряд ли вы будите этот код прилизывать. А ООП это хороший способ прилизать код, это не сколько не влияет на функциональность вашего кода, даже наоборот, часто задерживает быстрое написание тех фич, которые вы решили сделать. Иногда даже страдает производительность. Но наверное каждый знает тот уровень, когда ему самому уже сложно разобраться в своем коде, тогда вы начинаете его просматривать и время от времени подумывать о рефакторинге. Если ваш язык интерпретируемый, без строгой типизации и не достаточно хорошо поддерживает ООП, то вы этот момент будет оттягивать долго — но я рекоммендую все же об этом задуматься. Если ваш язык JS — хорошим вариантом будет его перевести на TS, вы ничего не потяряете это уж точно. Но есть некоторые сложности, из-за которых в процессе перевода вы можете засомневаться в правильности такого решения.
Интервью с Дино Эспозито, автором книги «Microsoft .NET: Architecting applications for the enterprise»
2014-07-28 в 10:21, admin, рубрики: .net, cqrs, DDD, event sourcing, framework, Блог компании Luxoft, проектирование, Проектирование и рефакторингДИНО ЭСПОЗИТО
Анализ одного рефакторинга
2014-07-28 в 9:42, admin, рубрики: ошибки в книгах, ошибки в коде, Проектирование и рефакторингВ данном крохотном посте речь пойдет об одной из глав, книги «Принципы, паттерны и методики гибкой разработки на языке C#», с названием «Рефакторинг». Глава полностью посвящена рефакторингу. На примере одного большого метода, автор последовательно модифицирует код, попутно объясняя почему он делает те или иные модификации. После каждого этапа, код прогоняется через тесты.
Очевидно, что многие примеры из книг, часто являются синтетическими, и предназначены только для пояснения какой-либо мысли статьи. По этому часто в книгах присутствуют как синтаксические так и логические ошибки, и обычно, это ни как не ухудшает восприятие книги.
Статья не преследует цели дискредитации автора, просто показалось интересным выложить свои наблюдения и услышать мнение сообщества по этому поводу.
Читать полностью »
Еще одна книга о паттернах? Дайте две!
2014-07-23 в 18:30, admin, рубрики: .net, books, design patterns, Проектирование и рефакторингПривет, читатель! Я хочу поговорить с тобой о паттернах проектирования. Знаешь, это такая старая штука, о которой модно было писать в конце прошлого века, и некоторые изверги о них еще иногда спрашивают на собеседованиях. У меня возникла мысль, что пришла пора снова вспомнить о них, но на этот раз рассмотреть их в современных реалиях. А разве есть более подходящий способ это сделать, кроме как взять… и написать об этом книгу?
