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

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

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} в момент инициализации платежа',
      })



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

Чем больше бизнес зависит от новых фич — тем внимательнее и строже нужно следить за качеством кода. Бывают бизнесы, которые вовсе не зависят от фич — к примеру давайте представим, что мы производим зубные щётки. От конкурентов мы отстраиваемся при помощи офлайновых вещей: дизайна щётки и упаковки, договорённостей с магазинами, баннерной рекламы. Из информационных технологий у нас есть только лендинг, чтобы рассказать потенциальным покупателям о продукте. Качество кода не так уж и важно: если доработки лендинга пойдут медленно — мы просто закажем новый.

А вот если мы делаем щётки, которые подключаются к интернету и складывают статистику чистки зубов в облако, то мы боремся с конкурентами ещё и на поле информационных технологий. И если, пока наши программисты поднимают упавший сервер, разбираясь с тоннами непонятного кода, конкурент делает СМС‑напоминание о том, что пора чистить зубы, или проходит проверку GDPR, чтобы запустить свой продукт в Германии, то мы быстро оказываемся в роли догоняющего.

Чем аккуратнее кодовая база, тем быстрее запускаются новые фичи

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Управление проектомВеб‑разработка
Отправить
Поделиться
Запинить

Рекомендуем другие советы