Мы начинаем свой путь программирования без каких-либо мнений и предубеждений, и наши взгляды подвержены влиянию по мере того, как мы начинаем больше узнавать о написании кода. Подавляющее большинство нашего раннего опыта (от школьных заданий до собеседований по программному обеспечению) сужают нашу призму, чтобы рассматривать только правильность и производительность кода, который мы пишем, но это еще не все.

Эта статья направлена ​​на дальнейшее формирование ваших взглядов и рассмотрение процесса программирования в ином свете.

Отказ от ответственности

  • Графики, используемые в этой статье, являются наглядным пособием. Их единственная цель — передать идею — они не получены из реальных наборов данных.
  • Старшие разработчики сочтут содержание этой статьи «зачаточным». Я бы не стал отговаривать вас от прочтения, возможно, вы найдете мои идеи «свежими». Только не ждите просветления ;)

Аспекты программирования

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

  • Помогите вам улучшить качество кода.
  • Уточните, что представляет ценность для бизнеса, а что нет.
  • Обеспечьте средства для принятия трудных решений в отношении структуры кода.
  • Улучшите общение с коллегами.

Какие аспекты создания кода мы рассматриваем?

Правильность

Это может быть первый аспект, который мы рассматриваем: будет ли мое решение работать? Правильность важна/необходима, но дорога. Для достижения этой цели мы выполняем множество упражнений:

  • Мы пишем модульные тесты и интеграционные тесты.
  • Мы инвестируем в создание автоматизированных конвейеров тестирования, чтобы блокировать развертывания и перехватывать код друзей.
  • Мы обращаемся к коллегам, чтобы выявить пробелы и ошибки в нашей логике.
  • Если кто-то сообщает об ошибке, мы тратим время на изучение и решение проблемы.

Корректность является таким центральным компонентом программирования, что большинство (если не все) методов программирования можно проследить до правильности.

Ремонтопригодность

В какой-то момент вы перейдете от написания кода, который понимаете, к написанию кода, который поймут другие (включая вас в будущем). Вы также поймете, что код — это конструкция, требующая постоянного обслуживания и рефакторинга. Нет такого понятия, как «выстрелил и забыл». Эти осознания влияют на наши решения при написании кода, и мы фокусируемся на:

  • Читаемость. Понятно ли, что делает этот код? Любой код, который нелегко понять из-за контекстуальных причин, дополняется комментариями.
  • Расширяемость. Код меняется по мере исправления ошибок и добавления функций. Может ли текущая структура кода поддерживать это изменение практически без трения?
  • Структура кода. Структура кода влияет на скорость, с которой новые разработчики осваивают кодовую базу, или на риск внесения изменений. Мы пытаемся писать четко определенные слабосвязанные компоненты.

Представление

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

  • Применение ваших знаний о структурах данных и алгоритмах.
  • Написание приложений без сохранения состояния, чтобы вы могли горизонтально масштабировать свои серверы на обычном оборудовании.
  • Использование высокопроизводительных технологий в вашей архитектуре, которые соответствуют вашему варианту использования. (Redis, Neo4j, DynamoDB и т. д.)

Ценность для бизнеса

Весь код, который мы пишем, имеет одну и только одну цель: продвигать бизнес-интересы. Понимание того, как код повлияет на бизнес в настоящем и будущем, является очень важным навыком. Рассмотрим, как практика «ежедневных развертываний» влияет на бизнес:

  • Удовлетворенность клиентов повышается, поскольку вы можете приносить больше пользы за меньшее время.
  • Плохие решения становятся менее затратными, поскольку ежедневные развертывания сокращают ваше время выполнения. Это позволяет вашей организации идти на просчитанные риски и проводить содержательные эксперименты. Ваши затраты снижаются, а конкурентное преимущество ваших компаний увеличивается.

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

Соглашения

  • Правильность, Удобство сопровождения, Производительность и Ценность для бизнеса впредь будут известны как аспекты программирования или просто фасеты. Я не утверждаю, что это полный список «граней». Они всего лишь средство, помогающее сообщить будущие идеи в этой статье.
  • Я буду использовать жирный шрифт, когда буду ссылаться на фасеты. (например, мне действительно нужно сосредоточиться на производительности при разработке определенных функций.)

Как аспекты связаны с работой

Когда мы пишем код, наша цель должна состоять в том, чтобы максимизировать потенциал роста и прибыльности бизнеса:

  • Достижение результатов, влияющих на итоговую прибыль компании, помогает завоевать доверие и авторитет. Эти достижения принесут отличные баллы в ваше резюме и отличные примеры, подтверждающие аргументы в пользу продвижения по службе.
  • Рост приносит пользу сотрудникам, которые заинтересованы в бизнесе. (например, вы можете владеть акциями компании или можете получать бонусы в зависимости от денежных показателей компании).
  • Наблюдение за ощутимым эффектом ваших усилий может быть чрезвычайно полезным, и, очевидно, увеличение прибыли не так уж плохо для бизнеса…

Упомянутые мною аспекты влияют на приток/отток денежных средств в бизнесе. Например, код становится сложным/запутанным, если мы пренебрегаем обслуживанием, и в результате на разработку функций (которые обеспечивают коммерческую ценность) уходит больше времени. Стоимость разработки функций коррелирует с ремонтопригодностью вашей кодовой базы.

