Программная инженерия

Написать в одиночку скрипт на 200 строк — это программирование; а когда команда из 50 человек годами развивает миллионы строк кода, тестирует их и каждую неделю выпускает обновления, ничего не ломая, — это программная инженерия. Главная трудность здесь не алгоритмы, а сложность, меняющиеся требования и общение между людьми. В этом уроке мы узнаем, как профессиональные команды справляются с этими проблемами.

Жизненный цикл: от каскада к гибким методам

1. 1
   Требования

   Что должна делать система (функциональные) и насколько хорошо (скорость, безопасность — нефункциональные)?

2. 2
   Проектирование

   Архитектура, модули, база данных, интерфейсы.

3. 3
   Реализация

   Написание кода, код-ревью, контроль версий.

4. 4
   Тестирование

   Модульные, интеграционные, системные и приёмочные тесты.

5. 5
   Развёртывание и сопровождение

   Выпуск, мониторинг, исправление ошибок и новые требования — самая долгая часть жизни системы.

Манифест Agile 2001 года ставит на первое место работающий продукт, сотрудничество с заказчиком и готовность к изменениям. Самый популярный гибкий фреймворк — Scrum. В нём три роли: Product Owner (владелец продукта — управляет Product Backlog и приоритетами), Scrum Master (помогает процессу и устраняет препятствия) и Developers (команда, выполняющая работу). Работа идёт спринтами — отрезками фиксированной длины до одного месяца: Sprint Planning, ежедневный 15-минутный Daily Scrum, а в конце Sprint Review (показ результата) и Retrospective (улучшение процесса).

Контроль версий с Git

Git — распределённая система контроля версий: на компьютере каждого разработчика хранится полный репозиторий со всей историей. Коммит — «снимок» проекта (изменения, автор, время, сообщение); коммиты образуют цепочку, и каждый назван хешем. Ветка (branch) — подвижный указатель на коммит: новую функцию делают в отдельной ветке, а когда она готова, отправляют на проверку через pull request и сливают (merge) в основную ветку.

git switch -c feature/login          # create and switch to a new branch
git add login.py
git commit -m 'Validate the login form'
git push -u origin feature/login     # then open a pull request

git switch main
git pull                             # get the reviewed and merged work
git revert 3f2a9c1                   # safely undo a bad pushed commit

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

def is_leap(year):
    return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

def buggy_is_leap(year):
    return year % 4 == 0

cases = {2024: True, 2023: False, 1900: False, 2000: True}

def run_tests(func):
    failed = [y for y, expected in cases.items() if func(y) != expected]
    return 'all passed' if not failed else 'FAILED for ' + str(failed)

print('is_leap:', run_tests(is_leap))
print('buggy_is_leap:', run_tests(buggy_is_leap))

is_leap: all passed
buggy_is_leap: FAILED for [1900]

SOLID и код-ревью

from abc import ABC, abstractmethod

class Discount(ABC):
    @abstractmethod
    def apply(self, price): ...

class NoDiscount(Discount):
    def apply(self, price):
        return price

class Percent(Discount):
    def __init__(self, p):
        self.p = p
    def apply(self, price):
        return round(price * (1 - self.p / 100), 2)

class StudentCard(Discount):
    def apply(self, price):
        return max(price - 5, 0)

def checkout(price, discount: Discount):
    return discount.apply(price)

for d in [NoDiscount(), Percent(20), StudentCard()]:
    print(type(d).__name__, checkout(50, d))

NoDiscount 50
Percent 40.0
StudentCard 45

Код-ревью — проверка изменения другим разработчиком до того, как оно попадёт в основную ветку. Рецензент смотрит на корректность, тесты, читаемость, безопасность и дизайн; стиль же должны проверять автоматические инструменты (линтеры, форматтеры). Помимо поиска ошибок, ревью распространяет знания по команде: каждую часть системы знают минимум двое. Небольшие pull request'ы (меньше нескольких сотен строк) читают внимательнее.