* Совместное использование разных agile практик: XP, Scrum, Kanban & Lean
* TDD подробно
* Гибкий подход к разработке БД

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

Во второй - про то, что такое TDD и чем оно не является, про общий подход к тестированию, принятый в нашей команде, про разные уровни и паттерны тестирования, практические примеры тестирования начиная от классических тестов бизнес логики до хитрых методов тестирования GUI и DB

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

Вот раздумываю, стоит ли выбрать одну или отправлять все три?

Друзья, у меня к вам вопрос - какая тема вам была бы наиболее интересна?

Очень интересная история появления Lean. Корни его лежат в Toyota Production System (TPS), системе управления производством Toyota, автором которой является Таичи Оно.
Тойота поставила перед собой амбициозную цель - стать производителем автомобилей номер один в мире, обогнав американцев. Американское производство в те времена было построено на модели Генри Форда. Фордовский конвеер был идеален для выпуска машин в одинаковой комплектации. Производство же на Тойоте было организовано по другому - выпускать машин ровно столько, сколько они смогут продать и в такой комплектации, как захочет заказчик. Значит производство должно стать максимально гибким. Качеству уделялась особая роль.

Таичи Оно придумал и внедрил принципы TPS сначала в своем цеху, а затем в течение следующих 20 лет они распространились на все производство. Принципы эти часто противоречат общепринятым. Ну допустим, у нас есть производство машин. Машина состоит из деталей (дверей, двигателя, колес), которые в свою очередь состоят из множества других деталей. Колесо, к примеру, состоит из протектора и диска. Допустим, у нас есть станок, который штампует диски. Станок этот дорогущий, стоит 1 000 000$. Согласно классической экономической теории, раз станок такой дорогой, он ни в коем случае не должен простаивать. То есть он должен постоянно штамповать диски и наполнять ими склад. Когда надо будет делать другие диски, станок перенастраивается (это занимает несколько дней) и опять запускается в работу. Таичи Оно переворачивает этот принцип с ног на голову. Лишние диски, которые лежат на складе - это потери (waste), а потерь надо избегать. Поэтому станок должен штамповать ровно столько дисков, сколько требуется и не больше. это в частности приводит к тому, что у сборщика нет лишних деталей, которыми он бы мог заменить бракованные. Если возникает брак - это сигнал к тому, что нужно устранить причину возникновения этого брака, а не просто заменить делать на исправную.

Как я говорил, качество стоит на первом месте. Интересный принцип Stop the line. Если обнаруживается неисправность, например, приводящая к браку, конвейер останавливается до полного устранения причины брака. Все рсурсы мобилизуются на то, чтобы найти и устранить причину, которая мешает работать.

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

Принцип Kaizen (Кайдзен) говорит о том, что процесс должен постоянно улучшаться.

Тренинг был построен как workshop, то есть очень большую часть времени мы выполняли упражнения. Мы руководили воображаемой строительной фирмой, лозунг которой звучал "Мы сделаем вам ремонт в два раза дешевле и в два раза быстрее, чем конкуренты". Самое интересное, что когда мы начали думать над тем, как мы можем построить работу таким образом, чтобы удовлетворить это требование, мы сами вывели для себя большую часть принципов Lean. Что по моему мнению только доказывает, что они соответствуют принципам здравого смысла.

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

PS. Вчера приехал на заправку. Было еще не поздно, часов 7 вечера. Заправка закрыта - сливают бензин из автоцистерны. Перед заправкой стоит очередь машин 10, первые стоят уже минут 50. Пошел узнавать - будет закрыта еще полчаса как минимум. Ждать не стал, уехал, но по дороге, пользуясь принципами Lean, придумал несколько способов, как можно было эту ситуацию избежать. А заодно и как можно увеличить пропускную способность заправки примерно вдвое

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

