Практики разработки софта по-взрослому

Петр Туголуков

Практики разработки софта по-взрослому

Предисловие

Книга выросла из моей личной боли, из моего личного незнания и потребности в знаниях - как делать софт "по-взрослому"?

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

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

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

Что в этой книге такого?

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

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

Принципы

Работая над книгой, я выделил для себя несколько принципов, которым строго следовал:

• Я подаю материал так, как я бы рассказывал его друзьям за чашкой кофе: книга однозначно не претендует на академичность и даже строгий терминологический аппарат;

• Я максимально фильтровал воду: я очень не люблю слова ради слов, текст ради текста. Поэтому книга может получиться достаточно компактной;

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

• Эта книга, по сути, мой pet-проект, мой playground, на котором я практикуюсь в писательстве: не стоит ждать максимально эффективной структуры, шикарных речевых оборотов. Это всего лишь pet-проект :)

Я ожидаю, что, приступая к чтению, вы принимаете мои принципы. Это поможет сформировать корректные ожидания от книги и получить от нее максимальную пользу.

Целевая аудитория

Книга будет интересна вам, если вы:

• Тимлид команды;

• Разработчик;

• Системный администратор;

• Тестировщик;

• Системный аналитик;

Остальным тоже может быть интересно, но, возможно, в меньшей степени.

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

• Основы программирования

• Клиент-серверная архитектура;

• Опыт работы в команде;

• Системы контроля версий;

• Базовые знания инфраструктуры.

В тексте встречаются такие термины, как "балансер", "апишка", "инвалидация кеша", "метрики разработки". Полный список терминов (и IT-жаргонизмов) я привел в конце книги.

Структура книги

Всего здесь 3 основные части:

• Кратко про сами практики: их суть, проявления, характеристики;

• Работа с техническим долгом: я решил выделить это в отдельную главу, в ней рассказано много про феномен технического долга и работу с ним;

• Собственно, практики. Несколько наборов практик, разделенных по логическому принципу.

Каждая конкретная практика состоит из следующих частей:

• Эффект: краткое описание того, с чем практика может помочь;

• Детальное описание;

• Применение: нюансы и детали использования;

• Ссылки на ресурсы;

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

Дополнительно, в книге можно найти глоссарий IT-терминов и жаргонизмов, а также, так называемый "Радар практик", который поможет быстро выбрать нужную практику под вашу задачу или ситуацию.

Как читать эту книгу?

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

Введение

Инженерные практики. Определение.

Для начала - что такое "практика" в контексте IT.

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

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

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

Здесь же определим основные параметры процессов разработки и эксплуатации:

○ Скорость реализации: как быстро мы создаем и выкатываем изменение (как пример - фичу);

○ Качество: насколько созданное изменение соответствует установленным требованиям. Другими словами - как много багов имеем. Сюда же отнесем и нефункциональные требования, т.е. безопасность, масштабируемость, пропускную способность;

○ Затратность: это все затраты, которые идут на реализацию изменения и его поддержку. Сюда входит фонд оплаты труда (зарплаты), стоимость инфраструктуры, лицензии на IDE и так далее;

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

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

○ Уровень технического долга: уровень качества кода и архитектуры, влияющие на скорость внесения будущих изменений;

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

Глоссарий

• АПИ - см. API;

• Апишка - см. API;

• Баг - проблема в программе; ситуация, когда фактическое поведение отличается от ожидаемого;

• Багуля - см. Баг;

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