Xp: Экстремальное программирование

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

Другие модели

ISO/IEC 15504 — один из американских стандартов

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

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

Формальные методы

Формальные методы — математические представления проблемы создания программного обеспечения, а также оборудования на уровнях требований, спецификации, а также дизайна. Как пример можно привести B-Method, Сети Петри, RAISE . Доступны разные формальные нотации спецификаций, такие как Z notation. Чаще всего для создания и валидации приложений и их дизайна используется теория конечных автоматов.

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

Вопрос11. Системы контроля версий

Source control (revision control, source code management (SCM)) - по-русски это все обычно называют системами контроля версий. Контролировать ими можно много чего, но меня они, конечно, интересуют в плане работы с кодом. Сначала я кратко расскажу про системы контроля версий для тех, кто о них ничего не знает или знает мало, а потом пару слов скажу про выступление Линуса Торвальдса, в котором он рассказывает о Git'е.

Зачем вообще нужен какой-то контроль за кодом? Затем, что без контроля получается бардак. На диске появляются бесконечные копии исходников с загадочными именами: MyProject1, MyProject.backup, MyProject.old, MyProject.oldest. Проку в них никакого нет, потому что все равно уже не вспомнить где какие изменения делались.

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

Самые известные, которые чаще всего упоминаются - CVS, Subversion (SVN), Perforce. Все системы, что я перечислила, объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом. Скорее всего вы работали с какой-то из них. Если ни с какой не работали, то очень рекомендую поставить Subversion. Его легко и непринужденно можно погонять на одной локальной машине и получить полное представление о работе систем контроля версий.

Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает :-).

Транк (trunk) - основная ветка кода

Бранч (branch) - ответвления (для экспериментов, например)

Чекин (Check in (submit, commit)) - отправка кода в репозиторий

Чекаут (Check out) - получение изменения из репозитория.

Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать

Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом

Updated 20.07.2008 Вообще терминология расходится, всё зависит от того, о какой именно системе идет речь. Например, "check out" в Perforce имеет несколько иное значение.

Традиционная схема работы с репозиторием в Open Source проектах такова. Есть некто Главный (пусть будет Ведущий программист, неважно). Программисты делают патчи, цепляют их к багам в багтракинговой системе. Главный просматривает их патчи, если все ОК - применяет к коду. В Second Life используется схема работы с патчами. В качестве багтракинговой системы там используется JIRA, в качестве системы контроля версий - Subversion.

В компаниях такая схема тоже иногда применяется, при работе со стажерами. Чтобы кто-то просматривал их код, прежде чем он попадет в репозиторий. Обычные же программисты, как правило, имеют право коммита.

Вот выступление Линуса Торвальдса, в котором он рассказывает про им написанную систему контроля версий Git. Тон рассказа мне не очень понравился, Линус там периодически пытается несмешно шутить по поводу своей популярности. Кстати, по ходу доклада гугловцы упоминают, что у них используется Perforce.

Линус не любит Perforce, не любит CVS, не любит Subversion. Он ратует за распределенные системы контроля версий. Которые, мало того, что убирают точку отказа, но еще делают более простым процесс создания бранчей и позволяют смело экспериментировать с кодом, не вызывая комплексов "засабмитить не то".

Я думаю, Git получит рапространение хотя бы по тому, что его написал Линус. Еще пример использования распределенной системы контроля версий - Bazaar используется при работе над Ubuntu Linux.