Your SlideShare is downloading. ×
Борьба с ошибками (TDD)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

542

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
542
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×