Советы

Вступление

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

Мифы о UI/UX-дизайнерах

Вначале я хотел бы обратить внимание на предвзятое отношение и недоверие фронтендщиков к UI/UX-дизайнерам. Далее по тексту я опущу приставку UI/UX и буду писать просто дизайнер, подразумевая именно дизайнеров интерфейсов. Выделим несколько мифов, которые мешают в коммуникации.

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

Мой дизайнер самый ленивый. Этот миф возникает, когда приходишь несколько раз с одной и той же просьбой к своему дизайнеру, но он её упорно игнорирует. Зачастую дизайнеров меньше на проекте, и они всегда завалены работой и техдолгом как я уже упоминал выше, техдолг есть не только у разработчиков). Если работа простаивает без помощи дизайнера, лучше сходить к тимлиду возможно, есть задачи, которыми можно заняться в ожидании макета. Например, настроить инфраструктуру, среду для тестирования или что-нибудь ещё. Если тимлида нет, можно спросить дизайнера, чем он занимается, и помочь ему с расстановкой приоритетов. Объясните, какие экраны нужны в первую очередь, а какие могут подождать. Возможно, ваш дизайнер готовит дизайн-систему для проекта, тогда его лучше вообще не отвлекать, ведь как и у программистов, у них всегда есть важные задачи, при работе над которыми лучше не отвлекаться. Если вам действительно что-то очень нужно, объясните почему, спросите, когда у коллеги будет возможность заняться вашим вопросом, и до этого времени постарайтесь его не беспокоить.

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

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

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

Сложности с макетами

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

Следующая проблема связана с высотой блоков и вертикальными отступами между ними. Бывало, делаешь всё по макету, а при проверке на pixel perfect видишь, что вертикальные отступы отличаются. В моём случае это возникло из-за беспорядка в стилях, определяющих высоту блока. В макете высота строки (line-height) была задана в пикселях и была меньше размера основного текста (font-size), а размер блока был задан через height. При вёрстке я не смотрел на высоту блока, потому что обычно она не задается, ведь это может сломать элемент при переносе строки, и такой блок сложнее адаптировать. Высота блока должна формироваться автоматически и состоять из внутренних отступов (padding), высоты строки (line-height) и ширины рамки (border-width), при этом высота строки должна быть больше либо равна размеру шрифта (font-size). Отступы от блока считаются от внешнего края его границы, поэтому чтобы отступы и размеры блока совпадали с макетом, внимательно проверяйте все свойства. Если в них есть проблемы, постарайтесь объяснить их важность своему дизайнеру и попросите его привести эти стили в порядок. На одном из проектов мы с дизайнером договорились, что все отступы в проекте должны быть кратны определённой величине, например, четырем или восьми пикселям, тогда в случае расхождения отступов на сайте и в макете предпочтение отдаётся ближайшей кратной величине. Этот подход решает много проблем, но важно донести его тестировщику, который может прийти с багами, что отступы отличаются от макетов. Ещё рекомендация: всегда просматривайте свою вёрстку в pixel perfect, чтобы знать, где у вас явные расхождения и где вы могли что-то упустить, а где сам макет расходится с дизайн-системой.

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

В макете отступы внутри кнопки 8px от текста до верхнего края кнопки, но при вёрстке приходится уменьшать их на ширину бордера (border-width), потому что в браузере, как правило (если box-sizing: border-box), бордер входит в высоту и ширину элемента, и внутренний отступ (padding) считается именно от его внутреннего края. Похожая проблема наблюдается, когда кнопка в макете без обводки, но при ховере обводка появляется. Тогда, если делать один-в-один с макетом, наша кнопка будет прыгать, поэтому надо самому добавлять бордер с прозрачностью. Рекомендация только одна: всегда нужно удостовериться, что ваш элемент выглядит так, как нужно.

Следующая проблема связана с прелоадерами. В решении нам поможет теория конечных автоматов. Часто сами фронтендщики грешат тем, что задают одну булевую переменную (isFetching или isLoading) для отображения прелоадера, хотя состояний там гораздо больше. Например, в случае повторного перехода на страницу, на которой уже есть кэшированные данные, произойдёт отображение контента, а потом всё исчезнет и появится прелоадер, потому что пройдет обновление данных. Согласитесь, это не очень красиво. Такая проблема возникла потому, что мы смешали состояние первичной загрузки и обновления данных, а прелоадер использовали один и тот же в обоих случаях. Решить это можно, попросив вашего дизайнера продумать все состояния. Для этого лучше описать их, либо привести пример. При этом на фронтенде нужно будет задавать переменную не в булевом виде, а перечислением состояний, и обрабатывать каждое состояние отдельно.