Над проектом работает одновременно несколько пар разработчиков. Часто бывают ситуации, когда несколько пар работают над одним и тем же участком кода. При интеграции кода, то есть при check-in'е изменений в общий репозиторий, могут возникать конфликты. Например, над одним участком кода работают 2 пары. Первая пара решает зачекинить свои изменения. Перед этим им нужно взять последнюю версию, разреши конфликты (если они есть), прогнать тесты. В это время, пока первая пара готовится к чекину, вторая пара чекинит свои изменения, которые пересекаются с первой парой. Когда первая пара начнет чекинить свой код, система хранения кода будет ругаться на то, что есть более свежие версии файлов на сервере. Первая пара будет вынуждена по-новой брать последнюю версию, разрешать конфликты, чинить тесты. Если изменений было сделано много, это может отнять довольно много времени, в это время вторая пара опять может зачекиниться, и так далее.

А теперь представьте, что одновременно работают не 2 пары, а 5. Вероятность таких конфликтов будет значительно выше. Это ведет к непродуктивной работе, так как люди вынуждены делать одно и тоже без видимого прогресса, а так же может привести к возникновению обид внутри команды.

- Я же просил не чекинить, пока мы не закончим!
- А мы забыли
- }8-Е

Избежать таких конфликтов нам помогает каска-чекинка.

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

Почему название такое странное?
В переводе с английского - "стоячая планерка". Означает, что все участники митинга стоят.

А зачем они стоят?
А для того, чтобы митинг не затягивался. Хороший stand-up длится не больше 15 минут.

А зачем он вообще нужен?
Все участники отвечают на 3 вопроса:
Что я сделал вчера?
Что я буду делать сегодня?
Какие у меня проблемы или затыки, которые мешают мне выполнить мою работу?

Надо сказать, что это не допрос с пристрастием. Я тут слышал про команды, которые тоже использовали SCRUM. У них тоже был stand-up, но он длился по часу-полтора, что было очень утомительно. Я честно говоря не представляю как можно простоять час. На этом митинге каждый разработчик докладывал что он сделал, а потом оправдывался, почему он не успел сделать то, что запланировал. Митинг превращался в публичную порку. Удручает также то, что им приходилось писать ежедневные отчеты о сделанной работе, а потом еще раз озвучавать это на stand-upе.

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

Ну и что это дает?
А дает это то, что все члены команды понимают, кто чем занимается. Мы планируем работу на день. Мы разбиваемся по парам. Мы выбираем себе интересные задачи. Ну или не интересные - кому как повезет. А еще это сигнал к началу работы. Во время митинга все настраиваются на рабочий лад, вспоминают на чем вчера остановились. Если возникает какая-то проблема, находится другой человек, готовый помочь. После stand-upа все рассаживаются по парным станциям и начинают весело колбасить код.

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

Суть вкратце в следующем.

Программист Боб работает в компании KillerWattSoftware. Он хороший программист со стажем. В настоящий момент он работает над проектом под названием Flitzerboing-Ultra для компании MegaCorp. Проект очень крупный, заключен контракт на год стоимостью $12M. В настоящий момент Боб работает вместе с Питером, архитектором MegaCorp, над архитектурой будущего приложения.

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

Боб задумался и стал выспрашивать Сэм и других людей, что побуждает MegaCorp отказаться от контракта. Расчеты были несложные. Контракт на год стоимостью $12M стоит компании $1M в месяц. Это означает, что им нужен бюджет $12M в условиях кризиса, когда каждая копейка на счету. Разумеется, Flitzerboing-Ultra нужен им не просто так, а для того, чтобы с его помощью получать прибыль. Ожидаемая прибыль составляет $2M в месяц, что означает, что проект окупится только спустя 18 месяцев после его начала. Может быть меньше, может быть больше, но приблизительный порядок примерно такой.

Становится понятно, почему MegaCorp отказывается от контракта, не так ли? В условиях кризиса найти лишние $12M непросто, да и неизвестно, что будет через 18 месяцев.
Несмотря на это, никто не спорит с тем, что в долгосрочной перспективе проект Flitzerboing-Ultra выгоден, так как он в конце концов мог бы принести прибыль.

