Я большой фанат TypeScript. Каждый свой новый проект я предпочитаю писать на нём, а не на чистом JavaScript. В данной статье я не буду рассматривать причины выбора TypeScript или о его преимуществах и недостатках. Я хочу, чтобы данный пост стал своего рода шпаргалкой для тех, кто хочет понять, как настраивать tsconfig, разложить по полочкам его многочисленные флаги и, возможно, узнать некоторые полезные трюки.

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

Если открыть официальный референс tsconfig, то там будет полный список всех настроек, разделённых по группам. Однако, это не даёт понимания, с чего начать и что из данного обширного списка опций обязательно, а на что можно не обращать внимания (по крайней мере до поры до времени). Плюс, иногда опции сгруппированы по некому техническому, а не логическому смыслу. Например, некоторые флаги проверок можно найти в группе Strict Checks, некоторые в Linter Checks, а другие в Advanced. Это не всегда удобно для понимания.

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

Структура tsconfig

Рассмотрим структуру и некоторые особенности конфига.

• tsconfig.json состоит из двух частей. Какие-то опции необходимо указывать в root, а какие-то в compilerOptions

• tsconfig.json поддерживает комментарии. Такие IDE как WebStorm и Visual Studio Code знают об этом не выделяют комментарии как синтаксическую ошибку

• tsconfig.json поддерживает наследование. Опции можно разделить по некоторому принципу, описать их в разных файлах и объединить с помощью специальной директивы

Это болванка нашего tsconfig.json:

