Chunk Cloud Computing by Jimmy Nilsson

Джимми Нильсон подытожил в своём блоге новый подход к архитектуре приложений, интерес к которому значительно вырос в последнее время: http://jimmynilsson.com/blog/posts/CCC.pdf

Март 30, 2009. Метки: , , , , , . DDD, architecture, development. Оставить комментарий.

XAML Power Toys

XAML Power Toys – аддин для Visual Studio 2008 SP1 для разработчиков под Silverlight, WPF, облегчающий разработку генерацией XAML’а представений (View), а так же модели представления (ViewModel), со всем необходимыми бизнес-действиями и контролами.

imageПодробнее узнать можно здесь:

http://karlshifflett.wordpress.com/xaml-power-toys/

Март 24, 2009. Метки: , , , , . .net, WPF, coding, design, development, silverlight. Оставить комментарий.

Введение в проблемно-ориентированное проектирование (Domain-Driven Design) (DDD)

Проблемно-ориентированное проектирование (DDD) — это набор принципов и схем, помогающих разработчикам создавать изящные системы объектов. При правильном применении оно приводит к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит сложная бизнес-логика, устраняющая промежуток между реальными условиями бизнеса и кодом.

В этой статье я расскажу об основных принципах и схемах проектирования, соответствующих DDD. Считайте эту статью небольшим введением в проектирование и развитие полнофункциональных моделей предметной области. В качестве контекста беседы я использую сложную предметную область, с которой знаком: управление страховыми полисами.

Если вам понравятся представленные здесь идеи, я настоятельно рекомендую расширить свои познания, прочитав книгу Domain-Driven Design: Tackling Complexity in the Heart of Software (на английском языке), написанную Эриком Эвансом (Eric Evans). Это не просто первое и основное введение в DDD, это сокровищница информации, открытая для нас одним из лучших разработчиков программного обеспечения. Схемы и основные принципы DDD, о которых я буду говорить в этой статье, ведут свое происхождение от концепций, описанных в этой книге.

Статья сильная и заслуживает внимания, продолжение читать здесь:

http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx

Март 24, 2009. Метки: , , , , , , , , , , . .net, DDD, architecture, development. Оставить комментарий.

Создание простейшего DI контейнера с использованием TDD

Введение

Сегодня просмотрел ряд скринкастов от Daniel Cazzulino, в которых он рассказывает о создании с нуля простейшего DI контейнера, что не могло не привлечь моего внимания. Ниже будут приведены примеры из его скринкастов.

Требования

Нам понадобится Visual Studio 2008, 15-20 минут свободного времени и желание узнать как же сделать свой DI контейнер.

Начнём. Funq1

  • Для начала создадим проект Class Library в Visual Studio, назовём его Funq1
  • Далее добавим в решение проект тестов (мы будем использовать TDD на базе тестов Visual Studio) и назовём его Funq1.Tests, создадим ссылку из него на наш проект Funq1

Funq1.Tests

  • В проекте Funq1.Tests создадим тестовый класс ContainerFixture, который будет проверять функционал нашего контейнера.
  • Добавим объявление интерфейсов IFoo, IBar, а так же соответственно классов Foo, Bar, для тестирования нашего контейнера:

  1. public interface IBar { }
  2. public interface IFoo { }
  3.  
  4. public class Bar : IBar { }
  5.  
  6. public class Foo : IFoo
  7. {
  8.     public IBar Bar { get; private set; }
  9.  
  10.     public Foo(IBar bar)
  11.     {
  12.         Bar = bar;
  13.     }
  14. }

* This source code was highlighted with Source Code Highlighter.

  • Создадим тестовый метод, который проверит умеет ли наш контейнер регистрировать и возвращать объекты, выглядеть он будет примерно следующим образом:

  1. [TestMethod]
  2. public void RegisterTypeAndGetInstance()
  3. {
  4.     var container = new Container();
  5.  
  6.     container.Register<IBar>(() => new Bar());
  7.  
  8.     var bar = container.Resolve<IBar>();
  9.  
  10.     Assert.IsNull(bar);
  11.     Assert.IsTrue(bar is Bar);
  12. }

* This source code was highlighted with Source Code Highlighter.

  • Итак, на тестовый класс ContainerFixture выглядит следующим образом:

  1. using Microsoft.VisualStudio.TestTools.UnitTesting;
  2.  
  3. namespace Funq1.Tests
  4. {
  5.     [TestClass]
  6.     public class ContainerFixture
  7.     {
  8.         [TestMethod]
  9.         public void RegisterTypeAndGetInstance()
  10.         {
  11.             var container = new Container();
  12.  
  13.             container.Register<IBar>(() => new Bar());
  14.  
  15.             var bar = container.Resolve<IBar>();
  16.  
  17.             Assert.IsNull(bar);
  18.             Assert.IsTrue(bar is Bar);
  19.         }
  20.  
  21.         public interface IBar { }
  22.         public interface IFoo { }
  23.  
  24.         public class Bar : IBar { }
  25.  
  26.         public class Foo : IFoo
  27.         {
  28.             public IBar Bar { get; private set; }
  29.  
  30.             public Foo(IBar bar)
  31.             {
  32.                 Bar = bar;
  33.             }
  34.         }
  35.     }
  36. }

* This source code was highlighted with Source Code Highlighter.

Funq1.Container

  • Наш тест не проходит, так как Container остается не объявленный, в связи с этим в проекте Funq1 добавляем класс Container
  • Объявляем поле, в котором будут храниться соответствия типов:

  1. Dictionary<Type, object> factories = new Dictionary<Type, object>();

* This source code was highlighted with Source Code Highlighter.

  • Добавим метод для регистрации типа в контейнере:

  1. public void Register<TService>(Func<TService> factory)
  2. {
  3.     factories.Add(typeof(TService), factory);
  4. }

* This source code was highlighted with Source Code Highlighter.

  • А так же метод, для извлечения типа из контейнера:

  1. public TService Resolve<TService>()
  2. {
  3.     object factory = factories[typeof(TService)];
  4.  
  5.     return ((Func<TService>)factory).Invoke();
  6. }

* This source code was highlighted with Source Code Highlighter.

  • На данный момент наш Container выглядит следующим образом:

  1. using System;
  2. using System.Collections.Generic;
  3.  
  4. namespace Funq1
  5. {
  6.     public class Container
  7.     {
  8.         Dictionary<Type, object> factories = new Dictionary<Type, object>();
  9.  
  10.         public void Register<TService>(Func<TService> factory)
  11.         {
  12.             factories.Add(typeof(TService), factory);
  13.         }
  14.  
  15.         public TService Resolve<TService>()
  16.         {
  17.             object factory = factories[typeof(TService)];
  18.  
  19.             return ((Func<TService>)factory).Invoke();
  20.         }
  21.     }
  22. }

* This source code was highlighted with Source Code Highlighter.

Funq1.Tests

  • Пробуем запустить тесты, но они не проходят, т.к. мы умышленно внесли ошибку  в описании метода RegisterTypeAndGetInstance() в строке 17: Assert.IsNull(bar), чтобы убедиться, что тест срабатывает
  • Для того, чтобы тест прошёл, следует изменить эту строчку на Assert.IsNotNull(bar);
  • Далее нас интересует, а что же с зависимостью в конструкторе, как её необходимо зарегистрировать, для этого мы объявляем тестовый метод ResolveGetsDepedenciesInjected() и заносим следующие объявления:

  1. container.Register<IBar>(() => new Bar());
  2. container.Resolve<IFoo>(() => new Foo(container.Resolve<IBar>()));

* This source code was highlighted with Source Code Highlighter.

  • Однако данное объявление не понравится нашему компилятору, т.к. в области видимости замыкания не присутствует container, в связи с этим данное объявление придётся немного изменить:

  1. container.Register<IBar>(c => new Bar());
  2. container.Register<IFoo>(c => new Foo(c.Resolve<IBar>()));

* This source code was highlighted with Source Code Highlighter.

Funq1

  • Соответственно необходимо будет немного изменить наш контейнер, добавив в функции аргумент Container:

  1. public void Register<TService>(Func<Container, TService> factory)
  2. {
  3.     factories.Add(typeof(TService), factory);
  4. }
  5.  
  6. public TService Resolve<TService>()
  7. {
  8.     object factory = factories[typeof(TService)];
  9.  
  10.     return ((Func<Container, TService>)factory).Invoke(this);
  11. }

* This source code was highlighted with Source Code Highlighter.

Funq1.Tests

  • После внесенных в контейнер изменений необходимо будет немного поправить наш первый тестовый метод RegisterTypeAndGetInstance() строку 13 на выражение:

  1. container.Register<IBar>(c => new Bar());

