вторник, 23 февраля 2016 г.

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

экстремальное программирование

Вступление.

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

Основные моменты.

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

При создании системы присутствует человек со стороны заказчика, в идеальном варианте, это конечный пользователь программы. Он отвечает на вопросы программистов связанные с бизнес процессами и помогает в написании интеграционных тестов. Интеграционные тесты - критерий работоспособности программы. Тесты так же пишутся для отдельных компонентов, они называются unit-тесты. Используется практика test-driven development – с начало тесты, а затем реализация модуля, удовлетворяющая этим тестам. Тестирование важно, запуск полного набора тестов происходит, как минимум, один раз в день. Это позволяет добиться того, что код становится общим, облегчается изменение "сомнительных" участков кода и добавляется уверенность при рефакторинге.

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

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

Заключение.

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