Раз уж зашла речь о состояниях, хочу отметить, что часто в макетах не хватает всех состояний интерактивных элементов. А их, как правило, шесть:

• Normal сообщает, что компонент интерактивен и включен.

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

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

• Active активное или нажатое состояние сообщает о том, что пользователь нажал на кнопку.

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

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

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

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

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

Отдельно поговорим об адапативности. Как правило, вёрстка бывает адаптивная и резиновая. Адаптивная подстраивается под конкретные заданные разрешения экрана, а резиновая плавно изменяется, подстраиваясь под любую ширину экрана. На мой взгляд, резиновая вёрстка более современная и универсальная, а ее создание не вызывает трудностей, потому что в арсенале есть flex-box, grid, vw/vh, математические функции и прочее,. Однако, все давно привыкли к бутстраповским брекйпоинтам, и большинство макетов опираются именно на них. Хорошо, если в макете есть хотя бы три состояния: десктоп (как правило, 1440px), планшет (часто это 1024px или 768px) и телефон (320px или 375px). Именно с этого места обычно начинаются проблемы. Приходит заказчик и говорит, что на его моноблоке, у которого разрешение 2500px, сайт выглядит ужасно. Потом приходит аналитик и говорит, что сайт плохо выглядит на его ноутбуке, с разрешением в 1380px и так далее. Здесь описано сразу две проблемы.

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

Вторая проблема промежуточные состояния в макетах. Если размышлять адаптивно, а не резиново, все версии, отображаемые в макете, используются для состояний выше указанного, то есть макет на 1440px подходит для экранов шириной от 1440px и выше до следующего брейкпоинта (если он есть, конечно). Если ширина экрана меньше указанной в макете, должна отображаться версия для предыдущего брейкпоинта. Например, у вас в макете есть состояние на 1440px и 768px, на ширине в 1380px должна отображаться версия на 768px с ограничением ширины контентной области в соответствии с макетом. Выглядеть это будет не очень, мягко говоря. Худший сценарий, когда между брейкпоинтами большой разрыв. Например, дизайнер отобразил состояние на 1920px и на 768px. Тогда, следуя прямой логике, на 1440px включится состояние 768px, но так быть не должно. Суть проблемы в том, что, глядя на макеты в трёх разрешениях, фронтендщик не всегда понимает, какое состояние и в какой момент должно включиться. Если рассмотреть этот пример на резиновой вёрстке, на ширине экрана в 1380px должен отображаться макет для версии в 1440px, а на ширине 1110px версия для 1024px. Здесь возникают вопросы: в какой момент должна включаться какая из версий? До какой ширины экрана будет отображаться версия в 1024px? рассмотрим потенциальные варианты решений. Первый пойти к дизайнеру и описать проблему. Наверняка у него уже есть видение, как сайт должен меняться при сжатии и расширении экрана, он объяснит вам хотя бы на словах, однако это не всегда работает. Второй вариант отвязать свой разум от бутстраповских брейкпоинтов и рассматреть каждый блок как независимый. Потом я начинаю сжимать и разжимать каждый блок, наблюдая за его поведением, и определяю оптимальное разрешение для смены состояния. Многим верстальщикам такой подход не нравится и кажется избыточным. Основной аргумент возможно появление множества брейкпоинтов, но как показывает практика, этих состояний вряд ли будет больше шести, и все они будут инкапсулированы внутри своих блоков и ни на что не повлияют. Однако, ваш макет будет действительно резиновый и сможет подстраиваться под любое разрешение экрана.

Чем дизайнер может помочь фронтенд-разработчику

Здесь я собрал некоторые пункты, наличие которых в проекте помогло бы мне верстать.

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

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

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

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

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

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

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

• Консистентность между версиями. Это, скорее, просьба к дизайнерам. Разрабатывая макет мобильной версии сайта, старайтесь помнить, что это всё-таки сайт, а не мобильное приложение. Хочется видеть консистентность между десктопной и мобильной версиями. В некоторых проектах мобильная и десктопная версии настолько отличались, что приходилось делать разные версии с нуля, а это забирает в два раза больше времени на разработку.

Что следует знать дизайнерам о фронтенде

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

  • box-sizing определяет, как вычисляется общая ширина и высота элемента;

  • margin определяет внешний отступ;

  • padding определяет внутренний отступ;

  • border отвечает за все персональные свойства границ;

  • overflow работает с переполнением;

  • flex/grid наиболее популярные типы отображения элементов.

• Одна из основных методологий в CSS БЭМ. Дизайнеру она нужна, чтобы понять образ мыслей фронтендщика, который будет собирать страницу, и позволит хранить элементы проекта аналогично тому, как это будет делать фронтенд-разработчик.