Мы можем сгруппировать эти фасеты в 2 категории:

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

Легко удовлетворить все фасеты, когда кодовая база невелика, но по мере усложнения системы нам придется выбирать для удовлетворения одной фасетки за счет другой. Например, если мы отстаем от графика, нам придется делать что-то «неправильно», чтобы выпустить функцию вовремя. «Неправильный» способ может означать расслабленное тестирование, плохие методы программирования или низкую производительность.

Предположим, у нас есть список незавершенных задач; некоторые задачи сосредоточены на предоставлении ценности для бизнеса, а другие — на обслуживании. Какую стратегию расстановки приоритетов мы должны принять?

Быть жадным?

Принятие жадного подхода означает определение приоритетов задач с наибольшей ожидаемой прибылью (т. е. выбор задачи А). Это самый быстрый способ привлечь деньги в бизнес, но он не является устойчивым. Каждая функция, которую вы разрабатываете, будет стоить немного больше, чем предыдущая. В конце концов, вы достигнете точки убывающей отдачи, когда стоимость добавления новых функций превзойдет ожидаемый доход/рост:

После точки убывающей отдачи жадная стратегия расстановки приоритетов наносит вред бизнесу. Многие стартапы перенимают эту модель, стремясь захватить долю рынка. (Кто-то сказал стратегия приобретения?)

Сосредоточиться на качестве кода?

Другой крайностью может быть приоритет обслуживания и производительности (т. е. выбор задачи Б). Вы можете рассмотреть возможность использования этого подхода при погашении технического долга, но следует помнить о некоторых вещах:

  • Эта стратегия медленная и дорогая. Это так же неустойчиво, как и жадный подход, если стоимость написания/сопровождения кода не компенсируется ценностью, которую он предоставляет.
  • Медленно развивающаяся организация в конечном итоге будет вытеснена конкурентами на быстро развивающемся рынке:

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

Сосредоточьтесь на метриках.

Глобально оптимальной стратегии не существует. Стартапы должны быть жадными, когда они молоды, а организациям среднего размера в конечном итоге нужно замедлиться. Главное — сосредоточиться на том, что нужно вашему бизнесу сейчас и что может понадобиться в будущем. Мы можем использовать прокси-меры, чтобы увидеть, где бизнес испытывает трудности и где мы можем оказать влияние:

  • Если в бэклоге большое количество ошибок P0 и P1, вы можете отдать приоритет правильности.
  • Если ваше среднее/медианное время выполнения заказа превышает 3–4 дня, вы можете отдать приоритет ремонтопригодности.
  • Если время отклика вашего P90 для важных конечных точек API превышает 200 мс, вы можете отдать приоритет производительности.
  • Если ваш продукт теряет конкурентоспособность, вы можете отдать приоритет ценности для бизнеса.

Подход, ориентированный на метрики, также работает в реактивных ситуациях:

Предположим, вы отстаете от проекта. Вы должны продлить дату поставки или сократить объем. Если вы решите сократить масштаб, вам придется пойти на компромисс в отношении качества кода или отказаться от некоторых функций. Если вы решите отказаться от определенных функций, вам нужно решить, следует ли отказаться от тех, которые требуют наибольшей работы, или от тех, которые приносят наименьшую пользу. Понятно, что нужно принять много решений… и быстро. Какой лучший ход?

В таких ситуациях метрики становятся полезными эвристиками. Если вы отдаете предпочтение правильности (поскольку ваша косвенная мера, количество жалоб клиентов, слишком велико), вы можете рассмотреть возможность продления даты доставки, чтобы не отправлять код с ошибками.

Некоторые другие интересные свойства подхода, ориентированного на метрики:

Измеримый

Метрики измеримы. Вы узнаете, приносят ли ваши усилия пользу. Это гораздо надежнее, чем «доверие своей интуиции».

Легко общаться

Решения, подкрепленные метриками, хорошо доносятся до ваших коллег. «Нам нужно очистить наш код, потому что он слишком беспорядочный» не так эффективно, как «Давайте очистим наш код, чтобы мы могли сократить время выполнения заказа и сохранить конкурентоспособность».

Выравнивание

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

  • Такой подход помогает определить, над какими проектами следует работать.
  • При работе над проектом это помогает решить, какой задаче отдать приоритет.
  • При работе над задачей помогает разрешить противоречивые мнения по реализации.

Вывод

Обычно мы рассматриваем программирование как способ сказать компьютерам, что мы от них хотим. В другом контексте кодирование становится чем-то большим, чем просто. В этой статье мы рассмотрели код через призму бизнеса. Мы учитывали его правильность, удобство сопровождения, производительность и коммерческую ценность. Используя эти фасеты, мы нашли способ расставить приоритеты в коде, который мы пишем в контексте нашего бизнеса.

В другом контексте нам может понадобиться рассмотреть еще один набор фасетов. Понимание этих фасетов в соответствующем контексте и того, как эти фасеты соотносятся друг с другом, может помочь вам писать не только лучший, но и осмысленный код.