Боб старый волк, он знает, что если проект планируется на год, скорее всего он продлится полтора. Для KillerWattSoftware это выгодно, так как приносит допольнительные деньги. Лишние полгода потребуются для того, чтобы реализовать те требования, которые были не видны до начала планирования, которые появились в процессе разработки программы, или которые изменились. Что произошло бы, если бы проект растянулся на 2 года вместо запланированных 12 месяцев? Такое случается с проектами, знаете ли. MegaCorp потеряла бы ожидаемую прибыль за год использования продукта, то есть $24M. Компании KillerWattSoftware это тоже не сулило бы ничего хорошего, так как контракт предполагает серьезные штрафные санкции в случае срыва сроков. MegaCopr была очень заинтересована в проекте. Когда контракт только обсуждался, MegaCorp была готова заплатить даже больше $12M за проект, если бы он закончился за 6 месяцев. Техническая экспертиза оценивала проект в 8-10 месяцев, но менеджеры решили подстраховаться и заключили контракт на год.

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

Он думал, думал, думал, думал, думал, думал, думал, думал, думал, думал, думал, думал ... пока его не осенила блестящая идея.

Что если разбить Flitzerboing-Ultra на 4 маленьких релиза, каждый по 3 месяца? В этом случае MegaCorp получит первую версию спустя всего лишь 3 месяца, затратив на разработку $3M. Если предположить, что прибыль от первой версии будет не такая большая, как от всего продукта, но все-же будет, допустим, $1M в месяц, от второй - $1.2M, от третьей - $1.5M и от четвертой - $2M, это означало бы, что проект переставал быть затратным уже спустя 3 месяца после его начала. Начиная с 6 месяца он начинает самоокупаться, а полностью окупался через 14 месяцев. При этом затраты на проект сокращались с $12M до всего лишь $3M. MegaCorp тратит намного меньше, но получает тот же продукт через те же 12 месяцев, и при этом получает прибыль на 6 месяцев раньше! Разве это не стоит попробовать?

Кроме этого, все требования к проекту понадобилось разделить по приоритетам - нужные, очень нужные, очень-очень-очень нужные и не очень нужные. В первый релиз должны будут войти самые нужные функции, чтобы продукт мог приносить максимальную прибыль как можно раньше. Как известно, 80% пользователей пользуются только 20% продукта, так что если удастся реализовать эти 20% в первую очередь, это принесет максимальный эффект. Оставшиеся требования могут измениться или вообще оказаться ненужными. Первый iPod имел вполовину меньше функций по сравнению в конкурентными продуктами, но он был хорош, очень хорош. То что он делал - он делал хорошо, он понравился пользователям и он сразу начал приносить прибыль компании. Затем новые функции добавлялись и добавлялись, и все больше и больше людей их покупали. Вспомним, как Google представил бету версию GMail. Продукт был еще не готов, но пользователи уже вовсю могли им пользоваться и могли давать свою оценку. Программисты еще долгое время доволили продукт до ума, добавляли новые фичи, вылизывали, но основная часть - получение и отправка почты, была доступна пользователям очень рано, и прибыль за счет рекламы продукт стал приносить очень рано.

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

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

Что было дальше?

Руководство MegaCorp настолько понравилась эта идея, что они захотели применить ее ко всем следующим проектам, в которых это возможно. Кроме этого, они хотели сохранить это ноу-хау в тайне от конкурентов. Бобу эта идея не понравилась. Что если врач изобретет супер лекарство, которое будет спасать жизни тысячам людей, и сохранит свое изобретение в тайне. Что если программист придумает блестящий алгоритм и сохранит его для себя. Разве это правильно? Боб думал, думал, думал, думал, как сделать это публичным. И придумал. Он начал писать, писать и писать... и написал эту книжку, и выложил ее в интернете

Есть еще парочка возможных схем, которые по той или иной причине совершенно не используются.

1. Секонд хенд. Почему нет рынка б/у софта? Купил я допустим какой нибудь ну не знаю, к примеру, Автокад ну или там Corel Draw. Но он мне не для работы нужен, я не художник и не дизайнер. Я ремонт дома делаю, а плитку мне удобно в Corel-е планировать. Считать удобно, размеры точные, пораскрашивать можно - в общем удобнее чем в Paint-е гораздо. Зачем мне покупать полноценную коробочную версию, если она мне нужна от силы пару дней в год? Я бы лучше купил б/у за полцены, попользовался, а потом таки продал. Чем плохо? Производитель свои деньги уже получил от первого покупателя, а пользователей у программы становится больше. А, ну да, интересы производителя ущемляются - он же свои кровные теряет, которые в противном случае с каждого бы поимел. Но давайте не только о производителе думать, но и о нас, обычных пользователях.