{  // extends позволяет обогатить опции другими опциями из указанного файла  // файлом tsconfig-checks.json займёмся во второй части статьи  "extends": "./tsconfig-checks.json",  // в корне конфига находятся project-specific опции  "compilerOptions": {    // здесь все настройки, связанные с компилятором  }}

К root опциям относится только следующие: extends, files, include, exclude, references, typeAcquisition. Из них мы будем рассматривать первые 4. Все остальные опции размещаются в compilerOptions.

Иногда в root секции конфига можно встретить такие опции как compileOnSave и ts-node. Эти опции не являются официальными и используются IDE для своих целей.

Секция root

extends

Type: string | false, default: false.

Указывает путь к файлу из которого нужно унаследовать опции. По большей части, служит инструментом упорядочивания. Можно разделить опции по некой логике, чтобы они не смешивались. Например, вынести настройки строгости в отдельный файл, как в примере болванки конфига. Однако, учитывая поддержку комментариев в tsconfig.json это можно сделать проще:

{  "compilerOptions": {    // блок базовых настроек    // блок настроек строгости  }}

Рассмотрим другой use-case, где комментариями отделаться не получится. Если необходимо создать production и development конфиги. Так бы мог выглядеть tsconfig-dev.json версия конфига:

{  "extends": "./tsconfig.json",  "compilerOptions": {    // переопределяем настройки, которые нужны только для dev режима    "sourceMap": true,    "watch": true  }}

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

Если вы решите использовать эту опцию. То увидеть итоговую, объединённую версию конфига поможет команда tsc --showConfig.

files

Type: string[] | false, default: false, связана с include.

Указать список конкретных файлов для компиляции можно использовав данную опцию.

{  "compilerOptions": {},  "files": [    "core.ts",    "app.ts"  ]}

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

include

Type string[], default: зависит от значения files, связана с exclude.

Если опция files не указана, то TypeScript будет использовать эту директиву для поиска компилируемых файлов. Если include так же не указана, то её значение будет неявно объявлено как ["**/*"]. Это означает, что поиск файлов будет осуществляться во всех папках и их подпапках. Такое поведение не оптимально, поэтому в целях производительности лучше всегда указывать конкретные пути. Можно прописывать как пути к конкретным файлам, так и паттерны путей.

{  "compilerOptions": {},  "include": [    "src/**/*",    "tests/**/*"  ]}

Если паттерны не указывают конкретных расширений, то TypeScript будет искать файлы с расширениями .ts, .tsx, and .d.ts. А если включен флаг allowJs, то ещё .js и .jsx.

Следующие форматы записей делают одно и тоже src, ./src, src/**/*. Я предпочитаю вариант ./src.

Технически, используя опции include и exclude, TypeScript сгенерирует список всех подходящих файлов и поместит их в files. Это можно наблюдать если выполнить команду tsc --showConfig.

exclude

Type: string[], default: ["nodemodules", "bowercomponents", "jspm_packages"].

Директива служит для того, чтобы исключать некоторые лишние пути или файлы, которые включились директивой include. По умолчанию, опция имеет значение путей пакетных менеджеров npm, bower и jspm, так как модули в них уже собраны. Помимо этого, TypeScript будет так же игнорировать папку из опции outDir, если она указана. Это папка, куда помещаются собранные артефакты сборки. Логично, что их нужно исключить. Если добавить свои значения в эту опцию, то необходимо не забыть восстановить умолчания. Так как пользовательские значения не объединяются со значениями по умолчанию. Другими словами, необходимо вручную указать корень модулей своего пакетного менеджера.

{  "compilerOptions": {},  "exclude": [    "node_modules",    "./src/**/*.spec.ts"  ]}

Опция exclude не может исключить файлы, указанные через files.

Опция exclude не может исключить файлы, если они импортируются в других файлах, которые не исключены.

Секция compilerOptions

target

Type: string, default: ES3, влияет на опции lib, module.

Версия стандарта ECMAScript, в которую будет скомпилирован код. Здесь большой выбор: ES3, ES5, ES6 (он же ES2015), ES2016, ES2017, ES2018, ES2019, ES2020, ESNext. Для backend приложений/пакетов подойдёт ES6, если рассчитываете только на современные версии Node.js и ES5, если хотите поддержать более старые версии. На данный момент стандарт ES6, с небольшими оговорками, поддерживается 97.29% браузеров. Так что для frontend приложений ситуация аналогичная.

module

Type: string, default: зависит от target, влияет на опцию moduleResolution.

Модульная система, которую будет использовать ваше собранное приложение. На выбор: None, CommonJS, AMD, System, UMD, ES6, ES2015, ES2020 or ESNext. Для backend приложений/пакетов подойдёт ES6 или CommonJS в зависимости от версий Node.js, которые хотите поддерживать. Для frontend приложений под современные браузеры также подходит ES6. А для поддержки более старых браузеров и для изоморфных приложений, определённо стоит выбрать UMD.

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

moduleResolution

Type: string, default: зависит от module.

Стратегия, которая будет использоваться для импорта модулей. Здесь всего две опции: node и classic. При этом classic в 99% не будет использоваться, так как это legacy. Однако, я специально упомянул этот флаг, так как он меняется в зависимости от предыдущего флага. При изменении значения module режим moduleResolution может переключиться на classic и в консоли начнут появляться сообщения об ошибках на строчках с импортами.

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

lib

Type: string[], default: зависит от target.

В зависимости от того какой target установлен в конфиге, TypeScript подключает тайпинги (*.d.ts-файлы) для поддержки соответствующих спецификаций. Например, если ваш target установлен в ES6, то TypeScript подключит поддержку array.find и прочих вещей, которые есть в стандарте. Но если target стоит ES5, то использовать метод массива find нельзя, так как его не существует в этой версии JavaScript. Можно подключить полифилы. Однако, для того, чтобы TypeScript понял, что теперь данную функциональность можно использовать, необходимо подключить необходимые тайпинги в секции lib. При этом, можно подключить как весь стандарт ES2015, так и его часть ES2015.Core (только методы find, findInex и т.д.).

Конечно, правильным выбором будет подключать тайпинги только той функциональности, для которой установлены полифилы.

Для --target ES5 подключаются: DOM, ES5, ScriptHostДля --target ES6: DOM, ES6, DOM.Iterable, ScriptHost

Как только вы что-либо добавляете в lib умолчания сбрасываются. Необходимо руками добавить то, что нужно, например DOM:

{  "compilerOptions": {    "target": "ES5",    "lib": [      "DOM",      "ES2015.Core"    ]  }}

outDir

Type: string, default: равняется корневой директории.

Конечная папка, куда будут помещаться собранные артефакты. К ним относятся: .js, .d.ts, и .js.map файлы. Если оставить не указывать значение для данной опции, то все вышеуказанные файлы будут повторять структуру исходных файлов в корне вашего проекта. В таком случае будет сложно удалять предыдущие билды и описывать .gitignore файлы. Да и кодовая база будет похожа на свалку. Советую складывать все артефакты в одну папку, которую легко удалить или заигнорировать системой контроля версий.

Если оставить опцию outDir пустой:

 module    core.js    core.ts index.js index.ts

Если указать outDir:

 dist    module   |    core.js    index.js module    core.ts index.ts

outFile

Type: string, default: none.

Судя по описанию, данная опция позволяет объединить все файлы в один. Кажется, что бандлеры вроде webpack больше не нужны Однако, опция работает только если значение module указано None, System, or AMD. К огромному сожалению, опция не будет работать с модулями CommonJS or ES6. Поэтому скорее всего использовать outFile не придётся. Так как опция выглядит максимально привлекательно, но работает не так как ожидается, я решил предупредить вас об этом гигантском подводном камне.

allowSyntheticDefaultImports

Type: boolean, default: зависит от module или esModuleInterop.

Если какая-либо библиотека не имеет default import, лоадеры вроде ts-loader или babel-loader автоматически создают их. Однако, d.ts-файлы библиотеки об этом не знают. Данный флаг говорит компилятору, что можно писать следующим образом:

// вместо такого импортаimport * as React from 'react';// можно писать такойimport React from 'react';

Опция включена по умолчанию, если включен флаг esModuleInterop или module === "system".

esModuleInterop

Type: boolean, default: false.

За счёт добавления болерплейта в выходной код, позволяет импортировать CommonJS пакеты как ES6.

// библиотека moment экспортируется только как CommonJS// пытаемся импортировать её как ES6import Moment from 'moment';// без флага esModuleInterop результат undefinedconsole.log(Moment);// c флагом результат [object Object]console.log(Moment);

Данный флаг по зависимости активирует allowSyntheticDefaultImports. Вместе они помогают избавиться от зоопарка разных импортов и писать их единообразно по всему проекту.

alwaysStrict

Type: boolean, default: зависит от strict.

Компилятор будет парсить код в strict mode и добавлять use strict в выходные файлы.

По умолчанию false, но если включен флаг strict, то true.

downlevelIteration

Type: boolean, default: false.

Спецификация ES6 добавила новый синтаксис для итерирования: цикл for / of, array spread, arguments spread. Если код проекта преобразовывается в ES5, то конструкция с циклом for / of будет преобразована в обычный for:

// код es6const str = 'Hello!';for (const s of str) {  console.log(s);}

// код es5 без downlevelIterationvar str = "Hello!";for (var _i = 0, str_1 = str; _i < str_1.length; _i++) {  var s = str_1[_i];  console.log(s);}

Однако, некоторые символы, такие как emoji кодируются с помощью двух символов. Т. е. такое преобразование в некоторых местах будет работать не так, как ожидается. Включенный флаг downlevelIteration генерирует более многословный и более "правильный", но менее производительный код. Код получается действительно очень большим, поэтому не буду занимать место на экране. Если интересно посмотреть пример, то перейдите в playground и выберете в настройках target -> es5, downlevelIteration -> true.

Для работы данного флага, необходимо, чтобы в браузере была реализация Symbol.iterator. В противном случае необходимо установить полифил.

forceConsistentCasingInFileNames

Type: boolean, default: false.

Включает режим чувствительности к регистру (case-sensitive) для импорта файлов. Таким образом, даже в case-insensitive файловых системах при попытке сделать импорт import FileManager from './FileManager.ts', если файл в действительности называется fileManager.ts, приведёт к ошибке. Перестраховаться лишний раз не повредит. TypeScript - это про строгость.

Опции секции compilerOptions, которые нужны не в каждом проекте

declaration

Type: boolean, default: false.

С помощью включения данного флага, помимо JavaScript файлов, к ним будут генерироваться файлы-аннотации, известные как d.ts-файлы или тайпинги. Благодаря тайпингам становится возможным определение типов для уже скомпилированных js файлов. Другими словами код попадает в js, а типы в d.ts-файлы. Это полезно в случае, например, если вы публикуете свой пакет в npm. Такой библиотекой смогут пользоваться разработчики, которые пишут как на чистом JavaScript, так и на TypeScript.

declarationDir

Type: string, default: none, связан с declaration.

По умолчанию тайпинги генерируются рядом с js-файлами. Используя данную опцию можно перенаправить все d.ts-файлы в отдельную папку.

emitDeclarationOnly

Type: boolean, default: false, связан с declaration.

Если по какой-то причине вам нужны только d.ts-файлы, то включение данного флага предотвратит генерацию js-файлов.

allowJs

Type: boolean, default: false.

Портировать ваш JavaScript проект на TypeScript поможет данный флаг. Активировав allowJs TypeScript компилятор будет обрабатывать не только ts файлы, но и js. Нет нужды полностью мигрировать проект, прежде чем продолжить его разработку. Можно это делать файл за файлом, просто меня расширение и добавляя типизацию. А новый функционал сразу можно писать на TypeScript.

checkJs

Type: boolean, default: false, связан с allowJs.

TypeScript будет проверять ошибки не только в ts, но и в js-файлах. Помимо встроенных тайпингов для языковых конструкций JavaScript, TS-компилятор так же умеет использовать jsDoc для анализа файлов. Я предпочитаю не использовать этот флаг, а наводить порядок в коде в момент его типизации. Однако, если в вашем проекте хорошее покрытие кода jsDoc, стоит попробовать.

С версии 4.1 при включении checkJs, флаг allowJs включается автоматически.

experimentalDecorators и emitDecoratorMetadata

Type: boolean, default: false.

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

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

Для работы emitDecoratorMetadata необходимо подтянуть в проект библиотеку reflect-metadata.

resolveJsonModule

Type: boolean, default: false.

Флаг позволяет включить возможность импортировать *.json файлы. Ничего дополнительно устанавливать не требуется.

// необходимо указывать расширение .jsonimport config from './config.json'

jsx

Type: string, default: none.

Если проект использует React, необходимо включить поддержку jsx. В подавляющем большинстве случаев будет достаточно опций react или react-native. Так же есть возможность оставить jsx-код нетронутым с помощью опции preserve или использовать кастомные преобразователи react-jsx и react-jsx.

Завершение первой части

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

Хайди хо, Кайл!

Меня зовут Диана и я бизнес-аналитик в компании Surf. В прошлом году я закончила бакалавриат факультета компьютерных наук в ВГУ: это дало мне базовые теоретические знания. Однако теория мало применима без практики: теперь набиваю шишки в настоящих проектах.

Я пришла к вам для того, чтобы поделиться опытом, который получила на своём первом боевом проекте. Мы делали банковское мобильное приложение со сложной архитектурой и кучей фич.

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

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

Не бойтесь задавать больше вопросов и просить уточнений

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

Лучше задать больше вопросов, чем что-то упустить. Например, когда работаешь над проектом, важно уточнить:

• На чьей стороне будет реализована логика: фронта, middleware, бэка?

• Как определять нужное состояние элемента? Как и где получать и обрабатывать нужные параметры?

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

• Касаются ли вашей стороны эти требования или от вас никаких доработок и не потребуется?

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

Проверяйте и перепроверяйте выполнение договорённостей

Когда в процессе проработки фичи участвует большое количество человек, это как минимум значит, что сторонам будет непросто договориться. А ещё это значит, что сложно будет уследить за всеми требованиями и договорённостями.

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

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

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

Не стесняйтесь быть настойчивым и даже назойливым, иногда вы и проджект-менеджер единственные, кто может повлиять на то, что договорённости будут выполнены в срок. Если видите, что ответов нет в оговоренное время, не стесняйтесь пинговать коллег. Иначе ожидание может сильно затянуться.

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

Пример из жизни

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

Я не акцентировала внимание бэкендеров и продакт оунера на том, насколько важно, чтобы бэк присылал нам этот признак. Когда фича должна была уже уйти в разработку, этого признака всё ещё не было и в помине, потому что ни бэк, ни сторонний сервис, к API которого мы обращались, не разработали его.

Из-за этого процесс задержался ещё на неделю, потому что пришлось потратить много времени на повторное обсуждение. В итоге решили кнопку отображать всегда:)

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

Уточняйте, как сделать проще

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

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

Френдли ремайндер

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

Будьте внимательным к потенциально проблемным требованиям

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

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

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

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

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

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

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

• Не очевидна инициализация флоу и переход между экранами.

• Нет четкого понимания логики.

Например, несколько месяцев назад мы начали обсуждение фичи без определённых требований. У продакт-оунера не было четкого понимания, что должно получиться в итоге. Это стоило нам многих часов созвонов-обсуждений и несколько раз перекроенного ТЗ.

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

Пример

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

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

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

_______

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

Вот и всё, мои маленькие хоббиты. Я поделилась с вами своей мудростью, теперь вы сами по себе. Не дрейфте, не теряйтесь, будьте настойчивы и внимательны. В добрый путь!

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

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

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

Начнем со знакомством с философией трех путей:

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

• Второй Путь - это движение по дороге улучшений за счет построения циклов обратной связи.

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

Вряд ли эти три тезиса заставили вас воскликнуть "Теперь я знаю, что мне делать со всеми моими проблемами". Тут нет серебряной пули. Эта философия предусматривает методичное и дисциплинированное выполнение ряда шагов.

О них дальше и поговорим.

Визуализируйте всю работу

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

• бизнес проекты - тип работы, которая создает ценность для конечного пользователя и/или конкурентное преимущество организации;

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

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

• незапланированные работы - три предыдущих типа работ мы планируем, в то время как четвертый появляется против нашей воли и ставит под сомнение все наши планы. Зачастую они появляются после "срочных" изменений.

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

Выявляйте ограничения

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

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

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

Устраняйте ограничения

Горы незавершенной работы указывают не только о наличии ограничений, но и увеличивают время нахождения работы в процессе. Одним из способов решения данной задачи является сократить количество новых работ, в которых задействовано ограничение. Вторым способом является расширение ограничения. Каждый производственный участок можно охарактеризовать 4 вещами: машиной, человеком, методом работы и измерениями. Соберите больше информации об ограничении, и попробуйте наиболее доступный вам вариант для его расширения. Не пытайтесь улучшать систему вне ограничения, это дает иллюзию улучшений, но не решает реальную проблему. В своей практике, я первым делом начинаю решать задачу первым методом. Если возникает ограничение в производстве, то намного быстрее сфокусироваться на том, что перед ним - генерации и проверке идей. Только убедившись, что в работу идет самое ценное я перехожу к методу расширения ограничения. Второй метод не только дороже, но и дольше. Найм и обучение человека, который потенциально поможет расширить ограничение, займет от нескольких месяцев до полугода, а количество работ в процессе вы можете ограничить за недели, иногда и быстрее.

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

Устраняйте движение против потока

Давайте опять вернемся к примеру с линией сборки. Конструкция линии не предусматривает движение в обратном направлении. Продвинутые системы производства, например Тойота, отбраковывают некачественные заготовки перед приемом в работу на каждом узле . Оператор может остановить производство, чтобы разобраться в причинах брака и убедиться в качестве последующих заготовок. Чем меньше у вас горы заготовок перед ограничением, тем быстрее вы сможете гарантировать качество и ценность каждой работы на самом медленном участке. В моей практике хорошо зарекомендовали себя чек-листы. Перед выполнением работы сотрудник проверяет, вся ли необходимая информация предоставлена. Если есть несоответствия, то он без зазрения совести возвращает ее назад. Периодически все возвраты анализируются. Какие-то проверки можно автоматизировать, чтобы задача попадала на доработку без отвлечения человека из следующего участка.

Наладьте обратную связь

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

Благодаря внедрению второго пути ваша организация способна предсказуемо доставлять ценность и совершенствовать качество поставки.

Экспериментируйте

Развитие технологий и глобализация открыла новые возможности для бизнеса. Сегодня маленький стартап из Израиля или Беларуси, может конкурировать с гигантом из США или Европы за аудиторию. Пользователь становится более избирательным, а конкуренты не дремлют. Если вы будете довольствоваться тем, что есть, то очень быстро вас догонят и перегонят. Эксперименты - основа основ для развития. Как сказал Эдисон: "Каждая неудавшаяся попытка это еще один шаг вперед". Чем больше компания экспериментирует тем выше ее шансы найти нужный подход к аудитории и монетизировать его. Это и есть ключ к третьему пути.

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

На нескольких примерах я покажу, какможно легко и эффективно создавать проекты от этапа проектирования до релиза продукта.

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

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

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

• Toolkit больше не нужен

• Живой пример

• Обзор возможностей

• Итог

Toolkit больше не нужен

Toolkit означает - в каждой команде свой хаос. Объясню почему. Когда формируется новая команда, каждый её юнит привносит свои знания. Со временем появляется набор инструментов и практик.

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

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

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

Живой пример

Frontend-разработчик Павел пришёл в новый коллектив. В прошлой команде дизайнер рисовал интерфейсы в Sketch (но у паши Винда и он использовал Lunacy), правки доносил через Google Docs, а бизнес логику показывал через Zoom.

А в новой команде используют Figma и Miro. Часть бизнес-логики показывают, через кликабельный прототип. Правки присылают в Телеграм, Slack, либо ставят в задачи в JIRA (но переписка как правило ведётся в мессенджерах).

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

Что, если Паша в прошлой команде работал в нашем инструменте, а в новой используют его же? Как Паша и команда выигрывают?

Обзор возможностей

Конкретика

Наш сервис решает ваши задачи конкретным способом, поэтому 1 раз изучив, можно использовать эти знания в любой команде. Тем более, что сервис будет интуитивно понятен всем, кто работал с PowerPoint, Miro и Figma.

Накапливаемый опыт

Наш сервис в одном месте накапливает весь ваш опыт, который вы приобретали, работая над тем или иным ИТ продуктом. Этим опытом можно делиться с другими и конечно же обращаться к нему самому.

А при стандартном подходе всё теряется, разбросано по мессенджерам, таск-трекерам, доскам, каталогам, документам и прочим местам хранения данных.

Всё в одном месте

На одной доске, с минимальным кол-ом кликов вы получаете максимум информации. К примеру, дизайнер отправляет правки по интерфейсу разработчику. Скрин экрана он загружает в слайд, внизу пишет описание, создаёт кейсы: что и куда нужно перенести или может просто поменять текст (на одном слайде может быть несколько кейсов).

Разработчик и дизайнер могут вести беседу по слайду и кейсу (как правило у второй стороны появляются уточняющие вопросы). И по итогу можно записать решение и поставить статус Готово.

Бизнес-логику теперь проще донести

Например, дизайнер при тестировании продукта нашёл несколько несоответствий в бизнес-логике. Не всегда удобно созвониться с коллегами, поэтому иногда проще записать видео экрана. Но для этого нужно опять же найти инструмент. Скачать и установить программу, научиться ей пользоваться. Хорошо, это он сделает 1 раз, но опять возвращаемся к проблеме - куда скидывать файл и где вести переписку.

Как водится, это видео полетит в мессенджер и там же будет по нему переписка. Либо в JIRA, в виде задачи, но опять же, часть вопросов будет в комментариях к задаче, а часть в переписке в мессенджерах или ещё хуже - при созвоне (половина забудется). И потом концов не соберёшь.

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

Обсуждения с командой

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

Итог

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

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

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

Для первой тысячи мы откроем premium-доступ на целый год бесплатно - после запуска MVP.

Для связи со мной Телеграм. Подробнее о сервисе в моём инстаграм.

Сказ о том, как делать не стоит. Или, как я дважды сгорал на работе

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

Но, именно данный заказ натолкнул меня на мысль, что подобным опытом стоит поделиться. Дабы, не знакомые со сферой, знали, как работает внутренняя кухня, а коллеги, как делать не стоит и почему. К тому же, перспектива Top-Down специфическая и материалов по ней практически не существует. Когда я начинал работу, никакого опыта с top-down перспективой, кроме игровой, у меня не было, что подогревало интерес.

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

Проект выполнен в жанре: Top Down Stealth - Action (уникальная смесь из серий Splinter Cell и Hotline Miami).

Движок: Love2D
Арт/Дизайн/Анимации выполнены в: Adobe Photoshop ( :) )
Художественное направление: Pixel art

Проект находится в Steam, и ознакомится с ним можно по данной ссылке: Intravenous

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

Я изготовил для проекта UI (редизайн/арт), эффекты, персонажей, анимации, тайлсеты, объекты, портреты, promo-art.
В общем, практически всё, что вы увидите в игре. Но в данной статье, речь пойдёт именно про анимации, т.к. они стали "камнем преткновения" всей разработки.

Немного о перспективе

Существует распространённое заблуждение, что "top-down" - это любой угол поворота камеры, в том числе несколько видов изометрии и, так называемая, перспектива 3/4.

Связано это с тем, что у ряда перспектив, не существует какого-то объединяющего понятия/термина отличного от "вида сверху" т.е. "Top-Down".
Отсюда и возникающие недопонимания при обсуждении того или иного проекта.

"Top-Down" (топ-даун) - это перспектива, камера в которой привязана исключительно над головой персонажа.
Примеры: GTA 1/2, Darkwood, Hotline Miami

Анимации

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

Список анимаций для всех персонажей включал в себя:

• 5 видов основного оружия (Дробовик, Обрез, MP5, UZI, AK103, M4);

• 5 видов второстепенного (Glock19, HS2000, P89, SW457, VP9);

• 5 видов уникальных приспособлений (Тазер, Переносной ЭМИ глушитель, Светошумовая граната, Осколочная граната, Пустые магазины);

• Ближний бой на всех видах оружия, в том числе и рукопашный;

• Выбивание двери;

• Idle анимации;

• Анимации смерти;

• Подбор и взаимодействие с предметами;

Уникальные для персонажа игрока:

• Перенос тел;

• Оглушение или добивание персонажей;

• Использование отмычки;

• Лаз через 2 вида препятствий;

• Движение ползком;

• Бег;

Помимо этого, существует 3 степени умения обращения с оружием (что увеличило список анимаций втрое!), которые мы условно назвали:

- Умелый; (персонаж игрока, профессиональные военные)
- Не умелый; (киллеры, наёмники)
- Абсолютно не умелый; (гангстеры, шпана)

Все 3 степени отличаются геймплейно:

- точностью при стрельбе;
- скоростью перезарядки;
- скоростью реакции на события;

Что отражается визуально, через:
- наличие лишних телодвижений при перезарядке;
- положение персонажа (стойку);

Список анимаций на каждого персонажа достигал значения 200+. Т.к. каждая анимация, даже в которой было изменён исключительно спрайт пистолета был уникальным.

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

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

Шаблон

Шаблон персонажа включал в себя:

- Голову;
- Тело;
- Руки;
- Оружие;
- Дополнительные слои (ладони/детали);
- Ноги/нижняя половина тела (отдельно);

Из которых покадрово собирался цикл анимации.

Экспорт

Существует 2 пути экспорта шаблонных анимаций.

Способ 1:

• Все части шаблона - отделены (слоями);

• Оружие легко заменяется (если позволяет анимация);

• Одежда кладётся поверх слоёв в игре;

+ Упор делается на сборку составляющих внутри движка игры;
+ Гибкость, возможность осуществлять исправления, буквально, на лету;
- Требователен к инструментарию движка;

Не совсем корректный, но отличный пример: Garage: Bad Trip.
(На самом деле, она известна своей скелетной анимацией скрещенной с Pixel-art графикой, и даже существует статья на эту тему, но я её не нашёл) ("Пес-песа" - тебя помнят!)

Способ 2:

• Все части шаблона склеены (монолитный слой);

• Оружие заменяется исключительно в исходнике (PSD/GIF файле);

• Одежда склеивается вместе с частями шаблона;

+ Упор делается на финализацию работ перед отправкой;
+ Лёгкий импорт в движок игры;
- Многократно возрастающий объём работы;
- РУТИНА;
- Не подходит проектам, в которых используется большой размер спрайтов;

Отличный пример: Hotline Miami

Как вы уже понимаете, нами был выбран 2 вариант. Почему?
На это повлиял целый ряд причин:

• Отсутствие инструментария для анимации (игра разрабатывалась на Love2D);

• Необходимость разгрузки программиста от лишней работы (переизбыток задач);

• Тримминг текстур (упаковка кадров анимации в spritesheets);

• Малый размер спрайтов;

А теперь поподробнее.

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

• Разработка инструментария для анимаций не рассматривалась вовсе, т.к. эти силы разумно было бросить на встроенный level-editor (редактор уровней) и проработку ИИ (искусственного интеллекта) врагов;
  
  

Продолжение в части 2.

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

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

В этой статье я расскажу:

• как мы не потерялись в сложном графе зависимостей;

• как спасли CI от чрезмерной нагрузки;

• что делать, если с каждым новым модулем приложение запускается всё медленнее;

• мониторинг каких показателей стоит предусмотреть и почему это необходимо.

Сложный граф зависимостей

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

Так выглядел граф зависимостей Badoo к моменту, когда у нас было около 50 модулей:

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

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

2. Сложности визуализации порождают сложности отладки. Найти фундаментальные проблемы в сложном графе зависимостей крайне непросто.

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

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

Основные характеристики утилиты:

• это консольное Swift-приложение;

• работает с xcodeproj-файлами с помощью фреймворка XcodeProj;

• понимает сторонние зависимости (мы не очень активно и охотно принимаем их в проект, но некоторые всё же используем; загружаются и собираются они через Carthage);

• включена в процессы непрерывной интеграции;

• знает о требованиях к нашему графу зависимостей и работает в соответствии с ними.

Последний пункт объясняет, почему не стоит надеяться на появление подобных утилит с открытым исходным кодом. Сегодня не существует универсальной хорошо описанной структуры проектов и их настроек, которая подойдёт всем. В разных компаниях могут отличаться различные параметры графа:

• статическая или динамическая линковка;

• инструменты поддержки сторонних зависимостей (Carthage, CocoaPods, Swift Package Manager);

• хранение ресурсов в отдельных фреймворках или на уровне приложения;

• и другие.

Поэтому, если вы смотрите в сторону 100+ модулей, на каком-то этапе вам, скорее всего, придётся задуматься о написании подобной утилиты.

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

1. Doctor. Команда проверяет, все ли зависимости корректно связаны и встроены в приложение. После исполнения мы либо получаем список ошибок в графе (например, отсутствие чего-либо в фазе Link with binaries или Embedded frameworks), либо скрипт говорит, что всё хорошо и можно двигаться дальше.

   

2. Fix. Развитие команды doctor. Эта команда в автоматическом режиме исправляет проблемы, найденные командой doctor.

   

3. Add. Добавляет зависимость между модулями. Пока у вас простое небольшое приложение, добавление зависимости между двумя фреймворками кажется простой задачей. Но когда граф сложный и многоуровневый, а вы работаете с включёнными явными зависимостями, добавление нужных зависимостей становится задачей, которую вы не захотите из раза в раз делать руками. Благодаря команде add разработчики могут просто указать два названия фреймворков (зависимый и зависящий) и все фазы сборки заполнятся необходимыми зависимостями в соответствии с графом.

Впоследствии скрипт создания нового модуля по шаблону также стал частью утилиты deps. Что мы получили в итоге?

1. Автоматизированную поддержку графа. Мы находим ошибки прямо в pre-commit hook, сохраняя стабильность и правильность графа и давая возможность разработчику в автоматическом режиме эти ошибки исправлять.

2. Упрощённое редактирование. Добавить новый модуль или связи между модулями можно одной командой, что сильно упрощает их разработку.

Непрерывная интеграция не справлялась

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

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

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

Мы безуспешно попробовали несколько подходов. Расскажу о них подробнее, чтобы вы не повторяли наши ошибки.

Очевидным решением было перестать собирать и проверять всё и всегда. Нужно было, чтобы CI проверял только то, что нужно проверить. Что не сработало:

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

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

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

   1. Те, кто на всякий случай проверяет всё.

   2. Те, кто уверен, что не мог ничего сломать.

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

В итоге мы вернулись к идее автоматизации вычисления изменений, но немного с другой стороны. У нас была утилита deps, которая знала про граф зависимостей и файлы проекта. А Git позволяла получить список изменённых файлов. Мы расширили deps командой affected, с помощью которой можно было получить список затронутых модулей, исходя из изменений, отражаемых системой контроля версий. Ещё более важно то, что она учитывала зависимости между модулями (если от затронутого модуля зависят другие модули, их тоже необходимо проверить, чтобы, например, в случае изменения интерфейса более низкого модуля верхний не перестал собираться).

Пример: изменения в блоках Регистрация и Аналитика на нашей схеме указывают на необходимость проверить также модули Чат, Sign In with Apple, Видеостриминг и само приложение.

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

В результате такой модернизации мы получили ряд бонусов:

1. Мы проверяем в CI только то, что действительно было затронуто прямо или косвенно.

2. Продолжительность CI-проверок перестала линейно зависеть от количества модулей.

3. Разработчик понимает, что его изменения могут затронуть и где нужно быть осторожным.

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

Ждём завершения Е2Е-тестов

Для приложения Badoo у нас есть более 2000 сквозных (end-to-end) тестов, которые его запускают и проходят по сценариям использования для проверки ожидаемых результатов. Если запустить все эти тесты на одной машине, то прогон всех сценариев займёт около 60 часов. Поэтому на CI все тесты запускаются параллельно насколько это позволяет количество свободных агентов.

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

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

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

Подобное решение едва ли можно назвать оптимальным, но всё же преимущества от его внедрения были ощутимы:

1. Нагрузка на CI существенно снизилась. Чтобы не быть голословным, привожу график времени, которое задача на прогон сквозных тестов провела в очереди:

   

2. Уменьшился шум инфраструктурных проблем (меньше запусков тестов меньше падений из-за зависших агентов, сломавшихся симуляторов, недостатка места и т. д.).

3. Карта модулей и их тестов стала точкой синхронизации отделов разработки и тестирования. В рамках разработки программист и тестировщик обсуждают, например, какие из имеющихся групп тестов могут подойти для проверки в том числе нового модуля.

Медленный запуск приложения

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

В середине графика видно резкое снижение времени. Причина переход на статическую линковку. С чем это связано? Инструмент динамической загрузки модулей dyld от Apple выполняет трудоёмкие задачи не совсем оптимальными способами, время исполнения которых линейно зависит от количества модулей. В этом и была основная причина замедления запуска нашего приложения: мы добавляли новые модули dyld работал всё медленнее (на графике синяя линия отражает количество добавляемых модулей).

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

Стоит сказать, что статическая линковка несёт с собой и ряд ограничений:

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

2. После перехода на статическую линковку нужно хорошенько протестировать приложение на предмет рантайм-падений. Чтобы исправить многие из них, вам просто придётся использовать не самые оптимальные параметры оптимизаций. Например, почти для всех Objective-C-модулей придётся включить флаг -all-load. Отмечу ещё раз, что решение всех этих проблем с вынесенными xcconfigами (про xcconfig в первой части) не было таким мучительным, каким могло бы быть.

Итак, мы побороли две основные проблемы, вынесли ресурсы в отдельные бандлы, поправили конфигурации сборки. В результате:

• количество модулей в приложении перестало влиять на скорость его запуска;

• размер приложения уменьшился примерно на 30%;

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

Цифры подскажут, куда двигаться дальше

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

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

• уменьшение нагрузки на CI за счёт фильтрации проверяемых модулей и умных тестов: не попадайтесь в ловушку прямой зависимости продолжительности CI-проверок от количества модулей;

• статическая линковка: скорее всего, вам придётся перейти на статическое связывание, так как уже к 50-60 модулям регресс в скорости запуска приложения станет заметен не только вам, но и вашим менеджерам.

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

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

Поэтому у нас есть график среднего времени сборки наших приложений на компьютерах разработчиков:

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

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

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

Кроме того, мы стали понимать, какое оборудование ещё подходит для работы над нашим проектом, а с каким пришло время прощаться.

Например, видно, что iMac Pro 5K 2017 года выпуска не лучшее железо для сборки Badoo, в то время как MacBook Pro 15 2018 года ещё вполне неплох.

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

Измеряем время сборки

Чтобы получать данные о продолжительности сборки на компьютерах разработчиков, мы создали специальное macOS-приложение Zuck. Оно сидит в статус-баре и следит за всеми xcactivitylog-файлами в DerivedData. xcactivitylog файлы, которые содержат ту же информацию, которую мы видим в билд-логах Xcode в непростом для парсинга формате от Apple. По ним можно понять, когда началась и закончилась сборка отдельного модуля и в какой последовательности они собирались.

В утилите есть white- и black-листы, так что мы отслеживаем только рабочие проекты. Если разработчик скачал демо-проект какой-то библиотеки с GitHub, мы не будем отправлять данные о её сборке куда-либо.

Информацию о сборке наших проектов мы передаем во внутреннюю систему аналитики, где имеется широкий инструментарий для построения графиков и анализа данных. Например, у нас есть инструмент Anomaly Detection, который предсказывает аномалии в виде слишком сильных отклонений от прогнозируемых значений. Если время сборки резко изменяется по сравнению с предыдущим днём, Core-команда получает уведомление и начинает разбираться, где и что пошло не так.

P. S. Мы дорабатываем Zuck, чтобы выпустить его в open source.

В целом измерение локального времени сборки даёт важные результаты:

• мы измеряем влияние изменений на разработчиков;

• имеем возможность сравнивать чистые и инкрементальные сборки;

• знаем, что надо улучшить;

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

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

1. Время запуска приложения. Последние версии Xcode предоставляют эту информацию в разделе Organizer. Метрика быстро укажет на появившиеся проблемы.

   

2. Размер артефактов. Эта метрика поможет быстро обнаружить проблемы линковки. Возможны случаи, когда линковщик не сообщает о том, что, например, какой-то модуль дублировался. Однако об этом скажет увеличившийся размер скомпилированного приложения. Обращайте внимание на этот график. Проще всего подобную информацию получить из CI.

   

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

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

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

Заключение

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

1. Всего сейчас у нас работают 43 iOS-разработчика.

2. Четыре из них в Core-команде.

3. Сейчас у нас два основных приложения и N экспериментальных.

4. Около 2 миллионов строк кода.

5. Около 78% из них находятся в модулях.

Последняя цифра постепенно растёт: старые фичи и переписанный legacy-код потихоньку перетекают из основного таргета приложений в модули.

В двух статьях я рекламировал вам модуляризацию, но, конечно, у неё есть свои минусы:

• усложнение процессов: вам придётся решить ряд вопросов в процессах как вашего департамента и рядовых iOS-разработчиков, так и во взаимодействии с другими департаментами: QA, CI, менеджерами продуктов и т. д.;

• в процессе перехода на модуляризацию вскроются проблемы, которых вы не ждали, всё не предусмотреть: возможно, потребуются дополнительные ресурсы и других команд;

• всё, что вы построите, будет нуждаться в дополнительной поддержке: процессы, новые внутренние инструменты кто-то должен будет за это отвечать;

• приложения, базирующиеся на модулях, сильнее зависят друг от друга. Например, при изменении чего-то в модуле работы с базой данных для приложения Badoo через несколько минут можно получить от CI сообщение о том, что в приложении Bumble не прошли тесты.

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

О плюсах модуляризации уже было сказано, но я повторюсь:

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

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

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

Напоследок скажу, что совсем не обязательно брать крупную часть приложения как первый модуль на старте внедрения модуляризации. Берите кусочки поменьше и попроще, экспериментируйте. Не стоит слепо следовать любому из примеров других компаний у всех разные подходы к разработке, и вероятность того, что вам полностью подойдёт чей-то опыт, небольшая. Обязательно развивайте инфраструктуру и мониторьте результаты. Успехов!

Привет Хабр! В этот пост я хочу вынести опыт на тему начинания в сфере тестирования. Здесь не будут описаны техники и правила - это уже давно есть не только на Хабре и полно учебных курсов как платных, так и бесплатных.

Я захотел стать тестировщиком

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

Я решил стать тестировщиком

Когда решились стать тестировщиком, то просто потребляйте информацию - можно читать книги и Хабр или смотреть видео. Неважно. Главное, узнать что такое тестирование как можно подробнее и научиться тестировать тот же карандаш. Несмотря на заезженность, на собеседовании может показать бэкграунд. Также, немаловажно это общаться с единомышленниками, так как при общении с сообществом узнаёшь много нового и структурируется ранее полученная информация.

Правда, в просто потребляйте информацию есть огромная проблема. Она заключается в том, что многие ресурсы в каких-то вопросах дают разные ответы. Я бы посоветовал так - изучите информацию на основе какого-то авторитетного определённого ресурса и далее на собеседованиях говорите: согласно {наименование_ресурса} я понимаю так... и тому подобное. Авторитетным ресурсом можно использовать книгу или сайты testbase.ru, software-testing.ru, а если есть желание, то можете изучать с помощью силлабуса ISTQB.

Инструменты

С чего начать? С Linux? Или Java? А может Docker?

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

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

Опыт

Если всё замечательно с софт скиллами, выполняйте любые задачи для набивания руки. Пишите тест-кейсы к сайту 2ГИС, пишите код для автотестов на главной Яндекса. Неважно где писать, важно чтоб хоть что-то было и это важно для джуна самого.Будут ли рассматривать ваши наработки? Скорее всего, нет.

Хочтите чтоб кто-то проверил? Попробуйте написать в телеграм чат QA_Junior.

Резюме

Главное, указать именно релевантный опыт, умение работать с инструментами, знание технологий и описать всё ёмко. Если 10 лет работали в продажах и 2 года водителем, то об этом стоит написать в резюме, чтоб указать что работал, а не сидел на печи: 12 лет не релевантного опыта.

Собеседование

Прежде, чем идти на собеседование, учтите несколько фактов:

• Тестировщик - это лицо помогающее бизнесу сэкономить денежные средства. Да-да, тестировщик помогает заработать больше и снизить риски потери денег бизнесу;

• Тестировщик не бог и у него нет никакого права решать не выпускать продукт - мы тестировщики и наша задача протестировать да рассказать о результатах тестирования людям выше;

• Тестировщик не нашёл/нашёл мало багов - это ничего не говорит об опыте сотрудника или качестве проверки продукта, качестве самого продукта;

• Тестирование - это информация. Не более.

Задача тестировщика предоставить информацию о соответствии критериям качества, о проблемах, о рисках, о способах сделать лучше (если есть такие идеи) или снять боль с команды/пользователей. Но ключевое слово: предоставить информацию - автор телеграм канала Shoo and Endless Agony в чате QA juniors

Ссылки

Для ознакомления с работой тестировщика можно прочитать эту статью. Мне статья понравилась;

Обзор развития карьеры

Если уже решили стать тестировщиком, то есть курс от mail.ru, а точнее от Алексея Петрова (pifagor_mc), очень понравилась подача материала и это первое что следует посмотреть для становления;

Чат единомышленников в телеграм. Первое что сделаете, когда вступите, это посмотрите закреплённое сообщение. Именно сюда можно скинуть работу и попросить обратной связи. Именно здесь можно много нового узнать. Несмотря на название, там сидят и очень матёрые ребята;

Что должен уметь начинающий специалист расписано здесь в разделе С чего начать.

Ольга Назина (Киселёва) представляет примеры хорошего резюме. Очень многое можно в её блоге почитать про тестирование в целом;

Арсений Батыров, который составил резюме из предыдущей ссылки, рассказывает про составление резюме.

*В данном предложении моё мнение - это изучить инструменты более важнее для перспективы трудоустройства, чем трата времени на изучение работы маршрутизации в сети интернет или чем отличается WWW от интернет и прочее. НО! Первое, замечательно будет знать будущему тестировщику веб-сайтов принципы клиент серверной архитектуры - любые знания будут иметь вес для специалиста. Второе, со временем специалист познает основы, допустим, что такое API и чем отличается от UI во время изучения Postman.