• Отличие блочных элементов от строчных. Это позволит глубже понять композицию веб-страницы.

• Браузерные инструменты разработчика упростят процесс проведения авторского надзора и помогут проверить некоторые гипотезы непосредственно в рабочей среде.

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

Что следует знать фронтендщику о дизайне и не только

• Сетка. Практически все макеты строятся на основе сетки. Зная её, верстать становится проще, а учитывая, что теперь у нас есть grid, это превращается в удовольствие.

• Основы Figma. Говорить с дизайнером на одном языке и понимать особенности и отличия вёрстки в Figma и WEB-е.

• БЭМ. Неважно, как вы верстаете, будь то CSS-in-JS или CSS-modules, методология позволяет навести порядок в голове и мыслить правильными категориями.

• Наследование стилей. Многие CSS свойства наследуются от родительского блока, в Figma это отсутствует.Чтобы не переписывать все стили, не глядя , помните, какие свойства берутся от родителя, а какие объявляются в самом элементе.

• Конечные автоматы. Понимать, сколько состояний может быть у того или иного элемента на странице.

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

Заключение

В этой статье я осветил только часть того моста, который перекинут между двумя берегами фронтенда и UI/UX-дизайна. Надеюсь, мой опыт поможет фронтенд-разработчикам и дизайнерам чуть лучше понять друг друга.

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

P. S. (постскриптум)

За помощь в подготовке материала благодарю самого крутого из дизайнеров Олега Ровного.

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

1. Разберитесь в работе механизма проверки изменений

В интернете множество отличных углубленных статей про проверку изменений в Angular. Например, вот эта. Так что давайте просто освежим основы и перейдем к советам.

Основы

В Angular два режима проверки изменений: Default и OnPush. Первый запускает проверку на каждый tick внутри приложения. Этим управляет Zone.js, которая патчит все асинхронные операции вроде подписок на события и промисов. Второй режим помечает view для проверки, только если в нем случилось слушаемое событие или изменились входные данные.

Default vs OnPush

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

Подписки на события через @HostListener Angular заметит и в OnPush. Но что делать, если вы используете RxJS? Всегда можно заинжектить ChangeDetectorRef и вызвать markForCheck(), когда потребуется. Декларативным решением тут будет async пайп, если стрим в итоге доходит до шаблона. Он сам запустит проверку и возьмет на себя отписку.

Вам наверняка попадался такой паттерн:

<div *ngIf="stream$ | async as result"></div>

Но что делать, если вам важны также falsy-результаты? Можно выкинуть всю логику на условие из ngIf и сделать свою простую структурную директиву. Она будет использоваться, только чтобы объявить контекст для вложенного вью:

@Directive({  selector: "[ngLet]"})export class LetDirective<T> {  @Input()  ngLet: T;  constructor(    @Inject(ViewContainerRef) container: ViewContainerRef,    @Inject(TemplateRef) templateRef: TemplateRef<LetContext<T>>  ) {    container.createEmbeddedView(templateRef, new LetContext<T>(this));  }}

NgZone

Если у вас нет возможности полностью перейти на OnPush, можно провести оптимизации. Заинжектите NgZone и выполняйте нагруженные операции в .runOutsideAngular(). Таким образом не будет возникать лишних тиков в механизме проверки изменений. Даже компоненты в режиме Default не будут реагировать на эти операции. Это уместно делать для частых событий, таких как mousemove или scroll. Это можно сделать декларативно в RxJS-стримах с помощью двух операторов: один для выхода из зоны, другой для возврата в нее, чтобы запустить проверку изменений:

class ZonefreeOperator<T> implements Operator<T, T> {  constructor(private readonly zone: NgZone) {}  call(observer: Observer<T>, source: Observable<T>): TeardownLogic {    return this.zone.runOutsideAngular(      () => source.subscribe(observer)    );  }}export function zonefull<T>(zone: NgZone): MonoTypeOperatorFunction<T> {  return map(value => zone.run(() => value));}export function zonefree<T>(zone: NgZone): MonoTypeOperatorFunction<T> {  return source => source.lift(new ZonefreeOperator(zone));}

Еще один вариант, работающий с @HostListener, создать свой EventManagerPlugin. Мы выпустили open-source-библиотеку под названием ng-event-plugins. Она позволяет отсеивать лишние проверки изменений. Подробнее об этом читайте в этой статье.

2. Хорошенько разберитесь в RxJS

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

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

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

