Евгений Рыжков. Еще раз про качество.

https://www.youtube.com/watch?v=TIRzBDE3_sA

Transcript

1. Еще раз про качество
   Рыжков Евгений
   , 30.08.2016
   специально для
   Deep Refactoring
   

   View Slide

2. 1. Отказ от ответствености
   ● Я работал/работаю в крупных аутсорсинговых
   сервисных конторах (это не продуктовые конторы и не
   интеграторы!).
   ● Это исключительно мой взгляд на сложившийся
   порядок вещей.
   

   View Slide

3. 2. Раскрою карты сразу
   Качественный софт делать дорого (с точки
   зрения исполнителя и заказчика) и скучно (с
   точки зрения молодых, талантливых и
   амбициозных).
   

   View Slide

4. 4. Что такое качественный софт?
   ● Все зависит от входных требований: для разных заказчиков один и тот
   же продукт будет как приемлемым, так и неприемлемым.
   ● Мало договориться о "качестве" с заказчиком до начала работ. Надо
   построить процесс так, чтобы было видно, насколько далеко продукт от
   “качественного”.
   ● Качество - ничто. Управление качеством - все.
   ● Качественный софт - это софт, качеством которого можно явно
   управлять в процессе создания.
   

   View Slide

5. 5. Управление - это информация
   ● Чтобы чем-то управлять руководителю надо получать информацию.
   ● Любой руководитель - это центр сбора информации.
   ● Информация не берется из ниоткуда: ее создают люди.
   ● На основании этой информации рассчитываются различные метрики,
   создаются отчеты, формируются бюджеты и т.п.
   ● Несохраненная информация пропадает и не может участвовать в
   управлении.
   ● Пример: учет трудозатрат (ежедневно, еженедельно, ежемесячно,
   никогда)
   

   View Slide

6. 6. Почему дорого и скучно?
   ● Попробуем разобрать один из элементов проектной деятельности с
   точки зрения заказчика, начальников программистов и самих
   программистов.
   ● За основу возьмем внутренние процессы одной достаточно крупной
   конторы...
   

   View Slide

7. 7. Управляем качеством кода
   ● Варианты: статический анализ (расчет метрик и анализ исходников,
   динамический анализ (запуск кода - тестирование).
   ● Один из методов статического анализа: code review.
   ● Вопрос к аудитории: как проводится code review?
   

   View Slide

8. 8. Что за процесс Review?
   ● Цель процесса: гарантировать соответствие промежуточных результатов требуемому уровню качества.
   ● У процесса есть модератор, который отвечает за весь процесс.
   ● Модератор:
   ○ определяет цель конкретного review.
   ○ определяет, кто должен участвовать в процессе.
   ○ находит того, кто будет делать review (если еще нет назначения).
   ○ обеспечивает доступность объектов для review (исходники, документы и т.п.) для участников.
   ○ проверяет актуальность документов, обеспечивающих процесс review.
   ○ назначает дату и время сессии, оповещает всех участников.
   ○ назначает секретаря для сессии
   ○ обеспечивает документирование и классификацию результатов.
   ○ проверяет наличие протокола сессии с подписями участников.
   ● И, конечно, протокол должен быть разослан всем и помещен в “систему документоборота” проекта.
   ● Вопрос к аудитории: а какие типы code review вы знаете?
   

   View Slide

9. 9. Примеры типов code review
   ● Informal review (выполняется на ходу, по мере того, как пишется код)
   ● Walkthrough (автор кода презентует результат непосредственно на
   сессии)
   ● Technical review (рецензент проводит анализ кода до сессии на основе
   только своего опыта; результаты обсуждаются на сессии)
   ● Inspection (рецензент проводит анализ кода до сессии, используя
   согласованные checklists; результаты обсуждаются на сессии)
   

   View Slide

10. 10. Сколько же это стоит?!
    ● Трудозатраты на создание регламентирующих документов и
    поддержание их в актуальном состоянии
    ● Трудозатраты на инспекцию кода до сессии
    ● Трудозатраты на проведение сессии (сколько там человеко-часов если
    сессия открыта для посещения всеми?)
    ● Трудозатраты на оформление результатов сессии, создание дефектов и
    отслеживание их закрытия
    

    View Slide

11. 11. А когда же кодить?!
    ● Надо быть в курсе регламентирующих документов (как называются, где
    лежат, прочитать последнюю версию)
    ● Надо кодить с учетом checklists
    ● Надо кодить с учетом стандартов
    ● Надо уметь рецензировать чужой код
    ● Надо уметь обсуждать технические проблемы
    ● Надо аккуратно вести отчетность о проделанной работы
    

    View Slide

12. 12. Имеем на выходе
    ● Для заказчика трудозатраты возрастают
    ● Для руководства бонусы снижаются
    ● Для молодых, талантливых и амбициозных программистов жизнь
    проходит мимо
    ● И еще один момент: менеджмент не всегда может правильно оценить
    реальные трудозатраты с учетом возможности управления качеством
    продукта.
    ● На выходе: писать софт качественно - очень дорого. Мало кто может
    себе это позволить.
    

    View Slide

13. У меня все
    Вопросы есть?
    

    View Slide