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

Направим лень в нужное русло.


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

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

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

(Часть 3) Моя первая игра в планирование: планирование на местах.
Разработка программного обеспечения, как и любой другой вид интеллектуальной деятельности, с трудом поддаётся контролю и анализу. Написание программы нельзя измерить просто количеством строк кода или временем, проведенным за компьютером. Более того, сами программисты, порой, не способны контролировать ситуацию и своевременную сдачу продуктов. Но, к счастью, в распоряжении, как менеджеров, так и программистов имеются методики планирования. Для программиста – это дополнительная уверенность в своей компетентности и способности выдержать все сроки, или, по крайней мере, возможность заранее предупредить начальство об ожидаемых задержках и трудностях. Для менеджера – способность эффективно планировать ресурсы.
Читать всё...

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

Как мне помогло модульное тестирование.
Я работал над задачей формирования команд запуска инсталляций на удалённых компьютерах. Логика заключалась в следующем: для выделенных компьютеров с помощью трёх переключателей (check box) задать команду установки или удаления компонент путём изменения текущего состояния переключателей. Это должно работать как при выборе одного компьютера, так и серии компьютеров. На листке бумаги я прикинул приблизительную иерархию задействованных классов и начал с простого теста, моделирующего базовое поведение системы. Это был тест изменения состояния одного компьютера. Следующим шагом было объявление недостающих методов и свойств. Далее, по методу светофора, были запущены компиляция и этот тест. Он, как и ожидалось, не сработал. Дальнейшее заполнение методов соответствующим кодом заставили работать этот тест. Такая же процедура была проведена и для случая выбора нескольких компьютеров. Интеграция этих классов в рабочее приложение и ассоциация их с интерфейсом пользователя были настолько просты, что заняли не более 15 минут. Справедливости ради сказать, запуск приложения и попытка отработки функциональных тестов (пока в ручном режиме) указали на небольшую недоработку. Она была зафиксирована ещё одним модульным тестом и успешно исправлена. Казалось, что всё прекрасно работало, естественно, пока это не увидел заказчик. Им был замечен небольшой просчёт в требованиях, который в принципе нельзя было предусмотреть заранее. Но я был готов принять это, и согласился с изменениями. Логики уже было написано достаточно много, но, к счастью, у меня была хорошая интуитивно понятная документация - тесты! Я определил, какие из них требуют изменений, исправил и запустил. Оказалось, что два из них выполнились успешно, а четыре нет. Это означает, что часть задействованной логики работает корректно и не требует изменений. Я начал по порядку исследовать, что необходимо изменить для выполняемости каждого теста. Таким образом, я фокусировался на маленьком участке кода, что давало мне возможность не забивать голову большим объёмом информации, чего я очень не люблю. Эти изменения в требованиях заказчика стоили мне всего двух часов работы, в то время как без тестов, одна только ручная проверка в отладчике заняла бы намного больше. Модульное тестирование - не роскошь, а жизненная необходимость!
Историю поведал Александр Федоренко.

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

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

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

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

Упражнение.

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

Адресуйте свои решения нам, lessons@xprogramming.com.ua. Будем рады увидеть не только их, но и ваши отзывы и пожелания.



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

В избранное