@Directive({  selector: "[sticky]",  providers: [DestroyService]})export class StickyDirective {  constructor(    @Inject(DestroyService) destroy$: Observable<void>,    @Inject(WINDOW) windowRef: Window,    renderer: Renderer2,    { nativeElement }: ElementRef<HTMLElement>  ) {    fromEvent(windowRef, "scroll")      .pipe(        map(() => windowRef.scrollY),        pairwise(),        map(([prev, next]) => next < THRESHOLD || prev > next),        distinctUntilChanged(),        startWith(true),        takeUntil(destroy$)      )      .subscribe(stuck => {        renderer.setAttribute(          nativeElement,           "data-stuck",           String(stuck)        );      });  }}

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

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

3. Выжимайте максимум из TypeScript

Мы все пишем Angular-приложения на TypeScript. Но, чтобы получить максимальную пользу, нужно задействовать его целиком. Я редко вижу проекты с включенным strict: true. Вам определенно следует сделать это. Оно спасет вас от множества cannot read property of null и undefined is not a function.

Дженерики

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

// Тип события с конкретным currentTargetexport type EventWith<  E extends Event,  T extends FromEventTarget<E>> = E & {  readonly currentTarget: T;};// Типизированный вариант fromEventexport function typedFromEvent<  E extends keyof GlobalEventHandlersEventMap,  T extends FromEventTarget<EventWith<GlobalEventHandlersEventMap[E], T>>>(  target: T,  event: E,  options: AddEventListenerOptions = {},): Observable<EventWith<GlobalEventHandlersEventMap[E], T>> {  return fromEvent(target, event, options);}

С ним вы будете уверены, что событие имеет конкретный тип, а currentTarget это элемент, на котором вы его слушаете.

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

Есть немало статей о продвинутой типизации и всевозможных трюках с TypeScript. Я очень советую расширять свои знания в этой области, это поможет вам писать надежный код. Мой последний совет: не используйте any. Если вы не можете применить дженерик, более безопасным выбором будет unknown.

Декораторы

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

export function assert<T, K extends keyof T>(  assertion: (input: T[K]) => boolean,  messsage: string): PropertyDecorator {  return (target, key) => {    Object.defineProperty(target, key, {      set(this: T, initialValue: T[K]) {        let currentValue = initialValue;        Object.defineProperty(this, key, {          get(): T[K] {            return currentValue;          },          set(this: T, value: T[K]) {            console.assert(assertion(value), messsage);            currentValue = value;          }        });      }    });  };}

Вы знали, что декорированный абстрактный класс не нуждается в пробросе аргументов в super()? Angular сам сделает это за вас, если не использовать конструктор в дочернем классе:

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

4. Dependency Injection. Используйте его почаще

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

Могу порекомендовать нашу статью, посвященную DI, чтобы освоиться с этим инструментом.

RxJS

Что касается практических советов, выше я уже говорил быть внимательными к утечкам памяти в RxJS. Главным образом это означает, что, если вы подписались на стрим руками, вам же и придется от него отписаться. Идиоматическим решение в Angular будет инкапсуляция подобной логики в сервис:

@Injectable()export class DestroyService extends Subject<void> implements OnDestroy {    ngOnDestroy() {        this.next();        this.complete();    }}

Вы также можете создавать общие стримы и добавлять их в DI. Нет необходимости создавать отдельные потоки на базе requestAnimationFrame в вашем приложении. Создайте токен и переиспользуйте его. Вы даже можете заложить в него операторы для выхода из зоны, описанные выше:

Токены

DI хороший инструмент для повышения абстрактности вашего кода. Если вы не зависите от глобальных объектов вроде window или navigator ваше приложение готово к использование в Angular Universal в серверном окружении. Такой код просто тестируется, так как все его зависимости легко подменить на заглушки. Глобальные объекты без труда превращаются в токены. Внутри фабрики при объявлении токена нам доступен глобальный инжектор. Нам потребуется всего пара строк для создания WINDOW токена на базе встроенного DOCUMENT:

export const WINDOW = new InjectionToken<Window>(  'An abstraction over global window object',  {    factory: () => {      const {defaultView} = inject(DOCUMENT);      if (!defaultView) {        throw new Error('Window is not available');      }      return defaultView;    },  },);

Чтобы не тратить на это время, используйте нашу open-source-библиотеку, где мы уже реализовали многие такие токены. А для Angular Universal есть ее библиотека-сестра с качественными заглушками. Не стесняйтесь, пишите нам, если вам нужен еще какой-то токен.

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

5. Бросайте императора в бездну, как Вейдер

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

Геттеры

Что это означает писать декларативный код? В первую очередь постарайтесь использовать ngOnChanges как можно реже. Это плохо типизированный сайд-эффект, который нужен, по сути, только когда надо выполнить какое-то действие при изменении нескольких входных значений.

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

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

