Software engineering

Writing a 200-line script on your own is programming; a team of 50 developing millions of lines of code for years, testing them and shipping updates every week without breaking anything is software engineering. The main difficulty here is not algorithms but complexity, changing requirements and communication between people. In this lesson we learn how professional teams manage these problems.

The life cycle: from waterfall to agile

1. 1
   Requirements

   What must the system do (functional), and how well (speed, security — non-functional)?

2. 2
   Design

   Architecture, modules, database, interfaces.

3. 3
   Implementation

   Writing code, code review, version control.

4. 4
   Testing

   Unit, integration, system and acceptance tests.

5. 5
   Deployment and maintenance

   Release, monitoring, bug fixes and new requirements — the longest part of a system's life.

The Agile Manifesto of 2001 puts working software, collaboration with the customer and readiness for change first. The most popular agile framework is Scrum. It has three roles: the Product Owner (manages the Product Backlog and priorities), the Scrum Master (supports the process and removes obstacles) and the Developers (the team doing the work). Work proceeds in sprints — fixed periods of up to one month: Sprint Planning, a 15-minute Daily Scrum every day, and at the end the Sprint Review (showing the result) and the Retrospective (improving the process).

Version control with Git

Git is a distributed version control system: every developer's computer holds a complete repository with the whole history. A commit is a “snapshot” of the project (changes, author, time, message); commits form a chain and each is named by a hash. A branch is a movable pointer to a commit: you build a new feature on its own branch and, when it is ready, send it for review with a pull request and merge it into the main branch.

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

Testing

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 and code review

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

Code review means another developer checks a change before it reaches the main branch. The reviewer looks at correctness, tests, readability, security and design; style should be checked by automatic tools (linters, formatters). Besides catching bugs, reviews spread knowledge through the team: every part of the system is known by at least two people. Small pull requests (under a few hundred lines) get read more carefully.