Журнал «Компьютерра» N 33 от 12 сентября 2006 года

Постоянный рефакторинг заключается в регулярном пересмотре того, что уже написано, уже разработано. И в постоянном его улучшении.

Простота разработки - из двух вариантов выбирается более простой и быстро реализуемый.

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

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

Сотрудничество, а не конфликтование

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

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

Спиральная модель жизненного цикла разработки ПО

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

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

СОФТЕРРА: Высокохудожественный командный интерпретатор

Автор: Илья Шпаньков

Когда разговор заходит о растровых графических редакторах, абсолютное большинство людей в первую очередь вспоминает Adobe Photoshop. Сторонники свободного софта, конечно, не забудут упомянуть и своего фаворита The Gimp, по умолчанию входящего в большинство GNU/Linux-дистрибутивов. Возможно, кто-то вспомнит Paint.NET или еще какой-нибудь «легкий» редактор «для дома, для семьи». Но сегодня мы поговорим не о них.

Все эти популярные средства создания и редактирования графических изображений обладают хорошо развитым интерфейсом и содержат сотни функций, позволяющих создавать настоящие шедевры цифровой живописи. Меж тем наряду со своими известными «коллегами» живет и здравствует еще один своеобразный редактор по имени ImageMagick, который скромно трудится на ниве обработки цифровой растровой графики уже не первый год. Широкой публике этот редактор (а точнее - пакет графических утилит) практически неизвестен в силу особенностей, о которых будет сказано ниже. Однако в некоторых случаях он даст фору любому именитому аналогу.

Скромный трудяга