В прошлом месяце меня пригласили провести индивидуальный семинар для одного из моих клиентов-наставников. В группу входили разработчики, тестировщики и члены команды технического менеджмента, всего около дюжины человек. Я подумал, что кое-что из того, что мы обсудили, может оказаться полезным для других, поэтому я публикую здесь некоторые заметки о семинаре. Если вы считаете, что я могу помочь вашей команде или приложению улучшиться с помощью удаленного наставничества или семинара на месте, пожалуйста, свяжитесь со мной.
Обзор их компании/продукта
Я работаю с членами команды разработчиков этой компании уже более года, но тем не менее многим в зале было полезно, чтобы старший менеджер рассказал немного о компании и ее продуктовой линейке. Эта история оказалась полезной, поскольку основная часть усилий команды была направлена не на создание новых приложений, а на расширение существующего набора продуктов. Это обсуждение также охватило многие планы и цели, которые были у компании в прошлом, что помогло объяснить многие решения, которые вошли в существующую архитектуру и дизайн системы.
Это обсуждение перешло от высокого уровня и долгосрочных рамок к более тактическим и непосредственным, поскольку техническая группа обсуждала свой текущий набор целей. Команда использовала Scrum с двухнедельными спринтами и эффективно внедряла продукт в конце практически каждого спринта. Они надеялись стать более эффективными в этих развертываниях, а также сократить время, затрачиваемое на планирование спринта. Мы кратко коснулись некоторых идей, которые могли бы помочь, которые уже стояли на повестке дня, включая непрерывную интеграцию, стратегии ветвления и канбан.
Обзор доменно-ориентированного проектирования/обсуждение
В прошлом году я помогал команде применять Основы проектирования, ориентированного на предметную область, так что это был довольно краткий обзор и обзор некоторых принципов и шаблонов, используемых в DDD. Основной продукт, над которым работает команда, спроектирован с учетом данных, а не с использованием ориентированной на предметную область n-уровневой архитектуры. Это создает проблемы при попытке перейти к более предметно-ориентированному подходу. Во время этого занятия мы обсудили ограниченные контексты, агрегаты, уровни защиты от коррупции и события предметной области (и чем они отличаются от событий между приложениями). Некоторые из вопросов, которые мы обсуждали, включали:
- Кто «владеет» данными (для концепции, которая встречается в нескольких ограниченных контекстах)?
- Как вписывается отчетность?
- Для каких сценариев этот подход является «надархитектурным»?
- Какие проблемы обслуживания связаны с этим подходом (фреймворк, другие зависимости и т. д.)?
Очевидно, что детали этих обсуждений не обязательно имеют отношение к делу в целом, но обсуждение было очень полезным для команды и организации.
Проверки кода
В рамках своих усилий по постоянному совершенствованию команда нуждалась в помощи в проведении проверки кода, чтобы максимизировать свою пользу. Команда понимала, что обзоры кода — это «хорошо», но реалии выпуска программного обеспечения часто означали, что они не проводились или проводились неэффективно. Один из методов, который они использовали с некоторым успехом, заключался в том, чтобы привлечь всю команду и попросить одного разработчика поделиться чем-то, что они сделали, что, по их мнению, было интересно. Другой заключался в том, чтобы (большая часть) команды работала со мной во время нашего еженедельного сеанса наставничества, чтобы просмотреть последние проверки.
После некоторого обсуждения команда пересмотрела документ по стандартам кодирования, который они создали ранее, и согласилась использовать его при проведении проверок. Мы говорили о стиле GitHub, использующем ветки и запросы на вытягивание для создания обсуждений отдельных обновлений кодовой базы, и рассмотрели способы применения этого подхода с использованием текущего набора инструментов команды. Мы также говорили о парном программировании как об инструменте проверки кода, для которого позже проделаем практическое упражнение.
Сопряжение, тестирование, рефакторинг
Затем я представил некоторые материалы по парному программированию и модульному тестированию (а также другим формам тестирования). Я дал некоторую инструкцию о том, когда и как рефакторить код. Затем мы разделились на 4 группы, чтобы выполнить практическое задание. Всем четырем командам было предложено решить одну и ту же задачу в виде серии шагов, причем каждый последующий шаг был скрыт до тех пор, пока не был завершен предыдущий шаг. Это мешало командам планировать слишком далеко вперед и заставляло их пересматривать свой дизайн в соответствии с новыми требованиями, как при реальной разработке приложений. Это практическое упражнение было, по моему мнению, одним из основных моментов трехдневного семинара и заняло немногим более двух часов. Каждая команда работала в рабочем пространстве одного из ее членов, а остальные члены команды толпились вокруг пространства (по большей части представьте себе L-образные кабинки). Каждые 30 минут или около того я заставлял членов команды, которые не находились на своем рабочем месте, меняться, чтобы к концу упражнения перемещающиеся члены команды были на каждой стационарной рабочей станции. Затем мы вернулись в тренировочную комнату, чтобы повторить то, что было изучено.
У этой команды не было большого опыта парного программирования. Упражнение подтвердило некоторые моменты, которые я сделал в своей лекции о важности проектирования рабочего пространства для эффективного спаривания. В целом они нашли этот опыт очень приятным, но такие вещи, как плохая раскладка мебели и незнакомая клавиатура, были препятствиями. Им также было очень интересно посмотреть, насколько разными оказались четыре дизайна, и как некоторые члены команды эффективно передавали знания, полученные от одного члена команды, другому, перекрестно опыляя идеи и помогая уменьшить разрозненность знаний и проект. автобусный фактор».
Изолированные среды и автоматизированные сборки
Одной из проблем, с которой сталкивается команда в настоящее время, является размер их базы данных. Поскольку для всех приложений используется одна база данных, и в настоящее время она включает все данные с начала времени (для приложения), в настоящее время она не подходит для локального использования. Таким образом, команда использует небольшое количество общих баз данных для разработки и тестирования. Это приводит к частым узким местам и коллизиям из-за этого ограничения. Мы рассказали о некоторых методах решения этой проблемы, в том числе о передаче схемы базы данных в систему управления версиями (используя проекты базы данных Visual Studio или что-то подобное) и написании схемы и минимального набора данных, необходимого для запуска базовой версии приложения. Команда также обсудила собственные планы по уменьшению размера основной базы данных.
В связи с этим я показал, как использовать пользовательский сценарий MSBuild для автоматизации сборки проекта локально и как это можно использовать с танцем регистрации, чтобы убедиться, что код работает до того, как он будет возвращен в общий ресурс. ветвь управления исходным кодом. Я продемонстрировал использование Jetbrains TeamCity для настройки автоматизированных сборок, использующих те же сценарии MSBuild, что и на рабочих станциях отдельных разработчиков/тестировщиков, исключая случаи, когда это работает на моей машине. Мы говорили о том, как настроить TeamCity для автоматического развертывания определенных веток в промежуточных средах, если все тесты пройдены, что позволяет раньше тестировать выпускаемый код, чем их текущий процесс ожидания выпуска выпуска до конца спринта.
Git, GitHub, ветвление и канбан
По большей части команда была незнакома с git и распределенными системами контроля версий. Я научил их основам git, ознакомился с некоторыми инструментами совместной работы GitHub и сравнил их с существующим набором инструментов команды. Я объяснил базовую стратегию ветвления для каждой функции, используя ветку dev для незавершенной работы и ветку master для кода, готового к выпуску. Я дал краткое объяснение канбана, в том числе о важности ограничения незавершенной работы и помощи в выполнении последующих задач до начала новой работы. В связи с этим я показал команде, как Huboard можно использовать с любым проектом GitHub для создания мгновенного представления рабочих элементов проекта в стиле канбан.
После этого мы были готовы попробовать эти новые инструменты в другом практическом упражнении. На этот раз мы вместе планировали продукт, создавая новый репозиторий GitHub и Huboard, а также добавляя элементы в список невыполненных работ. Мы разделились на две команды: одна отвечала за пользовательский интерфейс и настройку автоматизированных сборок и TeamCity, а другая отвечала за уровень предметной области и основные сервисные функции учений. Две группы продолжали заниматься парным программированием (или, на данный момент, более мобовым программированием), но на этот раз они также использовали ветки git для каждой добавленной проблемы/элемента работы. Затем команды создавали запросы на вытягивание вместо того, чтобы просто фиксировать в основной ветке, и требовали от другой команды проверки и утверждения их изменений, прежде чем они смогут их объединить.
Обе команды многое узнали о рабочем процессе, связанном с использованием инструментов GitHub для просмотра и обсуждения запросов на вытягивание, а также о том, как настроить и работать с Huboard для визуализации и определения приоритетов работы. Одна команда также познакомилась с самостоятельной настройкой сборок TeamCity и сценариев автоматизации MSBuild, которые они планировали добавлять в каждый из своих проектов в будущем.
Реальное моделирование предметной области
Семинар завершился некоторым моделированием предметной области будущей функции, которую команда готовила к созданию. Эта функция в настоящее время смоделирована в PDF-документе, показывающем, как может выглядеть пользовательский интерфейс. Мы обсудили некоторые сценарии, показанные на экранах, и обнаружили некоторые подразумеваемые бизнес-правила. Я рассмотрел, как эти правила могут быть встроены в модель предметной области, и протестирован с помощью модульных тестов, не задумываясь о том, как данные могут быть сохранены (сейчас или в будущем). В конце упражнения по моделированию предметной области у нас был простой набор классов, которые были небольшими и простыми для понимания. Эти классы были пригодны для тестирования и модульного тестирования, и мы смогли изолировать знания о существующей схеме данных в небольшом наборе классов инфраструктуры, предназначенных для доступа к данным.
Именно в этот момент многое из того, что обсуждалось ранее, действительно начало обретать смысл для некоторых членов команды. Некоторые из них выразили волнение по поводу того, что они с нетерпением ждут возможности применить некоторые из этих методов немедленно или в ближайшем будущем. Одними из основных тем были более совместная работа, разрушение больших общих зависимостей путем установления границ и API-интерфейсов между приложениями, а также моделирование сложности в коде, а не в данных.
Один из руководителей команды оставил мне такой отзыв:
«Знания Стива во всех областях, от разработки до рабочего процесса, очень помогли нашей команде организации и доставки. Эти знания в сочетании с его презентацией и стилем преподавания способствуют обсуждению, энтузиазму в команде и более чистому и удобному в сопровождении коду.
Спасибо за отличный мастер-класс»
Сводка
Мне было очень весело работать с этой командой, и я с нетерпением жду возможности продолжать помогать им. Мы проделали большую работу всего за три дня, и было полезно провести время с командой на месте. Мне очень нравится помогать разработчикам создавать более удобное в сопровождении программное обеспечение. Также здорово помочь компаниям увидеть, как это позволяет им быстрее приносить пользу своим клиентам и не увязнуть в техническом долге и устаревшем коде. Если вы нашли это интересным и у вас есть какие-либо вопросы, пожалуйста, оставьте комментарий или свяжитесь со мной в Твиттере. Если вы считаете, что можете помочь своей команде разработчиков программного обеспечения быстрее приносить пользу, ознакомьтесь с некоторыми из моих курсов по Pluralsight и свяжитесь со мной для удаленного обучения или оценки приложения.
