Что такое экстремальное программирование?
Экстремальное программирование - это дисциплина разработки программного обеспечения, которая объединяет людей для более продуктивного производства высококачественного программного обеспечения.
- «Объяснение экстремального программирования»
Экстремальное программирование выводит лучшие практики традиционных методологий программной инженерии на «экстремальные» уровни, отсюда и название. Обычно его называют XP. Прежде чем вдаваться в подробности, позвольте мне рассказать вам предысторию.
Недавно я посетил четырехдневный семинар Экстремальное программирование для разработчиков в ThoughtWorks. Это хорошее место, заполненное кучкой энтузиастов XP, которые увлечены своим делом и любят делиться этим с сообществом. Я получил удовольствие от проведенного там времени и многому научился. Это мой первый опыт работы с XP. Это не исчерпывающая статья по XP. Это просто моя попытка продолжить их философию обмена и записи моего опыта на семинарах. Хорошо, вернемся к нашему обсуждению ...
Каковы методологии разработки программного обеспечения? Понимаете, написание кода - это не конец программирования. Это должен быть чистый код. Он должен хорошо работать в системе, гарантируя, что он не нарушит код, написанный другими. Он должен быть протестирован как с точки зрения кода, так и с точки зрения функциональности. Мы должны следить за тем, чтобы не было проблем с безопасностью, и постоянно доставлять это клиентам. В дополнение к этому, нам необходимо интегрировать полученные отзывы и продвигать проект в направлении изменения требований клиентов. Но, в конце концов, нам нужно убедиться, что нам нравится заниматься любимым делом - «программированием». Достичь этого сложно, особенно когда речь идет о сложных проектах с огромными командами, поскольку все может быстро стать хаотичным.
Процессы и методологии доводят это безумие до метода.
Эти методики представляют собой рекомендации и предложения. В течение определенного периода времени люди наблюдали закономерности, формировали вокруг них структуру, давали ей имя, чтобы мы могли идентифицировать и прилагать сознательные усилия, чтобы следовать им. XP - одна из таких методологий, и она подпадает под действие гибкой разработки программного обеспечения. Это не установленные процедуры, которые вам нужно применять в своей команде для получения быстрых результатов.
Кент Бек - создатель Extreme Programming и один из 17 первых подписантов Agile Manifesto.
Прочтите об agile манифесте и двенадцати принципах.
ЗАРОЖДЕНИЕ
Несмотря на то, что существуют разные типы оценок и разные способы определения требований к проекту, и они различаются для разных компаний, команд и проектов, начало является одним из популярных способов инициирования проекта. Вначале клиенты, владельцы продуктов, бизнес-аналитики, архитекторы, разработчики и аналитики качества собираются вместе и обсуждают потребности клиентов, технологии и т. Д. Это оценка требований проекта на очень высоком уровне. истории (функциональность) и их размер (количество баллов) [малый (1 балл), средний (2 балла) и большой (4 балла)] и исходная скорость команды (сколько очков каждая команда может набрать за одну итерацию) обсуждаются. На основании этого делается оценка проекта.
ВСТАНЬТЕ
Стенд-ап - это не встреча. У стендапа есть определенные цели, процедуры и практика. Как следует из названия, стоя следует проводить, когда вся команда должна стоять вместе, предпочтительно на рабочем месте, в отличие от стандартной встречи, которая проводится на сидячей конференции. Типичное выступление не должно превышать 15 минут.
Stand-up помогает вам поделиться пониманием целей, проблем и улучшений, таким образом, координируя усилия, и помогает каждому идентифицировать себя как команду. Люди , которым интересно узнать о статусе проекта или внести в него свой вклад, должны присутствовать на нем. Стендапы не направлены на то, чтобы сообщить менеджеру, это члены команды делятся своим статусом со всей командой на основе «препятствий вчера-сегодня”. Хотя есть много способов интерпретировать это, простая структура
- Что я сделал вчера?
- Что я буду делать сегодня?
- Какие препятствия мешают моему прогрессу?
Хотя люди могут сразу же приступить к решению проблемы, услышав о препятствиях, лучше отключить это от сети.
ПАРНОЕ ПРОГРАММИРОВАНИЕ
В парном программировании всегда два человека работают над одним фрагментом кода одновременно на одной машине. Того, кто пишет код, называют драйвером, а другой постоянно просматривает его по мере написания, его называют навигатором. Они постоянно меняются ролями. Ключевое преимущество - качество кода. Он предлагает наилучшее возможное решение, поскольку два ума лучше, чем один. Это снижает фактор попадания в автобус, заставляя членов команды делиться знаниями и узнавать обо всем проекте. Это улучшает динамику коллектива.
Старайтесь избегать некоторых негативных шаблонов, таких как супермен, водитель на заднем сиденье, король коротких путей, чтобы парное программирование было эффективным. Сложность проблемы и опыт вовлеченных людей определяют эффективность парного программирования. Матрица сопряжения - это один из ключевых источников информации, используемый для того, чтобы убедиться, что все в команде объединяются в пары для получения максимальной выгоды.
Разработка через тестирование (TDD)
Это ключевой компонент XP. Цикл программирования начинается с написания модульных тестов. Модульные тесты - это тесты, написанные для наименьшего фрагмента кода, которые можно протестировать независимо. Вы пишете тестовые примеры для реализаций, пишете код, чтобы они прошли, и реорганизуете его.
Для человека, который не делал TDD или никогда не писал тестовых примеров, это может показаться контрпродуктивным. Причина в том, чтобы сделать тестирование частью процесса разработки, а не рассматривать его как что-то, что нужно сделать в конце. Написание тестов для всех случаев может показаться сложным, но вы должны убедиться, что охватываете достаточно. Стандартное эмпирическое правило: по крайней мере, один тестовый пример должен завершиться неудачно, если одна строка кода была изменена. Приложенные вами усилия будут полезны в долгосрочной перспективе. TDD требует минимального предварительного проектирования и помогает вам со временем развивать дизайн.
Хорошие тестовые примеры должны охватывать все возможные ошибки, но стараться выполнить их за минимально возможное время. Для достижения этой цели с минимальными усилиями доступно множество фреймворков для тестирования.
РЕФАКТОРИНГ
Рефакторинг - это дисциплинированный метод реструктуризации существующей части кода, изменения его внутренней структуры без изменения его внешнего поведения.
- Мартин Фаулер.
Согласно методологиям TDD и XP вы должны реализовать функции с минимальным рабочим кодом. Как только это будет сделано, вы можете вернуться и улучшить свой код. Позвольте дизайну развиваться исходя из требований, не занимайтесь предварительным проектированием. Не думайте о будущих требованиях, просто делайте минимум необходимого.
На этапе рефакторинга нужно искать запахи кода. Запахи кода - это предупреждающие знаки в вашем коде. Прочтите о некоторых запахах кода и развивайте свой кодовый нюх.
ТЕСТИРОВАНИЕ
В рамках TDD мы пишем как можно больше модульных тестов, и весь наш код запускается против него каждый раз, когда мы делаем сборку. Это лишь часть всего диапазона тестирования. Вам необходимо провести другие виды тестирования, такие как приемочные тесты, тесты безопасности, стресс-тесты, интеграционные тесты ...
Нам нужно проверить, как разные юниты играют вместе, написав интеграционные тесты. Приемочные испытания проводятся, чтобы выяснить, работают ли реализованные функции так, как от них ожидают. Как следует из названия, тесты безопасности предназначены для проверки устойчивости кода к любым вредоносным атакам. Стресс-тесты написаны, чтобы определить способность сервера противостоять большим нагрузкам и выяснить, какая часть кода вызывает его сбой.
CI/CD
CI / CD означает непрерывную интеграцию, непрерывную доставку и непрерывное развертывание. Непрерывная интеграция побуждает членов команды часто интегрировать работу и автоматизировать задачу по созданию кода, статическому анализу кода, запуску модульных тестов и т. д. функциональные тестовые примеры… и т. д. В Непрерывной доставке и Непрерывном развертывании основное внимание уделяется переносу сборки в производственную среду клиента. Если непрерывная доставка - это запланированное развертывание, которое происходит в цикле выпуска функций продукта (может быть еженедельный или ежемесячный выпуск), непрерывное развертывание подталкивает сборку каждый раз, когда код регистрируется в репозитории.
Некоторые методы CI / CD поддерживают единый репозиторий, в котором доступно все, что необходимо для сборки, и каждый фиксируется в основном репозитории каждый день. Автоматизируйте сборку с помощью инструментов, доступных для конкретной платформы. Сделайте свою сборку самотестирующейся, написав модульные тесты, функциональные тесты с использованием фреймворков тестирования. Делайте сборки быстро. Убедитесь, что всем известен статус сборки и доступ к сборкам.
CI / CD устраняет утомительные ручные задачи и помогает настроить автоматизированный способ интеграции, сборки и развертывания. В CI / CD вы настраиваете конвейер. Конвейер - это не что иное, как набор задач, которые должны выполняться с момента, когда вы отправили свой код в основную ветвь, до того, как финальная сборка будет развернута на сервере, что делает продукт живым. Ранняя обратная связь - это ключ к CI / CD.
Ретро
Ретро - это аббревиатура от ретроспективы. Ретро происходит каждые несколько недель или месяцев, в зависимости от требований команды. Ретро - это место, где команда обсуждает состояние проекта. Они обсуждают успешные вопросы и проблемы, с которыми они сталкиваются. Команда придумывает список действий для решения проблем и назначает участника для работы над этим и постоянно проверяет наличие обновлений. Есть множество способов сделать это. В течение четырех дней семинаров мы каждый день сталкивались с новым стилем ретро, включая удаленное ретро, которое имитируется во время видеоконференции.
В конечном счете, «гибкое программирование», «экстремальное программирование», «спиральное развитие» и «методология водопада» - все это просто ярлыки. На самом деле в большинстве программных проектов используются определенные аспекты этих методологий в зависимости от требований проекта, и все они основаны на надежных принципах и практиках разработки программного обеспечения.
Команда мастерской XP проделала фантастическую работу, объяснив принципы и заставив нас понять и испытать способ работы XP. Если у вас есть возможность посетить семинар, не упустите его. Это действительно того стоит.
Прошло 3 недели с тех пор, как я посетил семинар, и все, что я мог реализовать на работе, - это стоять. Но да, неплохое начало. TDD - это основной компонент, который может изменить способ написания кода. Я собираюсь включить TDD в свой рабочий процесс и напишу о своем опыте. Будьте на связи.
Ссылки
Встаньте:
Рефакторинг:
CI/CD:
Спасибо Викрам за то, что прочитал мои черновики и отрегулировал их.