Это хороший пример для сеттера, который я опустил для краткости, но про который мне напомнил внимательный читатель.

Template reference variables

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

<input #input><button (click)="onClick(input)">Focus</button>

Здесь мы передаем template reference variable непосредственно в метод, где она нужна. Так код нашего компонента остается чище. Думайте об этом как о подобии замыкания в шаблоне.

Но что, если мы хотим получить DOM-элемент, который является компонентом? Мы могли бы написать @ViewChild(MyComponent, {read: ElementRef}), но мы обойдемся без поля класса, если создадим директиву с exportAs:

@Directive({    selector: '[element]',    exportAs: 'elementRef',})export class ElementDirective<T extends Element> extends ElementRef<T> {    constructor(@Inject(ElementRef) {nativeElement}: ElementRef<T>) {        super(nativeElement);    }}

Динамический контент

Люди часто используют ComponentFactoryResolver для императивного создания динамических компонентов. Зачем, если есть директива ngComponentOutlet? Потому что так мы получим доступ к экземпляру компонента и сможем передать в него данные. Хороший способ решения подобной задачи опять же, Dependency Injection. ngComponentOutlet позволяет передать Injector, который мы создадим и подложим в него данные через токен.

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

Мы уже давно используем этот подход, не зависящий от типа переданного контента. Мы вынесли его в крошечную open-source-библиотеку под названием ng-polymorpheus. Она не делает ничего, кроме передачи контента в соответствующий встроенный инструмент, ngTemplateOutlet, ngContentOutlet или же простую интерполяцию с вызовом функции. Когда привыкаешь к такому, обратной дороги уже нет! Подробнее читайте в этой статье.

На этом все. Надеюсь, мои советы будут вам полезны. Приятного кодинга!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

_______

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

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

Перед вами вторая часть руководства по антипаттернам деплоя в Kubernetes. Советуем также ознакомиться с первой частью.

Список антипаттернов, которые мы рассмотрим:

1. Использование образов с тегом latest

2. Сохранение конфигурации внутри образов

3. Использование приложением компонентов Kubernetes без необходимости

4. Использование для деплоя приложений инструментов для развёртывания инфраструктуры

5. Изменение конфигурации вручную

6. Использование кubectl в качестве инструмента отладки

7. Непонимание сетевых концепций Kubernetes

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

9. Смешивание кластеров Production и Non-Production

10. Развёртывание приложений без Limits

11. Неправильное использование Health Probes

12. Не используете Helm

13. Не собираете метрики приложений, позволяющие оценить их работу

14. Отсутствие единого подхода к хранению конфиденциальных данных

15. Попытка перенести все ваши приложения в Kubernetes

6. Использование кubectl в качестве инструмента отладки

Утилита kubectl незаменима при работе с кластерами Kubernetes. Но не стоит использовать её как единственный отладочный инструмент.

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

kubectl get nskubectl get pods -n saleskubectl describe pod prod-app-1233445 -n saleskubectl get svc - n saleskubectl describe...

Вместо этого все ваши кластеры Kubernetes должны иметь надлежащие системы мониторинга, трассировки и сбора логов, которые можно использовать для своевременного выявления проблем. Если вам нужно запустить kubectl для проверки чего-либо, это означает, что вы не учли это, настраивая вашу систему мониторинга.

Сложно переоценить ценность метрик и трассировок, мы расскажем о них отдельно в одном из следующих антипаттернов.

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

Например, обратите внимание на Kubevious, это универсальная панель управления Kubernetes, которая позволяет вам искать и отображать ресурсы Kubernetes в соответствии с настраиваемыми правилами.

7. Непонимание сетевых концепций Kubernetes

Прошли те времена, когда единственный балансировщик нагрузки был всем, что необходимо для настройки подключения к вашему приложению. Kubernetes представляет свою собственную сетевую модель, и вам нужно разобраться с её основными концепциями. По крайней мере, вы должны быть знакомы с типами сервисов - Load Balancer, Cluster IP, Node Port и понимать, чем сервисы отличаются от Ingress.

Сервисы типа Сluster IP используются внутри кластера, Node Port также могут использоваться внутри кластера, но при этом доступны снаружи, а балансировщики нагрузки могут принимать только входящий трафик.

Но это ещё не всё потребуется разобраться, как в кластере Kubernetes работает DNS. И не забывать, что весь трафик между служебными компонентами шифруется и нужно контролировать срок действия сертификатов.

Будет полезно разобраться, что такое Service Mesh и какие проблемы она решает. Необязательно разворачивать Service Mesh в каждом кластере Kubernetes. Но желательно понимать, как она работает и зачем вам это нужно.

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

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

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

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

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

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

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