2. Аренда. Я плачу не за коробку, а за время, потраченное на пользование тем или иным софтом. Да, тут возникает куча проблем - как считать время, как посылать его на сервер производителя, как быть если нет связи, но давайте пофантазируем. Предположим, что у нас повсеместно есть дешевый доступный интернет. Учитывая возможности современных беспроводных технологий, это вовсе не нереальное допущение. Насчет дешевости придется потерпеть, но надеюсь через пару (десятков?) лет провайдеры утолят врожденную жадность и интернет будет не дороже воды из-под крана. Допустим также что все пользователи честные благородные люди и если стоимость софта лежит в разумных пределах, они готовы за него платить. Ну давайте пофантазируем, чего вы? Ведь тогда нет принципиальных проблем посчитать чем я реально пользовался? В конце месяца получаем квитанцию
- за Office 40 часов = 80 рублей
- за Corel Draw 3 часа = 15 рублей
Деньги снимаются с электронного счета, или с кредитки, да пофиг как лишь бы в сберкассу не бегать.

Почему такого до сих пор нет? Пора бежать за патентом?

Для примера возьмем излюбленный пример системы учета заказов. В системе имеются объекты заказчик (Customer) и заказ (Order).

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

order.Amount >= 1000000M

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

Начнем, как всегда, с написания теста:

[TestClass]
public class SpecificationTests {
[TestMethod]
public void CriticalOrderTest() {
  var specification = new CriticalOrder();

  Assert.IsFalse(specification.IsSatisfiedBy(new Order() {Amount = 0}));
  Assert.IsFalse(specification.IsSatisfiedBy(new Order() {Amount = 999999}));
  Assert.IsTrue(specification.IsSatisfiedBy (new Order() {Amount = 1000000}));
  Assert.IsTrue(specification.IsSatisfiedBy (new Order() {Amount = 2000000}));
 }
}

И собственно имплементация

public class CriticalOrder {
 public bool IsSatisfiedBy(Order order) {
  return order.Amount >= 1000000;
 }
}

Какой прикуп мы получили от введения спецификации? Имеет ли смысл ли вводить новый класс из-за какого-то одного условия? Возможно, не всегда, но в этом случае имеет. Ценность спецификации в том, что она

• Отделяет логику условия от объекта, хранящего данные
• Легко тестируется в изоляции
• Помогает избежать дублирования одинаковых условий
• Дает условиям понятные мнемонические имена, отражающие их бизнес смысл

Преймущества инкапсуляции, я думаю, объяснять не надо. Бизнес-правила могут измениться, а лучше сказать, что они точно изменятся. Например, в следующей итерации нужно будет выделить крупных заказчиков в особую категорию "KeyCustomers" и считать критическими все заказы этой категории, независимо от суммы. Или по прежнему зависимо, но от другой величины, например $200 000 (сказываются последствия кризиса). Можно сделать спецификацию параметризуемой пределом суммы:

[TestClass]
 public class SpecificationTests {
 [TestMethod]
 public void CriticalOrderTest() {
  var specification = new CriticalOrder(200000);

  var keyCustomer = new Customer {Type = CustomerType.KeyCustomer};
  var otherCustomer = new Customer {Type = CustomerType.Other};

  Assert.IsFalse(specification.IsSatisfiedBy(new Order(keyCustomer) {Amount = 0}));
  Assert.IsFalse(specification.IsSatisfiedBy(new Order(keyCustomer) {Amount = 199999}));
  Assert.IsTrue(specification.IsSatisfiedBy(new Order(keyCustomer) {Amount = 200000}));
  Assert.IsFalse(specification.IsSatisfiedBy(new Order(otherCustomer) {Amount = 200000}));
 }
}

public class CriticalOrder {
 private readonly int minimalAmount;

 public CriticalOrder(int minimalAmount) {
  this.minimalAmount = minimalAmount;
 }

 public bool IsSatisfiedBy(Order order) {
  return order.Customer.Type == CustomerType.KeyCustomer && order.Amount >= minimalAmount;
 }
}

