Доклады
В погоне за качеством. Code Review
Николай Алименков, Алексей Солнцев, XP Injection
Кстати, авторы уже читали этот доклад на других конференциях, так что видео можно посмотреть здесь, не дожидаясь публикации докладов с Agile Days. Вы ничего не потеряете, на Agile Days презентация тоже была на английском, хотя доклад читался на русском, с приятным украинским акцентом). Конечно, не обошлось без известной картинки про WTF?/min.
Общее впечатление — хорошо прочитанный и насыщенный доклад про Code Review. Авторы систематически рассказали про разные аспекты процесса, но почти ничего нового я не услышал. Впрочем, доклад полезен все равно — «сверить часы» никогда не лишнее.
Из необычного:
- Code Review докладчики предлагают делать «в паре» с автором, на одной машине
Мысли на будущее:
- Еще раз подумать про распределенные системы контроля версий.
- Посмотреть средства поддержки Code Review, например Code Collaborator
Конспект
Цели Code Review
(собирали варианты ответов из зала)
- Общее владение кодом (знакомство с другими частями системы через Code Review)
- Самообучение Review’а
- Обучение автора кода через замечания
- Поиск общего видения (одна голова хорошо, а две — лучше!)
- Мотивация на качество для автора кода
- Приведение кода к стандартам
- Улучшение качества кода в широком смысле
- Устранение ошибок / проверка завершенности задачи
Возможные негативные последствия/проблемы
- Holy Wars
- Межличностные конфликты
- Code review может быть очень скучным
Для предотвращения межличностных конфликтов следует всегда применять принцип «Review кода, а не автора»
Варианты организации Code Review
- «Папа рядом» — старший разработчик осуществляет review в неопытной команде
- именно в этом случае очень легко вызвать отвращение Code Review
- Автор ищет reviewer’а сам
- может всегда выбирать «удобного человека»
- Review по контракту — пары выбираются в начале итерации, на следующей — меняются
- Control Center — менеджер распределяет задачи
- может быть очень эффективным
- SWAT — отдельный отдел Code Review
- Все Agile-гуру сильно не одобряют этот вариант
- «Все смотрят всех» — задачи по Code Review свободно берутся любым разработчиком
- «Связи на стороне» — кросс-командное ревью
- На регулярной основе делается очень тяжело
- Так делали review TN-ERP
Способы Code Review
- От автора — автор рассказывает, что же он сделал
Быстро
Автор может намеренно обходить скользкие моменты
Автор невольно навязывает свою логику рассуждений
Оба способа могут дополняться средствами IDE или специальным средствами
Направления и площадь Code Review
- Можно начинать Review
- От интерфейса (мой любимый способ)
- От тестов
- От кода
- Можно смотреть
- разницу (diff)
- готовое решение
Метрики
Сейчас уже не вспомню книжку (есть в презентации), оттуда авторы приводят следующие метрики:
Для эффективного review
- процесс должен занимать не боее часа
- затрагиваться должно не более 500 строчек кода
- В одном коммите не должно быть более 400 строчек
Tips and Tricks
- Делать review до или после COMMIT?
- авторы предлагают делать ДО, разрабатывая в отдельной ветке
- В RMS это не так, особых неудобств не испытваем
- Делать чек-листы
- Использовать статический анализ кода
- например, для проверки соответствия стандартам кодирования, чтобы не тратить время проверяющего
- Выделять большие исправления после Review в отдельную задачу
- Некритичные замечания исправлять самому проверяющему
Ретроспективы. Настраиваем наш процесс разработки
Сергей Дмитриев.
Я пришел под самый конец, так что единственная ценная мысль. который успел выхватить, это предложение по возможности использовать внешнего модератора, причем не только для ретроспективы, но для любых собраний вообще. Интересно, что в книжке(Agile Retrospectives:Making Good Teams Great про ретроспективу, авторы предлагают выбирать на роль ведущего наименее вовлеченного в обсуждаемые события участника команды.
Архитектура в Agile: переосмысляя идею модульности и компонентности
Андрей Бибичев.
- Презентация
- Документ на slideshare.net (Спасибо Диме Белобородову за ссылку)
Хороший доклад про паттерны и антипаттерны ООП. Интересно, однако, что внедрение многих хороших упомянутых практик в RMS (и в ЗИС вообще) началось по инициативе «снизу», а не пришло из TechEvol.
Вполне можно использовать как справочник или мантру для размышления каждый вечер
Общее
- + Side-effects
- + Избыточная область видимости
- + Мутабельность всего и вся
- + Большие глобальные контексты
- God-класс
- Огромные классы, которые умеют «все». Их рост все труднее остановить, так как новую функциональность становится все проще реализовать внутри такого класса и все сложнее вне его.
- Может помочь паттерн State (GoF)
- В RMS пример такого класс — InitialDataTestBase, базовый класс тестов с деревней
- Огромные функции
- Андрей привел пример из Open-Source проекта, функцию длиной 9520 строк
Взаимодействие классов
- Длинные руки объектов = длинные цепочки вызовов по большим графам объектов
Как бороться?
- Inversion of Control (наиболее предпочитаемый метод — через конструктор)
- Law of Demeter
- Принцип «Tell, don’t ask»
- рекомендую посмотреть пример из презентации
Наследование
Способы:
- Общие данные + helper-методы к ним
- чаще всего наследников мало
- не предполагаться написание новых наследников
- сам базовый класс в API никак не фигурирует
- правки наследников рушат базовый
- Расширение функциональности за счет перекрытия виртуальных методов
- Отдельная проблема — когда вызывать базовую реализацию в перекрытом методе, «до» или «после»
- Очень тяжело, если на n+1 уровне нужно что-то изменить
- Наследование как отношение «is»
- Методы добавляют новое поведение
- иногда очень тяжело правильно понять, к какой иерархии отнести класс, цена ошибки очень высока
По возможности, от наследования лучше отказываться:
- Interface over inheritance
- Composition over Inheritance
- Delegation over Inhertance
Что еще
- AOP
- Design by contract
- Хорошо не статическим проверками, а тем, что программист задумывается над тем что пишет
- Инструмент .NET — Microsoft Code Contracts
- Варианты проверок: предусловия, постусловия, инварианты
Свободное обсуждение разных тем
- Должен был быть доклад Антона Бевзюка «Архитектура для автоматизированного тестирования UI», который обещал быть интересным, но Антон не приехал(
Толку было не очень много. Обсуждали по 5-10 минут следующие темы:
- Электронная или реальная доски (выяснили, что лучше и такая и такая)
- Длинный скучный Daily Scrum (у девушки команда на 15 человек, делающая разные проекты). Очевидный вывод — делить команду
- Agile при работе с гос. заказчиком (ничего особо полезного)
- Test-Driven Development (тоже ничего особо полезного)
Domain Driven Design в условиях разработки распределенных приложений
Николай Гребнев
Обзорный доклад на тему применимости DDD в распределенных приложениях. Добротно, но без откровений. Также было заметно, что аудиторию разочаровало отсутствие хотя бы упоминания новых подходов (типа CQRS).
Модель системы — архитектура для Agile-разработки
Максим Цепков
Мне очень понравилось, хотя не уверен, что все было понятно слушателям вне контекста учета/торговых сетей. Для себя же мне было очень полезно структурировать (хоть бы услышать названия) практики, которые мы уже давно применяем, плюс было кое-что новое.
Основные моменты (лучше смотреть видео/презентацию):
- Макс упомянул о такое практике XP как «метафора системы», понятие хорошо раскрыто и проиллюстрировано в докладе
- Нужно использовать разные диаграммы/иллюстрации/взгляды для разных систем и разных случаев. Нотация не так важна как понятность.
- Стандартные диаграммы (проекции) используемые в ЗИС:
- диаграмма классов (скорее, на мой взгляд, сущностей)
- диаграмма учета
- диаграмма состояний документов
- Некоторые правила
- Для простоты и гибкости приходится отказываться от case-средства
- нельзя использовать технические коды на диаграммах
- активно использовать цветовое кодирование
- детализация только там, где необходимо
Модель принятия инженерных решений: ключ к ответам на технические вопросы
Евгений Кривошеев, ScrumTrek
Достаточно интересный и познавательный, но малополезный на практике (ИМХО) доклад.
Что можно попробовать:
- оформить Architecture Guideline — руководство по принятию архитектурных решений
- сформулировать хотя бы устно требования по надежности, производительности и другим нефункциональным требованиям.
Антипаттерны:
- «Категорическое мышление»
- Неспособность обосновать инженерное решение — хотя бы на словах оттрасировать к (нефункциональным требованиям)
- Неверный акцент усилий (слишком много дизайна/аналитики перед разработкой и т. п. — аналогично потерям в Lean)
- Overengeneering (тоже потери)
Модель компетентности
Гибкая теория ограничений
Борис Вольфсон
Доклад про теорию ограничений Голдратта. Полезных мыслей по его результатам не возникло.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