* This source code was highlighted with Source Code Highlighter.

  • Далее вернемся к нашему методу ResolveGetsDepedenciesInjected() и добавим к нему извлечение объекта и утверждение-проверку на null, в результате получим:

  1. [TestMethod]
  2. public void ResolveGetsDepedenciesInjected()
  3. {
  4.     var container = new Container();
  5.  
  6.     container.Register<IBar>(c => new Bar());
  7.     container.Register<IFoo>(c => new Foo(c.Resolve<IBar>()));
  8.  
  9.     var foo = container.Resolve<IFoo>() as Foo;
  10.  
  11.     Assert.IsNotNull(foo);
  12.     Assert.IsNotNull(foo.Bar);
  13. }

* This source code was highlighted with Source Code Highlighter.

Заключение

Вот и подошёл к концу наш увлекательный (надеюсь) урок по созданию с нуля простейшего DI контейнера, что же мы приобрели в процессе:

  1. Базовое понимание функционирования DI контейнера
  2. Практические навыки разработки с использованием TDD

Март 9, 2009. Метки: , , , . .net, C#, coding, development. 1 комментарий.

Руководство по UI дизайну для программистов

VectorBitmapExample[1] Сегодня немного обучался работе с векторной графикой, вспомнил, что Спольски написал по этому поводу книгу:

Большинство известных мне программистов, работающих на С++, с большой опаской относятся к созданию пользовательских интерфейсов (UI). Меня это, признаться, удивляет, поскольку программирование UI, на мой взгляд,- дело простое, очевидное и увлекательное.

Простое – потому, что самый сложный алгоритм, который вам может потребоваться,- алгоритм отцентровки одного прямоугольника в другом. Очевидное – потому, что, сделав ошибку, вы можете ее немедленно увидеть и исправить. Увлекательное – потому, что вы можете сразу же увидеть результаты вашей работы. Работа по UI дизайну сродни работе скульптора: вы непосредственно ваяете программу.

поэтому я сходил на http://russian.joelonsoftware.com/index.html и собрал для себя книжку, если кому-то интересно (получилось 44 страницы), можете скачать и прочитать её.

Март 8, 2009. Метки: , , , . Software, design, development, Книги. 3 comments.

Презентация или сайт

Введение

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

Презентация

image Большинство фирм имеют в своём арсенале качественные презентации, однако не все из них могут похвастаться качественным выполнением своих веб-сайтов. Исходя их чего можно с уверенностью заявлять – лучший вариант для них это публикация данной презентации в интернет, однако это связано с поиском разработчиков, оплатой их труда и прочими расходами. Следовательно, интересно было бы построить CMS, на основе функции импорта слайдов из ppt, pptx презентаций и на выходе получения готового решения в виде веб-сайта.

Так же мне очень нравится дизайн сайта студии depotwpf, который как раз и натолкнул меня на такие мыли.

image

Думаю нечто подобное и может быть результатом деятельности концепта PointCMS.

Вопрос к аудитории

Хотелось бы узнать, что вы думаете по этому поводу.

Февраль 26, 2009. Метки: , , , , , , , . creative, design, development, web. 2 comments.

Введение в Восхитительный Дизайн

Признание: я боюсь выключать свой мобильник.

image Не потому что я боюсь оказаться недоступным для связи, как вы решили. Черт возьми, мне надо меньше заботиться о том, могут ли люди достать меня. Если у вас есть, что сказать мне столь важного, что лучше оторвать меня от Will and Grace, что ж, думаю, лучше мне побыть еще 45 минут в блаженном неведении, прежде чем я это узнаю. Вот мой девиз: Сперва Воля и Милость, а потом Землетрясения и Потопы. (Will and Grace — сериал на NBC, но можно перевести и как Воля и Милость — прим. пер.).

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

У телефона две кнопки, счастливая зеленая и пугающая красная. На них забавные иконки, которые мало что мне говорят.

Вы думаете, что зеленая кнопка его включает. Зеленый значит «Идите», верно?

Неверно.

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

Похоже, что он включается красной кнопкой.

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

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

Наконец-то вы выучили, что телефон включается с помощью красной кнопки и что вы не должны удерживать красную кнопку нажатой для того, чтобы телефон включился, — после всего этого вы начнёте расстраиваться из-за того, что время, необходимое для полного включения телефона, для загрузки хорошенькой фоновой картинки и для поиска сети, — это время составляет примерно секунд 30. Да, это обидно. Похоже, что в Старые Добрые Времена вам не приходилось ждать по полминуты, чтобы включить электроприбор. Там был переключатель, положение «вверх» означало «вкл» (только если вы не жили в Европе, где была страшная война и Вы не могли себе позволить иметь электроприбор), вы переключали его, тумблер оказывался в положении «вкл» и всё сразу начинало крутиться, вертеться, карабкаться, словом, делать то, что ваш электроприбор, предположительно, должен был выполнять. Немедленно. И точка.

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

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