Композитные спецификации
Часто возникает задача выборки элементов, отвечающим каким-то условиям. К примеру, может понадобиться выбрать все заказы определенного заказчика или все заказы за год или все заказы в Россию и так далее. Можно было бы сделать несколько методов в фасаде слоя доступа к данным (Data Access Layer = DAL) типа GetOrdersByCustomer(Customer), GetOrdersByYear(int), GetOrdersByCountry(string) и т.д. А что делать, если условия нужно комбинировать, например получить все заказы в Россию за год? Если разных вариантов запросов много, интерфейс DAL будет неоправданно разрастаться. Можно эту проблему решить с помощью паттерна Query, а можно использовать спецификации.

Спецификация легко комбинируется с паттерном Composite, что позволяет объединять спецификации в сложные условия. В этом случае все спецификации будут наследоваться от базового класса Specification<T>


public abstract class Specification<T> {
 public abstract bool IsSatisfiedBy(T item);

 public static Specification<T> operator !(Specification<T> specification) {
  return new NotSpecification<T>(specification);
 }

 public static Specification<T> operator |(Specification<T> left, Specification<T> right) {
  return new OrSpecification<T>(left, right);
 }

 public static Specification<T> operator &(Specification<T> left, Specification<T> right) {
  return new AndSpecification<T>(left, right);
 }
}



public abstract class CompositeSpecification<T> : Specification<T> {
 protected readonly List<Specification<T>> specifications;

 protected CompositeSpecification(params Specification<T>[] specifications) {
  this.specifications = new List<Specification<T>>(specifications);
 }

 public ReadOnlyCollection<Specification<T>> Specifications {
  get { return specifications.AsReadOnly(); }
 }

 public void Add(Specification<T> specification) {
  specifications.Add(specification);
 }

 public void Remove(Specification<T> specification) {
  specifications.Remove(specification);
 }
}



public class AndSpecification<T> : CompositeSpecification<T> {
 public AndSpecification() {}
 public AndSpecification(params Specification<T>[] specifications) : base(specifications) {}

 public override bool IsSatisfiedBy(T item) {
  foreach (var specification in specifications) {
   if (!specification.IsSatisfiedBy(item)) {
    return false;
   }
  }
  return true;
 }
}



public class OrSpecification<T> : CompositeSpecification<T> {
 public OrSpecification() {}
 public OrSpecification(params Specification<T>[] specifications) : base(specifications) {}

 public override bool IsSatisfiedBy(T item) {
  foreach (var specification in specifications) {
   if (specification.IsSatisfiedBy(item)) {
    return true;
   }
  }
  return false;
 }
}



public class NotSpecification<T> : Specification<T> {
 private readonly Specification<T> specification;

 public Specification<T> Specification {
  get { return specification; }
 }

 public NotSpecification(Specification<T> specification) {
  this.specification = specification;
 }

 public override bool IsSatisfiedBy(T item) {
  return !specification.IsSatisfiedBy(item);
 }
}


Это позволят создавать сложные спецификации. Вот эта, к примеру, выберет все критические заказы в Россию в 2009 году:


var specification =
 new CriticalOrder(CustomerType.KeyCustomer, 200000) &
 new SoldTo(new Country("Russia")) &
 new AsOf(2009);


Фасад DAL в этом случае может иметь всего лишь один метод, принимающий спецификацию и возвращающий список объектов соответствующего типа

public List<T> Get<T>(Specification<T> specification);

Чтобы получить заказы, удовлетворяющие нашей спецификации, достаточно вызвать

infrastructureFacade.Get(specification);

Спецификации валидации
Спецификации удобно использовать для проверки валидности объекта. К примеру, заказ должен удовлетворять требованиям:

• Сумма от $0 до $10 000 000
• Дата заказа >= 1 Января 2008
• Дата отгрузки >= Даты заказа
• Дата оплаты >= Даты заказа

Хотелось бы, помимо собственно проверки, валиден объект или нет, иметь возможность показать пользователю внятное сообщение, что именно не в порядке. Естественно, сообщение будет зависеть от того, какое именно условие нарушено. Если такое требование возникает в нескольких местах (а как правило, так оно и есть), имеет смысл выделить базовый класс для спецификаций, отвечающих за валидацию.


