Экстрим-программирование Agile

Опубликовано cross в Разработка сайтов      4 комментов

Март
31

Полтора года работаю тим-лидом по разработке сайтов, в задачи входит общение с клиентом, расстановка задач и приоритетов, технические задания и планирование работы, разруливание багов, трекинг issues`ов и тд и тп.

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

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

Основные принципы экстрим-программирования очень просты и сводят разработку любых проектов к совершенно простым понятиям:

• Постоянная обратная связь с клиентом
• Прозрачность и простота разработки
• Анализ и предоставление клиенту готовых частей кода(релизов)
• Постоянное обсуждение и тестирование

Моделей(методик), а лучше сказать практик, такого подохода несколько: Cleanroom, RAD, RUP, Scrum, Спираль. На инфографике ниже расписана модель экстремального программирования Agile:

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

Интересно, что TDD в данной структуре выделено как обычный пункт ежедневной работы. У меня на это два взгляда, которые зависят от опытности работающей команды и каждого ее члена в частности.

Понятно, что тест-кейсы должны быть простыми: тест->ожидаемый результат->реальный результат->рефакторинг или новый) код. И в случае опытных программеров этот TDD проходит как по маслу, но если программеры не опытные или не до конца (непрозрачно) понимают весь проект в целом, что противоречит практике Agile, выплывают баги подобные нашим. Когда в самом конце тест-разработки готовый продукт является одним большим багом

Исходя из всего этого, становятся понятными некоторые вещи, которыми можно подитожить статью:

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

Постовой:
Уникальное предложение от CheapTop.ru - БЕСПЛАТНАЯ раскрутка - получи вожделенные ТИЦ и PR плюс продвижение по запросам без затрат. Спешите, число участников ограничено!

Как я Redmine поднимал

Опубликовано cross в Общее, Разработка сайтов      8 комментов

Март
17

Redmine is a flexible project management web application. Written using Ruby on Rails framework, it is cross-platform and cross-database.

Все классно в этой системе, и учет времени, и раскидывание тасков и расширяемость плагинами и скрость работы, но вот "written using Ruby on Rails" совсем не нравится и не потому что я его не знаю, а потому что для его установки, настройки и работы на сервере должен появится и заработать ruby.

Решений есть несколько, одно из них запускать Redmine под апачем, но мне оно не совсем понравилось, поскольку показалось несколько тяжелым. Я выбрал вариант запуска Redmine под библиотекой Webrick, которая предоставляет функционал работы приложений с http.

Идея совершенно проста, в папке редмайна лежит script/server, который поднимает Webrick и держит все http запросы к Redmine. Работает это все отлично даже скрипт можно запустить демоном на своем порту script/server -d -p port.

Но вот проблема в том, что при перегрузке сервера webrick падает и редмайн перестает работать. Так как я не фришник, пришлось гуглить решение и на свое удивление ответа о том, как поставить запуск webrick в автолоад не нашлось.

Попробовал закинуть /path/script/server в крон по перегрузке сервера, но это тоже не помогло. Следующее решение нашлось в основах документации FreeBSD.

/etc/rc.d - папка, в которой хранятся скрипты запуска приложений. В нее я положил файлик rm, с таким же owner и group как и у остальных файлов в этой папке. Его содержимое:

#!/bin/sh

. /etc/rc.subr

name="rm"
rcvar=`set_rcvar`
rm_flags="-d -p 3000"
command="/absolute/path/to/redmine/script/server"

load_rc_config $name
run_rc_command $1

В /etc/rc.conf добавляем строку rm_enable="YES" и в итоге при перегрузке сервера в логах получаем ошибку о том, что shebang не есть праильный, оно и действительно так.

Ищем свой ruby и в файлике /absolute/path/to/redmine/script/server правим shebang на(в моем случае) #!/usr/local/bin/ruby.

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