1. Обновление A содержит ошибки, B и C в порядке

2. Обновление B содержит ошибки, A и C в порядке

3. Обновление C содержит ошибки, B и A в порядке

4. Каждое обновление в отдельности работает, но при работе вместе с обновлениями A и B возникает ошибка

5. Каждое обновление в отдельности работает, но при работе вместе с обновлениями A и C возникает ошибка

6. Каждое обновление в отдельности работает, но при работе вместе с обновлениями B и C возникает ошибка

7. Каждое обновление в отдельности работает, но все 3 обновления вместе не работают

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

Способы избежать подобных проблем:

1. "Резервирование" промежуточного (stage) окружения разработчиками, чтобы они имели возможность тестировать свои обновления изолированно.

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

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

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

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

Есть много способов реализовать этот сценарий, по крайней мере, каждый запрос Pull Request должен создавать динамическую среду, содержащую только этот запрос Pull Request и ничего больше. Среда автоматически уничтожается, когда Pull Request объединяется / закрывается или по прошествии определенного времени.

Преимущество динамических сред это полная свобода разработчиков. Если я разработчик и только что закончил работу с обновлением A, а мой коллега завершил работу над обновлением B, я должен иметь возможность:

git checkout mastergit checkout -b feature-a-b-togethergit merge feature-agit merge feature-bgit push origin feature-a-b-together

Как по волшебству, будет создана динамическая среда:feature-a-b-together.staging.company.comилиstaging.company.com/feature-a-b-together.

Для создания динамических сред вы можете использовать, например, пространства имен Kubernetes.

Обратите внимание, что это нормально, если у вашей компании есть постоянные staging среды для специализированных нужд, таких как нагрузочное тестирование, тестирование на проникновения, развертывание A / B и т. д. Но для базового сценария Я разработчик и хочу, чтобы моё обновление работало изолированно и запускались интеграционные тесты динамические среды лучшее решение.

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

9. Смешивание кластеров Production и Non-Production

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

Прежде всего, смешивание Production и Non-Production кластеров может привести к нехватке ресурсов.

Так как приложение, работающее некорректно, может утилизировать слишком много ресурсов.

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

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

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

1. Разработчик создает новое пространство имен, используемое для тестирования и production.

2. Далее развертывается приложение и запускаются интеграционные тесты.

3. Интеграционные тесты записывают фиктивные данные или очищают БД.

4. К сожалению, в контейнерах были рабочие URL-адреса и конфигурация внутри них, и, таким образом, все интеграционные тесты фактически повлияли на работу production!

Чтобы не попасть в эту ловушку, гораздо проще просто создать Production и Non-Production кластера. К сожалению, многие руководства описывают сценарий при котором, пространства имен можно использовать для разделения сред, и даже в официальной документации Kubernetes есть примеры с пространствами имен prod / dev.

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

1. Production

2. Pre Production (Shadow) клон production, но с меньшими ресурсами

3. Development кластер, который мы уже обсуждали выше

4. Специализированный кластер для нагрузочного тестирования / тестирования безопасности

5. И даже отдельный кластер для служебных инструментов

10. Развёртывание приложений без Limits

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

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

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

Одно из преимуществ Kubernetes эластичность ресурсов. Если кластер убивает / перезапускает ваше приложение, когда оно начинает обрабатывать значительную нагрузку (например, ваш интернет-магазин испытывает всплеск трафика), вы не используете все преимущества Kubenetes. Вы можете решить эту проблему с использованием vertical pod auto-scaler (VPA).

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

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

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

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

Алгоритм максимальной эффективности

1. Определить цель и конкретные задачи.

2. Полное, совершенное погружение в работу с глубокой, устойчивой сфокусированностью и осознанностью. Чем больше осознанность, тем лучше.

3. Период отдыха и восстановления, когда нужно вообще не думать о работе.

4. Инсайт - появление моментов прозрения, новых идей и умственного прогресса.

Нагрузка + отдых = рост. Вот и вся формула успеха. При чём универсальная.Да, вот так всё просто.

Постановка целей

• Определите свои ключевые ценности.

• Персонализируйте свои ключевые ценности.

• Ранжируйте свои ключевые ценности.

• Запишите своё заявление о цели.

• Используйте визуальные подсказки - повесьте цели на видное место.

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

• Подумайте о том, насколько ваша жизнь соответствует вашей цели, и что нужно сделать, чтобы стать к ней ближе.

• Великие идеи рождаются в глубине души.

Используйте силу целеполагания

• Ищите смысл в трансцендентности, то есть в том, что превосходит вас самих.