public abstract class ValidationSpecification<T> : Specification<T> {
 public string Validate(T item) {
  return IsSatisfiedBy(item) ? string.Empty : BuildErrorMessage(item);
 }

 protected abstract string BuildErrorMessage(T item);
}


Теперь мы можем создавать валидационные спецификации для каждого случая:


public class ValidAmount : ValidationSpecification {
 public override bool IsSatisfiedBy(Order order) {
  return order.Amount >= 0 && order.Amount < 10000000;
 }
 public override string BuildErrorMessage(Order order) {
  return "Сумма заказа должна лежать в пределах от 0 до 10000000.";
 }
}



public class ValidDate : ValidationSpecification {
 public override bool IsSatisfiedBy(Order order) {
  return order.Date >= new DateTime(2008, 1, 1);
 }
 public override string BuildErrorMessage(Order order) {
  return "Дата заказа должна быть позже 1 Января 2008.";
 }
}



public class ValidShipDate : ValidationSpecification {
 public override bool IsSatisfiedBy(Order order) {
  return order.ShipDate >= order.Date;
 }
 public override string BuildErrorMessage(Order order) {
  return string.Format("Дата отгрузки {0} не может быть меньше даты заказа {1}", order.ShipDate, order.Date);
 }
}



public class ValidPayDate : ValidationSpecification {
 public override bool IsSatisfiedBy(Order order) {
  return order.PayDate >= order.Date;
 }
 public override string BuildErrorMessage(Order order) {
  return string.Format("Дата оплаты {0} не может быть меньше даты заказа {1}", order.PayDate, order.Date);
 }
}


Теперь можно построить композитную спецификацию ValidOrder


public class ValidOrder : AndSpecification {
 public ValidOrder() : base(
  new ValidAmount(),
  new ValidDate(),
  new ValidShipDate(),
  new ValidPayDate()
 ) {}
}


которую можно использовать в нескольких местах:

• На экране при создании/редактировании заказа
• При массовом импорте из внешней системы
• При реконструировании из базы данных

Интеграция с расширенными методами .Net
Добавление к базовому классу Specification явного преобразования к Predicate

public static implicit operator Predicate(Specification specification) {
 return specification.IsSatisfiedBy;
}

волшебным образом позволяет легко и просто использовать спецификации в расширенных методах:


orders.FindAll(new CriticalOrder());


Что мы узнали?
Спецификация - это абстракция условия, накладываемое на объект. Типичные области применения

• Фильтрация, например при получении списка объектов, удовлетворяющих некоторому условию
• Валидация, например перед сохранением нужно проверить, что объект находится в корректном состоянии

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

Огромное спасибо тем, кто помогал при создании этого материала:
Стас Неверов
Женя Сорокин
Дима Новоселов

Ссылки
http://martinfowler.com/apsupp/spec.pdf

Уфф

1. Общеобразовательный. Рассчитанный на широкую публику. Рассказать для чего нужен, как паттерн помогает решать бизнес-задачи. Минимум кода.
2. Описательный. Рассчитанный на широкий круг разработчиков, с небольшим количеством технических деталей. Показать как работает на простых примерах, не вдаваясь в подробности.
3. Технический. Ориентированный на опытных практикующих разработчиков. Максимально подробно рассказать детали реализации, примеры реального кода, рассмотреть разные варианты использования.

Есть идеи?

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

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

Доменная модель приложения содержит множество объектов. Центральным агрегатом является CommissionableEmployee, который содержит в себе информацию о сотруднике. Для упрощения допустим, что у сотрудника есть свойство - процент аванса. Кроме CommissionableEmployee есть еще большая куча связанных объектов, описывающих настройки расчета комиссий, я не буду сейчас вдаваться в подробности. Изначально CommissionableEmployee был обыкновенным плоским объектом с несколькими свойствами. Позже было добавлено требование, что некоторые свойства объекта должны быть зависимыми от времени, например процент аванса у сотрудника может изменяться в течение года. Это была первая волна версионности.

