17. Практики xp. Планирование

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

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

Обсуждение идет по принципу "от крупного к мелкому". Сначала обсуждается задача в общих чертах, потом она разбивается на подзадачи. И так далее.

Когда все требования таким образом сформированы – они фиксируются где-нибудь в письменном виде.

Затем заказчик определяет приоритеты.

После того, как приоритеты расставлены – производится временная оценка. Тут есть тонкость. Даже несколько.

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

Второе. Разработчики работают в разных ситуациях.

Оценка работы при условии, что разработчик будет сконцентрирован исключительно на задаче, что его ничто не будет отвлекать, что он будет работать с максимальной продуктивностью – эта оценка называется идеальное время. Время, потраченное на разработку в действительности, называется реальным. Отношение этих времен, усредненное за определенный промежуток времени (например, за 8 циклов разработки, см. Частые выпуски версий), называется коэффициентом загрузки (load factor).

Тестирование

А точнее – написание тестов ПЕРЕД написанием кода.

Парное программирование

В прямом смысле этого слова. Парное – два разработчика за одним компьютером.

Что это дает? Прежде всего – мышление у людей не совпадает. В результате в каждой точке ветвления есть большая вероятность, что я и кто-то другой изберем разные направления движения. Т.е. родятся две идеи вместо одной. Соответственно, появляется возможность выбрать более оптимальную из них.

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

Рефакторинги

Процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований Цель рефакторинга — сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным. Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет ее работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу. С другой стороны, нужно отличать рефакторинг от реинжиниринга, который осуществляется для расширения функциональности программного обеспечения.

В XP приняты т.н. постоянные рефакторинги. Зачем это делается?

Аналогия с капремонтом