• Понимание цели способствует упорству в её достижении.

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

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

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

Лучше всего мы учимся, когда нам приходится реально стараться

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

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

• Если вы чувствуете, что всё под контролем, можно сделать следующее задание немного сложнее.

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

Культивируйте мышление роста

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

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

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

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

• Ощути предвкушение победы. Как ни странно, оно дарует больше мотивации, чем сама победа.

Глубоко фокусируйтесь и добивайтесь осознанного идеального исполнения, даже если это не всегда приятно

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

• Уберите все, что вас отвлекает, например смартфоны. Помните: с глаз долой из сердца вон.

• Делайте только одну вещь за раз. Наука доказала: многозадачность неэффективна.

• Качество важнее количества.

Разбивайте работу на блоки

• Разделите работу на спринты продолжительностью 50 минут и передышки по 10 минут. Мозг устаёт точно так же, как и мышца.

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

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

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

  выйдите на короткую прогулку;
  посидите на природе;
  медитируйте;
  общайтесь с людьми;
  погладьте кота или партнёра;
  послушайте музыку;
  примите душ;
  помойте посуду.

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

• В случае действительно выматывающих задач подумайте о том, чтобы сделать паузу до утра.

• Чем сложнее задача, тем дольше должен быть перерыв.

Отдыхайте правильно!

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

• Регулярность важнее продолжительности. Лучше всего медитировать ежедневно, даже если это означает, что сессии будут короткими.

Используйте повышенную осознанность в повседневной жизни

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

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

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

• Чем больше стресс, тем дольше вы должны отдыхать.

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

• Усердный отдых порой может потребовать большего мужества, чем усердная работа.

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

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

Сон в приоритете

• Сон продуктивное занятие.

• 7-9 часов каждую ночь.

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

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

• Когда чувствуете дремоту, не боритесь с ней. Что бы вы ни делали, это может подождать до утра.

• Спальня должна быть как можно более темной. Если возможно, заведите светонепроницаемые жалюзи.

• Дневной сон от 10 до 30 минут для восстановления энергии, концентрации и креативности очень полезен. Однако ни в коем случае не дольше, а то случится обратный эффект.

Подготовка к производительности

• Создайте свой ритуал разогрева для важной деятельности.

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

• Разработайте последовательность действий, которая приведет ваше тело и разум в это состояние (зарядка, аффирмации, сытный завтрак, кофе, душ).

• Будьте последовательны: используйте один и тот же ритуал каждый раз, когда занимаетесь деятельностью, с которой он связан.

Выбирайте свое окружение

• Окружение имеет огромное влияние на нас.

• Следует окружить себя предметами, которые побуждают желательные действия, а приводящие к нежелательным - убрать.

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

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

• Не поддавайтесь негативным эмоциям и пессимизму.

Помните, что цепь сильна настолько, насколько сильно ее самое слабое звено.

Помогайте другим, чтобы избегать выгорания

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

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

• Помощь другим отлично помогает предотвращать и исцелять выгорание.

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

Кратко о себе: 2 вышки - 1ая Учитель рисования, 2ая - ИТ + одно средне специальное - художественная обработка металла

В Цехе

Начну с того, что где-то в 2001-2002 я устроился на завод, устраивался 2 раза.

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

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

И что характерно для цеха размером 150-250 м в длину и наверно 250-400 м в ширину + 200..300 работников в цехе (на заводе много цехов, завод и сейчас большой - более 10000 сотрудников, наверно даже больше)

Распорядок дня

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

Что бы попасть на завод надо взять с собой пластиковый пропуск с фото, пройти КПП (Контрольно пропускной пункт), а затем еще +5...8 минут пешком и в цех.

Хотя и начинался рабочий день в 8-00, а по факту, надо было до 8-30 закинуть пропуск в окно, на первом этаже цеха. В окне из оргстекла была щель, и к 8-30 накапливалась груда пропусков, а в 8-30 приходила табельщица, собирала все их, и кто не успел до 8-30 кинуть пропуск - тому ставила опоздание/прогул.

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

Что еще важно, так то, что в 8-45 начальник цеха начинал обход рабочих мест, смотрел, кто вышел, кто нет, есть ли косяки на рабочих местах (грязь например) и иногда спрашивал рабочих, что им нужно для работы.

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

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

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

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

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

Хоть я и не верю этой байке, но доля правды в ней есть.

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

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

Пол из кафельной плитки размером 40 на 40 см и огрызками плитки-линолиума, или какого то выцветшего зеленого пластика времен СССР, яркие лампы под 3+ метровым потолком.

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

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

Такой чай мог разбудить наверно и мертвеца как меня.

