Impact Mapping на практике

Когда читал книгу Impact Mapping первый раз, у меня было желание бросить её на середине. Всё, что там написано, слишком очевидно. Я нашел в себе силы и дочитал, благо книга коротная и с большими картинками. Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе.

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.

Смотрите видео с мастер-класса по Impact Mapping

Command and Query Responsibility Segregation (CQRS) на практике

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

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

IT-образование в ВУЗах

Окончился очередной учебный год в университете. Ниже будет мой отчет по работе на IT-специальности. Возможно кому-то тема обучения в ВУЗе близка, буду рад вашим комментариям и замечаниям, идеям как можно сделать лучше.

На данный момент у меня 4 года опыта преподавания в ВУЗах. Первые 3 года вел ООП и Технологии программирования у 4-го курса на кафедре Информатики в ЮУрГУ. Этот опыт я уже описывал в статье Обучение IT-специалистов в университете. Текущий год я провел на ВМИ в ЮУрГУ и эпизодически в ЧелГУ на нескольких лекциях.

Переход от монолитной архитектуры к распределенной

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

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

IT-конференции на ближайшее время

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

Приемочное тестирование как производственная необходимость

Все программисты — оптимисты. Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»
"Мифический человеко-месяц", Ф.Брукс

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

Я выбрал 3 задачи из практики, с которыми скорее всего сталкивался каждый разработчик. Многие разработчики делали эти задачи и ленились, как и я, сначала придумать как измерить успешность задачи. До начала надо ответить на вопрос: "Как я могу узнать, что сделал всё правильно?". Обо всем по порядку.

Integration Patterns: Shared DB, state machine и очередь сообщений

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

Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы

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

Сейчас я хочу рассмотреть более общий вариант работы со старыми или плохоработающими системами. Хочу дать ответ на вопрос: Что делать, если вам досталась в работу legacy system? В статье я буду использовать термины legacy system (унаследованная система) и legacy code (унаследованный код).

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