Как мы все знаем, одним из ключевых факторов, определяющих успех проекта по разработке программного обеспечения, является команда реализующая проект. В случае если команда фиксируется на весь срок проекта, никто не болеет, все работают в одно и то же время, то проблем никаких не возникает. Но в реальности, команда меняется походу проекту, в проект приходят новые люди, ключевые участники проекта уходят в самый неожиданный момент, нередки случаи, когда на время надо срочно заменить выбывшего члена команды.
Ввод нового человека в проект — это всегда риски, риски, того, что у человека окажется недостаточно квалификации, риск внесения ошибок вследствие плохого знакомства с проектом. Неожиданное отсутствие члена команды проекта может, как минимум, привести к задержке сроков, а в случае, если другие не знакомы с его фронтом работ, то возможен и крах проекта. Незаменимость членов команды, введение нового человека в проект, завышенные ожидания от разработчиков - острейшие проблемы во многих проектах по разработке ПО, а особенно сильно эти проблемы проявляются на крупных проектах, где фиксировать состав команды и избежать всех неожиданностей физически невозможно.
Существенно снизить все выше перечисленные риски возможно при правильном использовании практики Test Driven Development (TDD). TDD — это техника разработки программного обеспечения, которая предполагает активное использование модульных тестов (unit-тестов), что делает их центральной частью дизайна системы. Разработка посредством тестирования при грамотном проектировании обеспечивает не только высокое качество ПО, но и стимулирует к созданию слабосвязанной архитектуры приложения. Более того, хорошо изолированными частями системы являются классы, т. е. фактически минимально возможный элемент системы. Слабая связность системы и хорошая изолированность ее частей, позволяют разработчикам быть уверенными, что их исправления или изменения будут локальными и не приведут к падению всей системы.
Хорошее покрытие тестами, а также архитектура приложения, к которой провоцирует использование TDD, обеспечивает не только качество программного обеспечения и хорошую самодокументируемость кода, но и позволяет быть у
20. Test Driven Development — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест. (Wikipedia)
21. TDD Тесты не прошли Написать тест Написать реализацию Запустить тесты Все тесты проходят
33. Плохая документированность Документация устаревает сразу после своего написания Никто не поддерживает актуальность документации Зачастую документация вообще отсутствует
50. Вспомним риски Незаменимый разработчик «Не знал и сломал» Квалификация ниже ожидаемой Обучение новых сотрудников
51. Незаменимость vs TDD Любого человека возможно заменить: Система хорошо документирована Слабая связность Покрытие тестами
52. «Не знал и сломал» vs TDD Любые правки исходного кода безопасны: Высокая изолированность классов Обнаружение ошибок на этапе разработки Жесткое соблюдение контракта класса
53. Обучение и TDD Обучение на «боевых» задачах Скорость обучения возрастает Слабая связность Формально документированное взаимодействие в системе
54. СПАСИБО Докладчик: Николай Гребнев e-mail: ngrebnev@gmail.com slideshare.net: ngrebnev