Этот урок — самый короткий из всех, итог всех остальных уроков. Дело в том, что говнокод в репозитории обычно следствие плохо нанятых людей, кавардака в управлении, хаотичной продуктовой разработки или банального неумения договариваться. Если вы пришли в компанию, где вам в наследство достался монолит на 300к строк, скорее всего, дело не в самом говнокоде, а у команды проблема в одном из этих направлений.

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

• Содержание урока

<aside> 👨 Когда-то давно я работал в провинциальной веб-студии, которая писала на PHP. По традиции у нас был собственный движок, на котором мы делали плохонькие сайты для региональных фирм вроде ХХХ и YYY. Конечно, ни о каком качестве кода речи не шло — ни тестов, ни CI с проверкой качества кода, ни код-ревью у нас не было. Что уж говорить, если мы даже контролем версий пользовались не для всех проектов.

Конечно, я ходил на конференции, читал книги и пытался все это изменить. Венцом моих изменений было то, что мы перешли на готовый фреймворк вместо своего велосипеда и у нас появились зачатки code quality. Тестов, CI или кода где-то за рамками контроллеров у нас так и не появилось. В итоге я вдребезги разругался с сооснователями и решил, что разработка — это вообще не мое, потому что все, что пишут в книгах, — неправда и рассказано для какого-то ненастоящего, розового мира.

Сейчас я понимаю, что совершил все ошибки, которые только можно было совершить: внедрял подходы, которые не нужны были ни агентству, ни его клиентам; продавал качество кода людям, далеким от мира ИТ; пытался продать рефакторинг клиентам, у которых сайт приносил не больше 10% продаж, и так далее.

</aside>

Немного теории — зачем нужен хороший код

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

Посмотрите на этот участок кода:

def charge(user):
  if user.subscriptions.count():
    subscription = user.subscriptions.last_active()  
    bank = Bank(user)
    if bank.charge(amount=subscription.cost):
      subscription.prolong()

Даже не зная питон, можно понять, что здесь мы снимаем с пользователя деньги за ежемесячную подписку. А теперь посмотрите на то же самое, но на проекте, за здоровьем которого никто не ухаживает:

def charge(user):
  subscription = Subscription.objects.filter(user=user, is_active=True)[-1]
  if not subscription:
    return
  order = Order.objects.create(user=user, subscription=last_subscription, created=datetime.now())
  response = requests.post('<https://bank.api/init>', dict(
    amount=subscription.cost * 100,
    order_id=order.id,
  ))
  if response['OK'] is True:
    payment_id = response['payment_id']
    new_response = requests.post('<https://bank>,api/charge', dict(
      payment_id=payment_id
    ))
    if new_response['OK'] is False:
      requests.post('htps://api.slack.com', {
        'to': '#money',
        'message': f'Не удалось оплатить подписку пользователя {user}',
      })
    else:
      subscription.due_date = datetime.now() + timdelta(month=1)
      subscription.save()
      try:
        requests.post('htps://api.slack.com', {
          'to': '#money',
          'message': f'Новая подписка пользователя {user} на сумму {subscription.cost}',
        })
      except:
        pass
  else:
      requests.post('htps://api.slack.com', {
        'to': '#money',
        'message': f'Не удалось оплатить подписку пользователя {user} в момент инициализации платежа',
      })   

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

Хороший код нужен, чтобы делать быстрые изменения.

Соответствовать потребностям бизнеса

Перегибать с качеством и читаемостью тоже не стоит. Скажем, Kafka и CQRS не нужны, если вы делаете сайт регионального турагентства — как ни вкладывайся в архитектуру, у турагентства в будущем просто не будет запроса на такое количество изменений.

Даже если вы пилите стартап, который наверняка станет единорогом, прямо сейчас сложная архитектура вам, скорее всего, не нужна. Перед бизнесом наверняка стоят более сложные проблемы: нужно привлекать клиентов, зарабатывать с них деньги, бороться с конкурентами.

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

Кстати, интересное следствие: монолиты вполне себе норм, почитайте DHH, если сомневаетесь.

Что измерять