Cover Image: User Interface Design for Programmers (book)

Вот как обстояли дела, когда я написал книгу "Дизайн Пользовательского Интерфейса для Программистов", думая: "Отлично! Пришло время привести каждого на подобную этой страницу с описанием, как разрабатывать дизайн пользовательского интерфейса, и жизнь будет прекрасна".

К сожалению, в то же самое время нас накрыла огромная волна новых потребительских гаджетов, и в то же самое время нас настиг веб.

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

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

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

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

В то время как большая часть продукции становилась всё более непонятной, как типичный пульт управления домашним развлекательным комплексом с массой маленьких мягких кнопок, обозначенных надпиясми "MTS" или "SUPR" или "PTY", значение которых понять никто не имеет ни малейшей надежды, произошло ещё кое что: очень немногие, очень хорошие дизайнеры стали, каким-то образом, пробиваться с по-настоящему восхитительным дизайном, который был красивым, лёгким в понимании, остроумным, и который делал людей счастливыми. Вы знаете их, потому что продукты, о которых я говорю, стали бестселлерами. Apple iPod. TiVo. Google. Даже Motorola RAZR, который так сложно включить, в большинстве проявлений демонстрирует восхитетельный дизайн.

Статья заимствована на вики-узле Джоела.

Февраль 25, 2009. Метки: , , , , , . Getting Real, Software, development. Оставить комментарий.

О шоколаде, интернете, удобстве и разработке

Введение

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

Шоколад

Мне очень нравятся молочные продукты. В частности мне нравится выпить стаканчик молока с несколькими дольками горького шоколада. Сегодня этот очередной раз повторился. Но он не прошёл обычно (может быть это как-то связано с тем, что позавчера я начал новую жизнь ;) ), а отметился этот случай тем, что я очень тщательно подошёл к вопросу открытия шоколадки:

gork_franz[1]

Вы когда-нибудь ели шоколадки этой серии? Фишка в том, что когда ты открываешь её, тебе не надо задумываться над тем как это сделать, потому что всё написано и нарисовано на упаковке, причём сделано так, что мало кто сумеет пойти другим путём. Это Великолепно!

Интернет

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

Приведу простейший пример:

Я пишу сообщение в каком-нибудь RTE (rich-text editor) редакторе, и вдруг меня посещает мысль о том, что неплохо бы было вставить картинку, мои глаза устремляются на поиски соответствующей кнопочки и хорошо, если я найду её, а то вместо того, чтобы продолжить изливать свою творческую энергию в редактор, я начну изливать её авторам сайта, либо критиковать его на различных информационных ресурсах.

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

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

Принято считать, что объекты, содержащие в себе «золотое сечение», воспринимаются людьми как наиболее гармоничные. Пропорции пирамиды Хеопса, храмов, барельефов, предметов быта и украшений из гробницы Тутанхамона якобы свидетельствуют, что египетские мастера пользовались соотношениями золотого сечения при их создании. Архитектор Ле Корбюзье «нашёл», что в рельефе из храма фараона Сети I в Абидосе и в рельефе, изображающем фараона Рамзеса, пропорции фигур соответствуют величинам золотого сечения. Зодчий Хесира, изображённый на рельефе деревянной доски из гробницы его имени, держит в руках измерительные инструменты, в которых зафиксированы пропорции золотого сечения. В фасаде древнегреческого храма Парфенона присутствуют золотые пропорции. При его раскопках обнаружены циркули, которыми пользовались архитекторы и скульпторы античного мира. В Помпейском циркуле (музей в Неаполе) также заложены пропорции золотого деления, и т. д. и т. п.

Хотелось бы привести в пример ресурс, с которым в последнее время начал активно работать, это Twitter

image Он безумно популярен, и это не удивительно, в связи с тем, что он:

  1. Реализует законченную идею
  2. Предоставляет интересный и исчерпывающий функционал
  3. Прост и удобен в использовании

Разработка ПО

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

Чтобы не быть голословным хочу привести в пример анализ некого out-of-box движка для интернет-магазина.

При разработке такого движка следует понимать следующее:

  1. Клиент, который будет заинтересован в покупке данного решения (мы продаём не продукты, мы продаём решения ;) ), не будет заинтересован в организации его поддержки (если он купит коробку, он не захочет нанимать специалистов для работы с ней).
  2. Движок должен быть максимально прост и предоставлять основную функцию – разворачивание и поддержка интернет-магазина, желательно, чтобы это происходило по нажатии нескольких кнопок

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

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