Для всех объектов, изменяемых во времени, была выделена постоянная (Continuity) и переменная (Version) часть. Управление версиями, такое как создание новой версии, разбиение существующей версии на две новых, слияние версий - было вынесено в базовый абстрактный класс, а все объекты, которым требовалась версионность, наследовались от него. Изменение в классе CommissionableEmployee было самым тяжелым, поскольку это центральный объект, от которого зависят практически все остальные, так что добавление версионности отняло практически месяц. Другие дались легче - меньше было зависимостей и использовался другой подход к изменениям. Если на CommissionableEmployee набросились сразу, разделили на две части и сломали весь код, который от него зависел, а затем мучительно собирали проект, мержили изменения других разработчиков, собирали снова, поднимали тесты, и так без конца, то с другими объектами делали проще - создавали версионный объект рядом с предыдущим, например Account2 и AccountVersion вместо Account и постепенно, один за другим, маленькими шагами, заменяли использование Account на Account2. В конце, когда никто не пользовался классом Account, его удалили, а Account2 переименовали в Account.

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

Для решения этой задачи был использован паттерн Time Travel. Этот паттерн позволяет восстановить состояние объекта на любой момент в прошлом. Как побочный эффект сохраняется история всех изменений, выполняющая роль аудитных записей.

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

• 40% с Января по Март
• 30% с Мая по Июнь
• 50% с Июля до конца времен

Вся изменяемая информация о сотруднике хранится в транзакциях. Каждая транзакция содержит весь набор характеристик, зависящих от времени (такие, как процент аванса) и две временных характеристики: эффективный период и дату транзакции - дату, когда она была создана. Каждая транзакция не мутабельна, то есть не может изменять свои значения после создания. Транзакции могут перекрывать друг друга, в этом случае берутся значения из более поздней (то есть той, которая была создана позже).

В нашем случае будет последовательно создано три транзакции:

• 1. 40% с эффективным периодом Январь - конец времен
• 2. 30% с эффективным периодом Май - конец времен
• 3. 50% с эффективным периодом Июль - конец времен

Затем, по прошествии какого-то времени, скажем, 10 Июня в 14:45, администратор обнаруживает ошибку. Оказывается, сотрудник должен иметь аванс 50% начиная с Апреля.
Он создает новую транзакцию

• 4. 50% с эффективным периодом Апрель - конец времен

которая частично перекрывает 1-ю транзакцию и полностью отменяет 2-ю и 3-ю. С этого момента, то есть начиная с 10 Июня 14:45, программа будет показывать для сотрудника только 2 версии - с 40% и 50% соответственно. Если мы пересчитаем его зарплату на Май, задним числом, то она посчитается с авансом 50%. Но если возникнет вопрос, почему ранее сотруднику посчиталась зарплата на Май с авансом 30%, мы всегда сможем откатиться на момент времени, предшествующий 4-й транзакции, скажем на 9 Июня, и показать настройки сотрудника на тот момент.

Если сотрудник увольняется с Сентября, администратор создает транзакцию на увольнение (5), эффективную с Сентября по конец времен.

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

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

Ссылки:

Time Travel: A Pattern Language for Values That Change
Massimo Arnoldi, LifeWare
Kent Beck, Daedalos Consulting
Markus Bieri, LifeWare
Manfred Lange, Hewlett-Packard

http://www.manfred-lange.com/publications/TimeTravel.pdf

В начале положено представляться, так что для тех, кто меня не знает - меня зовут Антон Бевзюк, я работаю в Интеле чуть более 3.5 лет, в настоящее время занимаю должность Senior Application Developer в отделе со сложным названием, но простой сутью. Наша группа занимается поддержкой SMG (Sales & Marketing Group), то есть мы пишем внутренний софт, помогающий продавцам и маркетологам Интела делать свою работу.

Для наших приложений мы используем .Net платформу, пишем приложения на С# 2.0 - 3.5, в качестве БД используем в основном MS SQL, иногда приходится работать с Oracle, Terradata и прочими.

Визитной карточкой нашей команды является использование гибких методологий (XP, Scrum) в своей работе. Мы имеем более чем 6 летний опыт разработки бизнес приложений с применением гибких методологий и нам есть чем поделиться с теми, кто в этом заинтересован.

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

В следующий раз я расскажу о путешествиях во времени.