Персональные инструменты
 

Максим Цепков - отчет об ADD-2011/Заднее чутье разработчика

Материал из CustisWiki

Перейти к: навигация, поиск

Антон вырос от разработчика до менеджера проектов, это был его первый доклад на конференции и удачный. Большинство участников в этот слот пошли слушать доклада Орлова и Панкратова, с которыми я знаком по различным конференциям, и потому решил послушать неизвестного мне докладчика. И не пожалел.

Доклад, по сути, представляет собой некоторый список мест, где в проекте потенциально могут быть грабли и, чтобы проект был успешным, на эти места следует обращать внимание. Неизвестных для себя мест я не обнаружил. Однако, по мере рассказа вспоминал, что о некоторых из них — рассказывал новым разработчикам. А списка в компании — нет. Приведенный в докладе вполне можно взять за основу, потому что все пункты — по делу. Ну и кто-то вполне может обнаружить и новое. неизвестное для себя.

Основные места, в которых возникают грабли.

  • Пользователи — они могут портить даные из-за ошибок в системе.
  • Интеграция с внешними сервисами
  • Работа после наката обновлений

Сбои — потери — разгребание проблем.

Как избежать?

  • Типовые проблем — типовые решения. Их надо знать и делать (бэкап, например)
  • Новые проблемы — будут всегда, тут типовых решений нет. Но можно подготовиться — средства диагностики и средства восстановления. Восстановление — более-менее универсально и не зависит от конкретной проблемы.

Кто отвечает за это? Разработчик. А то он будет и расхлебывать.

Что такое «заднее чутье»?

  • Источники: Люди, ПО, Железо, Процессы
  • Возможные проблемы
  • Решения для них
  • Проверка, что решения работают (например, из бэкапа — можно поднять систему). Это — важно.

Прототип системы: нужен минимум — диагностика. В первой боевой версии — желателен максимум защиты. И далее надо постоянно поддерпживать

Дальше много частных решений.

  • Таких как мониторинг или бэкапы.
  • Протокол взаимодействия при интеграции; Проверка по контрактам входа-выхода
  • Повторение запросов, рассчитывать протоколы на это.
  • Резервные каналы синхронизации. Ннапример, с мобильного девайса, когда штатно не получается.
  • Вести логи, уметь их передавать.
  • Изоляция внешней системы — шлюз.

Работа с пользователем.

  • Механизмы восстановления. Напрмиер при ошибочном удалении или редактирвоании
  • Предусматривать возможность срезать углы, позволяя нарушать правила. Например, сохранять неконсистентные черновики.
  • Сохранять простой вариант UI
  • Обработчик ошибок верхнего уровня. Пользовательская диагностика. Интерфейс пользователя дляы ошибок.
  • Глюки из-за проигнорированной ошибки: Кидайте исключения, а не код возврата. Проверяйте контракт.
  • Уведомлять разработчика автоматически, отслеживать действия пользователя.
  • Изолировать объекты разных пользователей (usec-spec)

Релиз

  • Автоматический накат по одной кнопке
  • Блокировать работу на время релиза.
  • Порча базы патчами: бэкапы до и после, сравнение базы до и после, альфа-тест на отдельной площадке.
  • Бета-тестирование — использование новой версии частью пользователей в продакшн, пока остальные на старой версии

Поддержка

  • Разделять доступ на всех уровнях. Не из-за безопасности, а чтобы по ошибке не порушить на боевой.
  • Автоматизировать задач по поддержке. То есть специальные действия — не руками, а спец.интерфейсами доступнымпи поддержке.
  • Анализ поддержки — устранять причины часто возникающих проблем

Минимальный набор

  • исключения — throw
  • автоматический накат обновлений
  • автобекапы — и не забыть проверить, что восстанавливается
  • разделение доступа: база данных, ОС, сама система логины
  • при интеграции — логи запрос-ответ, промежуточные
  • контракты где уместно
  • уведомления о сбоях
  • аварийные каналы данных
  • инструментарий решения задач поддержки

В заключении была рекомендация книги Michael Nygard — Release It!