Заключение

Хотел попробовать пописать о разработке немного отвлеченно, немного не с технической стороны вопроса, хочу, чтобы мой опыт был полезен не только .NET – разработчикам.

Февраль 23, 2009. Метки: , , , , . Tech.Life, coding, creative, development, web. 1 комментарий.

SPVisualDev – инструмент Sharepoint разработчика

Введение

Я, как разработчик под платформу Sharepoint, постоянно сталкиваюсь с такими задачами, как создание большого количества однообразного XML-кода (к примеру для описания Feature, WePart, Content Type, List Template и т.д.) что не совсем удобно. Для облегчения выполнения этих задач есть несколько инструментов:

  • один из них это Visual Studio Extensions for SharePoint (VSeWSS), я так и не смог привыкнуть к работе сним, в связи с непрозрачностью генерируемых на выходе решений, что значительно уменьшало гибкость разрабатываемых решений
  • следующий инструмент STSDev – фактически это набор шаблонов для проектов в Visual Studio, является внешней утилитой, удобен в использовании, но полезен лишь на начальной стадии знакомства с платформой
  • ну и последний, на котором хотелось бы заострить внимание, это SPVisualDev

Подробнее

 

Данный продукт представляет собой расширения для Visual Studio, из чего следует тип проектов и прочие удобства, о которых подробнее:

  • Синхронизация в режиме реального времени локальной копии и папки 12
  • Простой способ добавления новых фич в проект, а так же редактирование их свойств и элементов в графических формах (а не XML-файлах)
  • Легкость в активации/деактивации фич из контекстного меню в проекте VS
  • Автоматическая генерация и синхронизация обработчиков фич
  • Набор стандартных проектов и элементов, включая веб-части, обработчики событий, шаблонные страницы и т.д.
  • Отладка фич для страниц приложения с возможностью присоединения дебагера VS к просмотриваемой странице
  • Интеграция с отличных инструментом для создания WSP-пакетов WSPBuilder

FileDownload[1]Так же приложение имеет исчерпывающее количество сопроводительной документации и даже Visual How-to.

Настоятельно рекомендую поставить и попробовать в деле и почувствовать насколько приятно работать с этим инструментом.

Однако это не панацея, а следовательно всё, что не предусмотрено инструментом, придется делать самостоятельно.

Январь 23, 2009. Метки: , , , . codeplex, development, sharepoint, visual studio. Оставить комментарий.

Манифест Agile-разработки ПО (Agile Manifesto)

Манифест

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

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

То есть, мы не ставим под сомнение важность пунктов справа, в то же время для нас гораздо важнее записанное слева. © 2001

Авторы:

  • Кент Бек (Kent Beck)
  • Майк Бидли (Mike Beedle)
  • Ари Ван Биннекум (Arie van Bennekum)
  • Алистэр Коуберн (Alistair Cockburn)
  • Вард Каннингем (Ward Cunningham)
  • Мартин Фаулер (Martin Fowler)
  • Джеймс Греннинг (James Grenning)
  • Джим Хайсми (Jim Highsmith)
  • Эндрю Хант (Andrew Hunt)
  • Рон Джеффрис (Ron Jeffries)
  • Джон Керн (Jon Kern)
  • Брайн Марик (Brian Marick)
  • Роберт К. Мартин (Robert C. Martin)
  • Стив Мэллор (Steve Mellor)
  • Кен Шваубер (Ken Schwaber)
  • Джефф Сазерленд (Jeff Sutherland)
  • Дэйв Томас (Dave Thomas)

Принципы, лежащие в основе манифеста Agile

Мы придерживаемся следующих принципов:

  • Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.
  • Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.
  • Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.
  • Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
  • Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им – они выполнят работу.
  • Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром – непосредственное общение.
  • Работающее ПО – главный индикатор продвижения проекта.
  • Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
  • Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.
  • Важна простота – искусство увеличения объема работ, которых удалось избежать.
  • Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
  • Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.

Материалы

При подготовке статьи использовались следующие материалы:

  1. Веб-сайт, на котором размещен манифест http://agilemanifesto.org/
  2. Русская адаптация (их текст вы прочитали выше)
    http://agileconsulting.ru/wiki/Agile_Manifesto

Январь 8, 2009. Метки: , , . agile, architecture, development. Оставить комментарий.