https://youtu.be/TIRzBDE3_sA

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

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

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

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

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

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

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

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

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

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

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

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

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