Отправляет email-рассылки с помощью сервиса Sendsay

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

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Создание сайта и его продвижение" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Июнь 2003   →
 1
 2
02.06.2003
14:14:04
15:04:04
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Александр Федоренко

Статистика

4.067 подписчиков
-4 за неделю
←   Все выпуски   →

Учимся документировать свои действия.


Информационный Канал Subscribe.Ru

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

Свежие статьи

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

Последние истории из жизни

Что дало мне итерационное планирование
В моей нелёгкой работе программиста я слишком часто использовал "метод продвижения в слепую". Это когда что-то делаешь, но не видишь глубины прогресса и затраченного времени, следовательно, тяжело сориентироваться: как, когда и вовремя ли будет сделана работа. Скажу больше, проблематично давать оценки предстоящим задачам, основываясь на одном лишь "слепом опыте". Такую ситуацию можно сравнить с практикой разговорной речи на иностранном языке: должно произойти чудо или немыслимое совпадение вашего произношения с правильным! Без оценки извне или сравнения с эталоном, данная практика пагубна. Не всегда приятно подвергаться постоянному контролю и давлению со стороны управляющих. Избавление от этого может дать лишь успешный самоконтроль: точность оценок, качество работы и успеваемость. Я чувствовал, что всем этим можно управлять и добиваться желаемого результата. Но для этого необходимо, по крайней мере, видеть, а потом уже анализировать сложившуюся ситуацию. Огромный прогресс в этом направлении я почувствовал, когда начал пробовать планирование итераций. Первые шаги были сделаны без привлечения других членов коллектива, как советуют в книгах по XP. Это позволило не только разбивать функциональность на более мелкие части, записывая ориентировочную оценку продолжительности каждой, но и следить за ходом работы. Такая практика указала мне, где была сделана неверная оценка, с какой скоростью я двигаюсь, и что необходимо предпринять для успешного выполнения работы. А главное, теперь нет необходимости многократно перестраховываться.
Историю поведал Александр Федоренко.

Учимся XP на лету

Начинаем экстремально мыслить

Учимся документировать свои действия.
В повседневной практике разработки программного обеспечения имеет место коллективная работа. Обычно, такая работа позволяет ускорить выпуск готового продукта. Этот подход не совсем прост: довольно редко встречаются случаи увеличения скорости разработки пропорционально количеству задействованных людей. Как и в любой коммандной игре, в программировании важна тактика. Это не просто какое-то правило, которое можно заучить, а целый набор мероприятий и действий, позволяющих организовать сцепление между членами коллектива. Одним из таких мероприятий является документирование кода. Эта тема достаточно многогранна и выходит за рамки использования лишь стандартов кодирования, которые, также, жизненно важны. Экстремальное программирование пропагандирует несколько этапов документирования кода:
а) выбор понятных имён функций, переменных и классов;
б) модульные интуитивно понятные тестовые случаи;
в) словестное описание классов, их публичных членов и аргументов функций.
Здесь будет рассмотрено написание тестовых случаев с целью документирования ожидаемого поведения отдельных участков кода.
Написание такого рода документации не выходит за рамки обычного программирования с использованием XP. Единственное о чём нужно заботится – об удобочитаемости кода теста и его простоте. Такой подход отличается самопроверкой на правдивость: неправильный тест не сработает. Очень редко можно написать код, который бы впоследствии не изменился, особенно в экстремальном программировании, которое не подразумевает изменчивость требований. И даже первоначально правильно записанный комментарий может остаться забытым и, следовательно, устаревшим, при изменениях в коде.
Написание такой документации регламентируется некоторыми правилами.
1) Тест должен отражать, что делает функция, но не как это делается!
2) Тест должен быть записан в соответствии с общепринятыми стандартами кодирования.
3) Тест должен быть простым.
4) Тест должен проверять минимальное количество аспектов работы, вплоть до одного.
Достаточно полемики, перейдём к практике.

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

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное