Практики разработки софта по-взрослому
- -
- 100%
- +
Предисловие
Книга выросла из моей личной боли, из моего личного незнания и потребности в знаниях - как делать софт "по-взрослому"?
Этим вопросом я задавался еще на заре своей менеджерской карьеры, когда в качестве техлида (тимлид с более техническим уклоном) начал управлять командой и делать продукт.
Ступая шаг за шагом, я получал нужные знания, нужный опыт. Что-то я брал из книг и видео, что-то я узнавал на конференциях, но большую часть, конечно же, я получил из собственного опыта. Эта книга - квинтэссенция моих набитых шишек, слез, пота и крови в контексте разработки программного обеспечения.
Немного другой аспект книги, о котором говорит ее подзаголовок, это ответственность за принятые решения. Неверно принятые решения могут приводить к багам, инцидентам, факапам: все это не очень приятная история. Для бизнеса это может вылиться в большие финансовые потери. Практики в этой книге - это то, что я использую в своих проектах, чтобы избежать проблем со стабильностью, сроками и производительностью. Можно сказать, что я доверяю этим практикам :)
Что в этой книге такого?
Я встречал много книг по узким темам, типа проектирования, построения процессов планирования, инфраструктуры, people-менеджменту, организации тестирования и так далее. Мне же всегда не хватало чего-то, что свяжет все эти темы воедино, чего-то, что поможет решить проблему за гранью этой самой темы. Например, как тестировать софт на куче разных устройств, не имея бюджета на это; как организовать код в ситуации нескольких суб-команд или гасить технический долг, не выделяя на него много времени.
Здесь вы найдете описания конкретных практик с описанием проблем, которые они помогают решить. Читая книгу, можно заметить, что многие практики - это микс технических и процессных решений. Много практик также связаны именно с управлением командами.
Принципы
Работая над книгой, я выделил для себя несколько принципов, которым строго следовал:
• Я подаю материал так, как я бы рассказывал его друзьям за чашкой кофе: книга однозначно не претендует на академичность и даже строгий терминологический аппарат;
• Я максимально фильтровал воду: я очень не люблю слова ради слов, текст ради текста. Поэтому книга может получиться достаточно компактной;
• Я понимаю ценность и значимость практики, поэтому везде, где только возможно, я привожу примеры и именно практические рекомендации. В тоже самое время я понимаю, что невозможно привести пример на абсолютно каждый случай, поэтому читатель может либо сам раскурить свой случай, либо обратиться ко мне лично для обсуждения какого-либо кейса по контактам, указанных в секции "Об авторе";
• Эта книга, по сути, мой pet-проект, мой playground, на котором я практикуюсь в писательстве: не стоит ждать максимально эффективной структуры, шикарных речевых оборотов. Это всего лишь pet-проект :)
Я ожидаю, что, приступая к чтению, вы принимаете мои принципы. Это поможет сформировать корректные ожидания от книги и получить от нее максимальную пользу.
Целевая аудитория
Книга будет интересна вам, если вы:
• Тимлид команды;
• Разработчик;
• Системный администратор;
• Тестировщик;
• Системный аналитик;
Остальным тоже может быть интересно, но, возможно, в меньшей степени.
Стоит отметить, что книга достаточно техническая и предполагает некоторую базовую подготовку с вашей стороны:
• Основы программирования
• Клиент-серверная архитектура;
• Опыт работы в команде;
• Системы контроля версий;
• Базовые знания инфраструктуры.
В тексте встречаются такие термины, как "балансер", "апишка", "инвалидация кеша", "метрики разработки". Полный список терминов (и IT-жаргонизмов) я привел в конце книги.
Структура книги
Всего здесь 3 основные части:
• Кратко про сами практики: их суть, проявления, характеристики;
• Работа с техническим долгом: я решил выделить это в отдельную главу, в ней рассказано много про феномен технического долга и работу с ним;
• Собственно, практики. Несколько наборов практик, разделенных по логическому принципу.
Каждая конкретная практика состоит из следующих частей:
• Эффект: краткое описание того, с чем практика может помочь;
• Детальное описание;
• Применение: нюансы и детали использования;
• Ссылки на ресурсы;
По возможности я буду прилагать как можно больше ссылок на ресурсы, которые содержат детали по каждой конкретной практике. Это может быть полезно, если у вас какой-то ну очень необычный случай и вам потребуется больше деталей, чтобы правильно применить тут или иную практику.
Дополнительно, в книге можно найти глоссарий IT-терминов и жаргонизмов, а также, так называемый "Радар практик", который поможет быстро выбрать нужную практику под вашу задачу или ситуацию.
Как читать эту книгу?
Вы можете читать книгу для общего ознакомления с практиками, а также можете использовать ее как референс, обращаясь к конкретным разделам при решении проблемы: для этого используйте "Радар практик" - небольшой раздел книги, где по указанной проблеме можно найти связанные практики.
Введение
Инженерные практики. Определение.
Для начала - что такое "практика" в контексте IT.
Практика - это способ выполнения работы, показывающий эффективность и используемый для получения стабильного результата в определенных условиях.
Другими словами - некоторый шаблон, паттерн действий для конкретной ситуации. Разработчикам это может напоминать паттерны проектирования, но в контексте практик задевается не только архитектура, но и процессы и куча всего еще.
Инженерные практики (в контексте IT) - набор методик и подходов, используемых при создании и эксплуатации программного обеспечения для улучшения основных показателей этих процессов.
Здесь же определим основные параметры процессов разработки и эксплуатации:
○ Скорость реализации: как быстро мы создаем и выкатываем изменение (как пример - фичу);
○ Качество: насколько созданное изменение соответствует установленным требованиям. Другими словами - как много багов имеем. Сюда же отнесем и нефункциональные требования, т.е. безопасность, масштабируемость, пропускную способность;
○ Затратность: это все затраты, которые идут на реализацию изменения и его поддержку. Сюда входит фонд оплаты труда (зарплаты), стоимость инфраструктуры, лицензии на IDE и так далее;
○ Прогнозируемость: один из редко встречаемых критериев. Данные критерий определяет, на сколько точно мы попадает в прогнозируемые сроки. Чем точнее, тем лучше бизнес может планировать свои активности (выставки, маркетинг, реклама);
○ Оперируемость: сложность оперирования, т.е. сопровождения, работа с уже реализованными фичами. Сюда относится и техническое оперирование, (очистка/прогрев кеша, масштабирование, работа с логами) и продуктовое/функциональное оперирование (подключение новых партнеров, выгрузка отчетов, конфигурация фичей);
○ Уровень технического долга: уровень качества кода и архитектуры, влияющие на скорость внесения будущих изменений;
○ Надежность: этот критерий можно отнести к "качеству", в частности к нефункциональным требованиям. Но я его выделил в отдельный пункт целенаправленно, так как про него часто забывают, хоть он очень важен для бизнеса.
Глоссарий
• АПИ - см. API;
• Апишка - см. API;
• Баг - проблема в программе; ситуация, когда фактическое поведение отличается от ожидаемого;
• Багуля - см. Баг;
• Балансер - программное обеспечение или устройство, принимающее запросы от клиентов, распределяющее эти самые запросы между группами сервисов. Может быть как очень простым, так и умным: может распределять запросы согласно метрикам сервисов (например, с учетом загрузки), логировать все входящие запросы, умеет в очень большую пропускную способность, умеет в рейт-лимиты);
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.