|
|
Строка 20: |
Строка 20: |
| [[Category:инсайд]] | | [[Category:инсайд]] |
| [[Category:AgileDays-2008]] | | [[Category:AgileDays-2008]] |
− | {{wl-publish: 2008-12-03 18:43:00 +0400 | StasFomin}} | + | {{wl-publish: 2008-12-03 18:43:00 +0400 | StasFomin}} |
| {{To-lib-silent}} | | {{To-lib-silent}} |
Текущая версия на 17:18, 7 февраля 2013
В Москве скоро пройдет AgileDays — конференция, посвященная техническим практикам гибкой разработки.
В теории применение технических практик Agile кажется очень привлекательным. Test Driven Development, Continuous Integration, Refactoringи прочие позволяют разработчиком повышать качество кода и эффективность разработки. Однако на практике возникает множество вопросов. Как делать рефакторинг в реальном проекте при отсутствии юнит тестов? Окупиться ли применение Continuous Integration? Как использовать TDD для наших технологий и архитектуре? И, наконец, как писать тесты при наличии большого объема унаследованного кода? На первой в России конференции по техническим практикам разработки мы постараемся ответить на эти вопросы. Конференция пройдет 12 декабря 2008 года в Москве с 10-00 до 19-00.
На этой конференции выступят и наши ведущие специалисты:
Андрей Бибичев — «Безудержный Refactoring: как не убиться об стену» На тему рефакторинга кода написано немало книг. Правильный рефакторинг кода поможет любой команде эффективно и безопасно модифицировать свою систему. Но не всегда рефакторинг применяется и понимается правильно. В этом докладе мы расмотрим, как делать рефакторинг с пользой для системы и при этом не «Убить себя об стену» в борьбе за качество кода.
Изюминкой доклада являются примеры – все они не модельные, а из реальных систем, находящихся в production-эксплуатации. Причем примеры будут как удачных, так и неудачных преобразований. Это тот опыт, который получен в ходе боевых действий (а не учений) и которым хочется поделиться.
Андрей Сатарин —«Введение в непрерывную интеграцию»Использование непрерывной интеграции в процессе разработки программного обеспечения обещает много преимуществ: быстрое обнаружение ошибок, устранение проблем интеграции, меньшее число дефектов. При более подробном рассмотрении оказывается, что эта практика сильно зависит от других, таких как модульное тестирование, стандарт кодирования и т.д. Множество ожидаемых преимуществ не реализуются без использования этих дополнительных практик. Складывается парадоксальная ситуация когда не ясно, имеет ли непрерывная интеграция независимую ценность или вся ценность обусловлена только «сторонними» методиками. Нет ли здесь обмана, когда под предлогом внедрения непрерывной интеграции пытаются использовать преимущества других инженерных практик?Спешите зарегистрироваться, конференция бесплатна, но помещение небольшое и количество мест ограничено!
_/_/ _/ _/ _/_/_/
_/ _/ _/_/_/ _/ _/_/ _/ _/ _/_/_/ _/ _/ _/_/_/
_/_/_/_/ _/ _/ _/ _/ _/_/_/_/ _/ _/ _/ _/ _/ _/ _/_/
_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/
_/ _/ _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/_/_/
_/ _/
_/_/ _/_/