Обзор инженерных практик

Software engeneering - 

разработка программного обеспечения

Agile-манифест разработки программного обеспечения

​

Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану 

 

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

 

 

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

 

Agile-манифест разработки программного обеспечения

​

Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану 

 

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

 

 

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

 

Принципы Agile-манифеста

1. Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.

2. Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.

3. Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.

4. На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.

5. Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.

6. Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.

7. Работающий продукт — основной показатель прогресса.

8. Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.

9. Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.

10. Простота — искусство минимизации лишней работы — крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.

12. Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.

Принципы Agile-манифеста

1. Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.

2. Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.

3. Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.

4. На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.

5. Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.

6. Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.

7. Работающий продукт — основной показатель прогресса.

8. Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.

9. Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.

10. Простота — искусство минимизации лишней работы — крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.

12. Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.

 Разработка продуктов

О чем это?

• Автоматическое тестирование
  • Модульное
  • Интеграционное
  • Нагрузочное
  • ...
• TDD/A-TDD/BDD
• Непрерывная интеграция (CI)
• Непрерывная поставка (CD)
• Парное программирование
• Рефакторинг
• Устойчивый темп

О Тестировании

Henrik Kniberg, Lean from the Trenches, pp. 46-47

Roy Osherove The Art of Unit Testing, Second Edition, p202

2 команды

Виды тестов

• Unit (Модульные)
• Integration (Интеграционные)
• Acceptance (Приёмочные)
• Component
• Functional (Функциональные)
• Smoke (Дымовые)
• Research (Исследовательские)
• Stress (Нагрузочные)
• Manual (Ручные)
• Property 
• GUI (Интерфейсные)
• End-to-end (E2E)
• Split testing
• ...

Пирамида тестирования

Анти-паттерн автотестов

Свойства хороших автотестов

• Достоверные
• Легко сопровождать
• Легко прочитать

Модульные тесты

• Быстрые
• Изолированные
• 1 тест - один кейс
• Arrange-Act-Assert (ААА)
• Безопасная зеленая зона
• Быстрые
• Надежные
• Легко читаются (коридорный тест)

Тест-дублеры

• Fake = [Stub, Mock]
• Stub (Заглушка) - заменяет поведение заменой вызова
• Mock (Имитация) - имитирует сложное поведение, отслеживают вызовы методов, как правило, реализуются при помощи готовых фреймворков

Интеграционные тесты

Покрытие кода (code coverage)

• < 20% - сигнал, что отсутствует большое количество тестов
• надо помнить что любые метрики читятся

Test first

• Сначала пишем тест
  • TEST FAIL 
• Пишем код
  • TEST PASS

TDD

Приемочные тесты

• Specification by Example
  • Живая документация
•  Cucumber

A-TDD

UI тестирование

• Selenium/webdriver

Refactoring

 Разработчики изменяют структуру кода без изменения её поведения для избавления от дублирования, улучшения коммуникации, упрощения или добавления гибкости

Continuous Integration

• Непрерывная интеграция кода - каждый интегрирует свой код в общую ветку не реже, чем 1 раз в день
• #nobranches
• http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

Система контроля версий (VCS)

позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое

 Git flow

Как интегрировать?

• Получить последнюю версию кода
• Собрать локально
• Запустить тесты
• Починить всё, что сломалось
• Закомитить изменения

Инструменты для CI

• VCS (svn, git, hg и тд)
• Autobuild (ant, cmake, sbt, ...)
• Jenkins (Hudson)
• Team City
• TFS
• ...

Continuous Delivery Deployment

Тестирование в бою

А/B тестирование

Code Review

Цель code review - выровнять знания, 

обсуждение кода в парах

Парное программированиеПарная работа

• Непрерывное code review

Чистый код

• Lean's 5S
  • Грамотный выбор имён
  • Код там, где он должен быть
  • Код не должен быть загромождён
  • Размышлять о работе
  • Единый стиль кодирования
• DRY (Don't Repeat Yourself)
• YAGNI (You Ain't Gona Need It)
• SOLID (single responsibility, open-closed, Liskov substitution, interface segregation и dependency inversion)
• KISS (Keep It Stupid Simple)

Общее владение

Кто угодно может менять что угодно в любой момент времени

Рефакторинг

Парное

программирование

Автоматическое

тестирование

Стандарты

кодирования

Непрерывная

интеграция

Общее

владение

Стандарты

Разработчики пишут код всегда в соответствии с правилами подчеркивающими коммуникацию через код

Устойчивый темп

• Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно
• Одна из практик XP: 40-часовая рабочая неделя 

DevOps

Вопрос к вам:

Что из озвученного сегодня вы будете применять у себя в работе и как?  

(3 минуты)

Что почитать?

• https://less.works/ru/less/technical-excellence/index.html
• https://cleancoders.com/
• https://martinfowler.com/