Никто не кидался за работу сразу, типичная поговорка была такой: "Чай не пил, какая сила ?"

Обед

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

Ближе к 16-40 конец дня, время прибраться, пострадать х... и занять очередь за пропуском.

Социалка и плюшки

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

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

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

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

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

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

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

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

Впечатления

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

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

А еще хорошо то, что там есть и простые люди и крутые люди, как например профессор/преподаватель по металлургии, который учил меня как на глаз определять температуру металла между 600 и 650, 700, 750, ... градусов, показывая на своем примере, как в муфельную печь размером с гараж засовывать заготовки и как их закалять в воде или в масле.

Что плохо - если ты молод и ничего не умеешь, то и ЗП маленькая.

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

P.S. А еще я работал и в других местах, как например

• Технологический отдел, с 350+ технологов, где 75% это женщины - инженеры и интриги это их основная деятельность - 3 года

• В отделе ИТ при заводе, так же где 200+ человек - еще 3-4 года, админил ORACLE

• На другом заводе админил ORACLE/MSSQL еще 8-9 лет и "пинал" программистов, за их код.

• Сейчас работаю сам программистом в банке - и дивлюсь еще больше, какие же программисты бывают альтернативно одаренными

• А еще и художественная сфера с которой все равно соприкасался, хоть и не работал

• А еще всякие мелкие халтуры в ИТ, как то дизайн и программирование для "маленьких"... ох...

Итеративный подход

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

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

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

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

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

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

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

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

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

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

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

Прототипирование Microspace project в Godot engine

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

Таким образом, требовалось собрать прототип, в котором на самом элементарном уровне были бы реализованы какие-то классические ингредиенты jrpg-жанра - режим глобальной карты, режим сражений. Чем я и занялся.

В качестве движка был выбран Godot engine, а конкретнее версия 3.2.1, язык GDScript и gles3 рендер. В целом данный проект относится к категории достаточно код-интенсивных, всё-таки это далеко не аркада, где можно обойтись вобще без программирования. Выбор GDScript'а не особо принципиален, просто на нём быстрее писать внутри редактора, без открытия лишних окон, а так - вся логика без каких-то особых проблем переносится на тот же C#. Gles3 тоже не принципиален, но я взял более мощный рендер в качестве целевой платформы, а на упрощённом всегда можно собрать отдельную версию, только потребуется переработать частицы.

Началось всё с набросков карты сектора и написания контроллера, чтобы добавить модель кораблика и полетать по получившемуся "космосу" (попутно придумалась музыкальная композиция для глобальной карты):

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

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

Подготавливая приблизительные иконки с персонажами/предметами для инвентаря я завёл пару текстурных атласов в формате png, размерами 512 на 512. Таким образом в каждом можно держать по 64 иконки размерами 64 на 64. Godot, кстати, сам умеет сшивать несколько выбранных картинок в атлас, но у меня почему-то эта его функция не срабатывает, поэтому набросал заготовки в графическом редакторе.

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

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

Следующее обновление принесло ещё один важный момент, которого не хватало - собственно, партию героев, к основному звездолётику Wanderer добавились Spira и Vanguard. Появились новые враги, отображение получаемого урона, самописный ориентировочный трек сражения, доработки инвентаря и специальная станция, где можно отправить одного из героев с основного корабля на задние, а потом забрать его, после истечения срока.

Архитектура приложения

Теперь немного о том, как всё это устроенно за кадром. Godot представляет всё в виде иерархически связанных элементов, которые являются различными узлами либо сценами, в которые завёрнуты другие узлы и/или сцены. То есть, у нас, допустим, есть общая "сцена-океан", в которой содержится "узел-солнце" и "сцены-острова", в каждом из которых расклонированы "сцены-деревья" и так далее.

Собственно, про некоторые особенности движка Godot и я рассказывал вот в этой статье:

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

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

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

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

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

Где брать идеи

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

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

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

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

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

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

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

Вот нам нужна игра про партию героев, которые сражаются с врагами, исследуют различные города, имеют систему развития, разные предметы... Начните с одного героя. Одного врага. Сражение с одной только опцией - удар. Вместо города несколько примитивов изображающих дом. Отображение пустого окошка с информацией о герое. И так далее. Потом героев станет два. В статистике появится имя. Врагов станет двое. Кроме ударить, появится вторая опция, пусть она даже сначала не работает. Коробок-домов станет несколько. Появится отображение содержимого сумки, пусть сначала только одна ячейка. Затем героев станет три, и можно будет менять их местами. Враги станут попадаться группами по 2 или 3. Появятся ещё боевые опции. Появится вторая область с "домиками", до которой можно добраться. Итак далее.

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

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

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

Н