Борьба с ошибками (TDD)

744 views
677 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
744
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Борьба с ошибками (TDD)

  1. 1. Ошибки в коде. Обзор. Пути решения. Малышкин Фёдор ( [email_address] ) 15 февраля 2 00 8
  2. 2. Результаты опроса разработчиков <ul><li>Вопрос: В каких частях кода возникает большее количество ошибок? </li></ul><ul><li>Варианты ответов: </li></ul><ul><li>В ранее написаном функционале, который приходится изменять (текущий проект) </li></ul><ul><li>В ранее написаном функционале, который приходится изменять (старый проект) </li></ul><ul><li>При изменении «чужого» кода </li></ul><ul><li>В совершенно новом коде </li></ul><ul><li>В точках интеграции с другими программистами </li></ul><ul><li>В местах использования «чужих» (не «наших») библиотек </li></ul>
  3. 3. Результаты опроса разработчиков <ul><li>В ранее написаном функционале, который приходится изменять (текущий проект) (6/14) (42%) </li></ul><ul><li>В ранее написаном функционале, который приходится изменять (старый проект) (4/14) (28%) </li></ul><ul><li>При изменении «чужого» кода (8/14) (57%) </li></ul><ul><li>В совершенно новом коде (5/14) (35%) </li></ul><ul><li>В точках интеграции с другими программистами (12/14) (85%) </li></ul><ul><li>В местах использования «чужих» (не «наших») библиотек (4/14) (28%) </li></ul>
  4. 4. Результаты опроса разработчиков <ul><li>В ранее написаном функционале, который приходится изменять (текущий проект) (6/14) (42%) </li></ul><ul><li>В ранее написаном функционале, который приходится изменять (старый проект) (4/14) (28%) </li></ul><ul><li>При изменении «чужого» кода (8/14) (57%) </li></ul><ul><li>В совершенно новом коде (5/14) (35%) </li></ul><ul><li>В точках интеграции с другими программистами (12/14) (85%) </li></ul><ul><li>В местах использования «чужих» (не «наших») библиотек (4/14) (28%) </li></ul>
  5. 5. Анализ записей JIRA по проекту Draftsman <ul><li>Из всех ошибок, которые были ошибками (а не некорректными реализациями требований) – около 55% были вызваны тем, что изменялся ранее написанный функционал . </li></ul>
  6. 6. Предполагаемое решение <ul><li>Написание модульных тестов и непрерывная интеграция (continuous integration). </li></ul><ul><li>Написание тестов с использованием Junit (и других библиотек xUnit серии) </li></ul><ul><li>Использование HUDSON в качестве сервера CI </li></ul>
  7. 7. Основные проблемы <ul><li>В ранее написаном функционале, который приходится изменять (текущий проект) </li></ul><ul><li>В ранее написаном функционале, который приходится изменять (старый проект) </li></ul><ul><li>Тут тесты показывают себя в полной красе – они моментально показывают не сломалась ли программа, после ваших изменений. </li></ul>
  8. 8. Модульные тесты, как средства решения других проблем <ul><li>При изменении «чужого» кода – кроме средств проверки, они являются своего рода «документацией» на «чужой» код </li></ul><ul><li>В точках интеграции с другими программистами – тесты позволяют создавать своего рода «контракт»: правила, которым должны следовать классы и методы другого программиста </li></ul><ul><li>В местах использования «чужих» (не «наших») библиотек – с помощью тестов можно проверить поведение библиотеки в запутанных местах. </li></ul>
  9. 9. Побочные эффекты модульного тестирования <ul><li>Повышения модульности классов (уход от God-класс паттерна) </li></ul><ul><li>Введение в использование интерфейсов </li></ul><ul><li>Улучшение архитектуры приложения </li></ul><ul><li>Избавление от дублирования кода </li></ul><ul><li>Повышение у программистов уровня владения языком </li></ul><ul><li>Повышение скорости разработки </li></ul><ul><li>Увеличение свободного времени </li></ul>

×