Код продакта | Александр Иосса

Тема дня: Code of conduct для дизайнеров

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

И поэтому написали свод из правил по организации макетов в Figma.

1) При использовании элементов из Material-ui (а мы их активно используем) следует использовать соответствующие названия для элементов:
- AppBar
- SnackBar
- ListItem
- Typography

2) При создании адаптивных компонентов, иконок, мы также должны задавать соответствующие self-descriptive имена, такие как:
- ProductCard
- DeleteIcon

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

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

Написали, зачем это нужно. Оказалось, что пока незачем. При этом интересно, что для разработчиков эти правила кажутся очевидными.
- Когда в команде менее трёх дизайнеров (у нас так), проблем с коммуникацией между друг другом нету.
- Разработчики же могут работать с текущими макетами и им в принципе всё равно, как сгруппированы и названы элементы в макете. Всё равно 1 к 1 сгруппировать элементы не получится.
- Обсуждения того, как называть элементы в Figma будет только накалять отношения между разработчиками и дизайнерами. При этом всё сведётся к тому, что разработчики будут говорить что как назвать.
- Различные темы в продукте мы пока вводить не планируем, а нормальных инструментов для экспорта компонентов из Figma в React приложение не появится ещё минимум полгода (сугубо личное мнение).

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

А тем временем в Казани организаторы конференции для разработчиков DUMP проводят небольшой митап для Тимлидов. Организаторов давно знаю и уважаю, сам там буду, поэтому welcome!


⏰2 октября 9:00 -11:00 пройдет тимлид-завтрак "Удаленная команда. Начало"

Встреча для тимлидов, менеджеров разработки, СТО — всех тех, кто по полгода не может найти разработчика, кто на грани факапа, и кто созрел взять первого сотрудника на удаленке или отдать часть работ на аутсорс.

Тимлид-завтрак пройдет в кафе-баре IQ на Баумана 60 в формате "кофе-кейсы". Первый час опытом поделятся те, кто уже работает с распределенной командой или аутсорсерами. Будет как об отличном опыте, так и о провальном. А еще будет о граблях, которые можно обойти, и о тех, которые встречаются раз за разом.

Обсудим интервью Никиты Соболева из wemake.services, сделанное специально к тимлид-завтраку, в котором он рассказывает почему не пожалел, что несколько лет назад распустил всю команду из офиса и полностью перешел на работу с удаленными разработчиками.

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

Мероприятие бесплатное. Свежесваренный кофе с оргов. Позавтракать можно прямо там: каши добавками, омлет с курицей, сэндвичи и сырники - от 160 руб.
Подробности и регистрация по ссылке 👉https://goo-gl.ru/5IzL

Тема дня: Люди-индикаторы

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

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

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

​​Тема дня: Дерево развития Тим лида

Давно держал в голове вопрос о том, какие навыки Тим лида наиболее важны и как их развивать.
И тут на просторах github'a наткнулся на целый репозиторий, посвящённый дереву навыков Тим лида.
Ребята проделали замечательную работу, результатами которой мы можем насладиться.
У них даже есть телеграмм канал.
Если что-то хотите дополнить в дереве - ПРы приветствуются.

Навыки делятся на 5 основных типов:
- Администрирование (управление процессами, управление проектами и т д)
- Управление ресурсами (управление людьми, командой, развитие технического бренда)
- Продуктовая компетенция (навыки Product owner'a)
- Навыки интеграции в компанию (развитие культуры и ценностей, понимание бизнес модели компании и умение встроить в неё отдел разработки)
- И наконец технические навыки: качество, техническое качество, знание технологий, архитектура
Навыки по написанию кода никто не отменял, но на фоне остального становится ясно, что это всего лишь один из навыков и стать Тим лидом без прокачки других невозможно.

Я практически полностью согласен с этим деревом, радует, что кто-то структурировал информацию в один Mind map. Интересно теперь было бы посмотреть на дерево CTO, потому как, мне кажется, разница будет не очень велика.

Прикрепляю само дерево в .png формате

Тема дня: взаимодействие между дизайнерами и фротендщиками

Достаточно хайповая тема, без которой последнее время не обходится ни одна конференция.
На одну конференцию в Иннополис только 3 доклада подаётся с такой темой. Естественно, выступят только достойные.

Если в вкратце, то пора зафиксировать state of the day (ИМХО конечно):
Основным инструментом для дизайнеров и разработчиков стала Figma. Если вы всё ещё делаете проекты в Sketch, возможно вам стоит задуматься. То ли "так исторически сложилось", то ли вы серьёзно переплачиваете. Если вы ещё на фотошопе - мужайтесь, в мире столько всего произошло..(

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

Вопрос о том, должен быть дизайнер в отдельной команде или же находиться внутри cross functional team в принципе решён. Есть плюсы и минусы у обоих подходов.
Основный влияющие факторы:
- Работает ли дизайнер только с одной командой,
- Выполняет ли он задания не только для разработчиков,
- Зрелость специалиста (неопытного дизайнера лучше держать ближе к команде),
- Общее количество дизайнеров и процесс взаимодействия между ними, требование соответствия общим guideline

Между дизайнерами и фротендщиками возможны конфликты типа "красота vs скорость". Например, что лучше, сначала отображать дефолтный шрифт, а потом загрузившийся кастомный с мельканием или же обойтись без мелькания и дождаться полной загрузки кастомного?
Фронтенд разработчики скорее всего будут за постепенную загрузку (при этом упирая на accessibility), дизайнеры - за отсутствие мелькания.

Тема дня: простое внедрение Definition of done

Все вокруг говорят, что definition of done очень важно, от этого сильно зависит качество конечного результата. DoD может включать тесты, может не включать тесты. Может включать обновление документации, может не включать.
Всё зависит от задачи и контекста, естественно. Главное, не пере.б.ть.

Однако дело с DoD обстоит как с сексом у подростков или искусственном интеллектом в современном мире. Все говорят о нём, однако практически никто не использует. Да-да, 2 года назад тоже самое было с блок-чейном, 5 лет назад было в big data. В общем ничего нового.

Чтобы и в вашей команде появились definition of done чек листы - предлагаю очень простой лайф хак.
Покажу на примере Джиры и Гитхаба.
В Джире добавьте кастомное поле "DoD" с типом чек боксов. И добавьте туда самые подходящие вам пункты для DoD листа.
Например:
- Checked in Safari,
- Checked in Chrome,
- Tests implemented,
- Docs up to date.
При заведении задачи выбирайте релевантные.

На гитхабе же добавьте приложение (Task list completed)https://github.com/marketplace/task-list-completed. Оно позволяет в комментариях создавать чек листы. С элементарным синтаксисом типа "- [x] Checked in Safari". При ПРе пусть разработчик будет указывать пункты из чеклиста, которые он выполнил. Отметка во всех пунктах листа вознагржается зелёной галкой в чеках (как другая галка ci). Отсутствие одной из них - крестом.

Если честно - очень спасает от дурацких вопросов "А в мобильной версии сафари проверил? Точно?"
Пункты в DoD в Джире можете указывать, можете не указывать, как хотите. Зависит от строгости вашего процесса.

Тема дня: как наказывать разработчика?

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

И ситуаций таких не так мало, вот тоже известные случаи:
[Junior, который в первый день работы удалил базу данных с production](https://habr.com/ru/company/flant/blog/330750/)
Gitlab «лежит», база уничтожена (восстанавливается)
Многие задают вопрос, а как правильно наказывать сотрудников, факап же все-таки не маленький.

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

То, что произошло - всего лишь симптом, наказание бедного сотрудника, никаким образом не поможет предотвратить подобную причину в будущем. При подобных происшествиях надо проводить Root cause analysis, в котором уже давным давно всё описано: надо понять что случилось, почему случилось. Определить, что можно сделать для того, чтобы предотвратить повторное возникновение проблемы.

Можно использовать знаменитую технику "5 whys", которым руководствовался Сакичи Тоёта на тоёте. После второго why будет очевидно, что наказание сотрудника не поможет. Скорее всего дело как всегда в процессе.
Например, неплохо тестировать бэкапы на восстановление. И это не рокет сайенс, в любой методологии ИТ процессов об этом пишут (ITIL, COBIT и т д).
Вот если уже конкретные люди противятся изменениям, не понимая рисков и причин этих изменений - это уже другой вопрос.

Тема дня "Open source проекты"

Не мог обойти тему, о которой на js митапе в прошедший четверг выступл Андрей Ситник @sitnik, создатель нескольких популярных и полезных open source проектов, таких как PostCss, browser list, NanoId, autoprefexier, size-limit и некоторых других.

Андрей поднял вопрос "Ради чего стоит идти в open source".
Если в кратце - то только ради того, чтобы что-то изменить. И при этом это очень сложный процесс, требующий огромной самоотдачи.

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

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

Теперь немного от себя. Вообще open source проекты очень схожи с обычными продуктами. Вы можете сделать 10 проектов и только один из них выстрелит. Точно также и с open source. По словам Андрея, из 52 его проектов, 5 стали популярны, остальные не выстрелили. И к сожалению, как и у обычных проектов, почти никого не волнует качество кода.
Точно также важно продвижение и подача проекта. У продуктов это как минимум визитка, у open source проекта - Read.me файл (без хорошей документации у open source проекта почти нет шанса).

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

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

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

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

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

Тема дня: Стоит ли отправлять сотрудников на конференции?

С одной стороны, практически каждый сотрудник после конференции скажет, что практически ничего нового не узнал. Ему понравилась поездка, он бы с удовольствием на неё поехал ещё раз, но что касается реальной пользы.. её мало.
И для большинства компаний этого ответа вполне достаточно для того, чтобы закрыть вопрос. Тем более там ещё хантеры от других конкурентов приезжают, что приносит дополнительные риски. В чем тогда смысл? По статистике дампа на конференцию в ЕКБ стоимостью 7 000 рублей 70% билетов было оплачено компаниями. На конференцию в Казани, стоимостью 3 000 рублей лишь 30%.

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

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

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

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

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

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


Один из интересных докладов на DUMP 2019 был от продуктолога Skyeng, которая рассказывала, что они тестируют в месяц более 100 гипотез, однако 99 из них убивают, не доводят до реализации.
При этом мелкие фичи типа "Поменять цвет у кнопки" не включают в этот список гипотез. А вот предложить новый тариф для определённой ЦА - это прямо гипотеза, которая может увеличить прибыль компании, а может нет. При этом из 10 разработанных фич в итоге выстреливает одна, поэтому у них в компании строго борются с кодерами-перфекционистами. Успешную фичу можно отрефакторить потом. А реализация фичи по всем правилам разработки может занимать по времени как 5 быстро запилинных фич.

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

Тема дня: DUMP 2019
На этих выходных мы с командой ездили на DUMP 2019 в Екатеринбург, совершенно замечательную конференцию разработчиков. Было аж 7 потоков:
- Frontend,
- Backend,
- Design,
- QA,
- Science,
- Management,
- Мастер-классы


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

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

Было очень интересно побеседовать с представителями Miro, которые раньше назывались Realtimeboard. Их продукт - онлайн доски общего пользования со временем отклика настолько маленькими, что мы можем видеить премещение сотен курсоров других участников, работающих с нами на одной доске. Можем рисовать, клеить стикеры, писать юзер стори, даже линковать задачи из джиры. И майнд мапы туда включены. В общем для меня это сейчас основной инструмент для Work breakdown structure схем.
И ребята подготовили классный доклад о том, как они делали performance тестирование своего продукта.

Тема дня: немного о процессах.

На днях разговаривал с молодой командой ребят, занимающихся своим стартапом.

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

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

Тема дня: ода к devOps специалистам

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

devOps должен брать на себя ответственность за всё, что связано с инфраструктурой. Для меня devOps - это аналог IAAS (infrastructure as a service). Я бы его даже называл IAAS man'ом. Как супермен, но про инфраструктуру. Я не хочу, чтобы разработчики задумывались о том, где хостятся и как хостятся их приложения. Пусть им в этом поможет IAAS man!

Итак, IAAS man, по моему скромному мнению, должен:
- выстраивать CI/CD pipeline. Тулзы и метрики остаются за разработчиками
- поддерживать стабильность CI/CD pipeline. Если ваши ПРы не проходят какие-то Quality Gates, то у разработчика не должно быть сомнений в том, что причина в коде. Возможно многие узнают ситуацию, когда при фэйле каких-то проверок приходится в первую очередь проверять, проблема в ci или же в коде, а уже потом лезть в код или перезапускать проверки руками. И у некоторых devOps действительно с этим проблемы

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

- настройка бэкапов и сиcтемы резервного копирования.

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

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

Не буду дальше копать в глубь и говорить, что есть devOps, специализирующиеся на каких-то более узких вещах, например, масштабируемости и надёжности. Это out of scope и тут одними devOps'ами не обойдёшься

Тема дня: Quality attributes и инструменты

Любое требование к системе можно отнести к одной из следующих качественных метрик:
- Functional suitability/ Функциональная пригодность
Ex: В 95% случаев, нейронная сеть корректно определяет, пойдёт ли дождь
- Performance Efficiency/ Уровень производительности
Ex: Время полной загрузки сайта менее 5 секунда
- Compatibility/ Совместимость
Ex: Наш сайт должен работать в IE 11 версии
- Usability/ Удобство использования
Ex: Сайт должен быть адаптирован для людей с ограниченными возможностями
- Reliability/ Надёжность
Ex: Сайт должен работать без интернета
- Security/ Безопасность
Ex: Не храним plain пароли!
- Maintainability/ Сопровождаемость
Ex: Технический должен быть менее 2 дней
- Portability/ Переносимость
Ex: Работает и под windows, и под ubuntu

Эти верхнеуровневые QA выбраны из ISO 25010. Когда-то в стандарте был указан и QA Scalability.

Теперь про инструменты.
Для определения QA фронтэнд приложений на начальном этапе подойдёт lighthouse
Ознакомиться с его функционалом и предоставляемыми метриками (их более сотни) можете прямо сейчас, он встроен в отладчик хрома.
Вот так, например, выглядит отчёт для rb.ru с учётом throttling'а Applied Fast 3G, 4x CPU Slowdown.

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

Тема дня: Quality gates

Qaulity gate - это проверка на соответствие качественным метрикам вашего проекта в контрольных точках CI/CD процесса. Например, прохождение 100% тестов при создании ПРа - это одна из метрик quality gate.
Какие ещё точки в CI/CD процессе есть? Например, pre-commit, pre-push (фактически любые другие git-hooks). Можно настроить и более сложные, такие как pre-production check. Когда мы перед запуском скрипта на деплой проекта в production выполняем финальные проверки.
Если git hooks фактически стандартизированная вещь, то другие контрольные точки в CI/CD процессе сильно отличаются из-за особенностей конкретного CI/CD процесса.
Какими бывают качественные метрики?

Перечислим базовые:
1. Проверка на соответствие coding standarts. То есть чтобы линтер не ругался.
2. Автоматические тесты проходят.
3. Ручные тесты проходят.
И на этом в большинстве проектов качественные метрики заканчиваются. Ну нет у нашего брата регрессионного performance testing'а. Не меряют они размер бандлов, время загрузки веб-приложения. Может у кого-то и есть, но не систематизировано это всё.

Как можно улучшить?
Давайте введём качественные метрики.
Если у вас web приложение, давайте замерим First meaningful Paint time для главной страницы. Время, через которое по умолчанию отрисуется главная страница. и пользователь сможет наконец что-то делать.

Зная, что в релизе 1.1 эта метрика была равна 2,5 секунды, увидев в релизе 1.2 значение 5,5 секунды, вы остановитесь и призадумаетесь о причине увеличения времени загрузки сайта.

Давайте замерим размер бандла и в целом загруженного контента. В релизе 1.1 размер бандла составил 340 килобайт. В релизе 1.2 160 килобайт. Всё верно, ведь как раз была закрыта задача по оптимизации зависимостей в проекте. А размер сайта наоборот увеличился. Почему?

Это вершина айсберга. Улучшать дальше можно долго.
Время загрузки сайта разобьётся на:
- First Contentful Paint
- Time to first beet
- Time to Interactive
- First Meaningful Paint
- и прочее

Размер сайта разобьётся на:
- Размер js бандла,
- Размер css бандла,
- Объём картинок,
- И так далее


Подумайте, что именно важно для вашего проекта, какие именно quality attributes и начните их регрессионно измерять. Практически все измерения можно делать автоматически, в том же самом jenkins'е.

В следующем посте поговорим с вами о систематизации Quality attributes и тулзах для их измерения. Именно на них выстраиваются Quality gates.

Тема дня: Полгода с typeScript. Стоимость внедрения и оверхэдов.
Для тех, кто торопится: всё огонь, в команде, в которой есть хотя бы один Senior, можно без проблем использовать ts.

О преимуществах и недостатках использования typescript'a было написано не раз, при этом недостаток обычно указывался только один - learning curve и отсутствие специалистов, его знающих. Статья не о преимуществах typescript, а как раз-таки о learning curve и молодых специалистах.

Когда мы начинали использовать ts, у нас по факту не было человека, который хорошо в нём разбирался. И да, мы наломали в своё время дров. Но через месяц использования мы примерно поняли что к чему и довольно быстро смогли отрефакторить наше мракобесие.
Typescript достаточно нов и, по моему субъективному мнению, только недавно созрел для полноценного использования в production. Процесс его эволюции хорошо описан в докладе Андрея Старовойтова.

Год назад я бы не рекомендовал использовать его в production, потому что большинство библиотек ещё не поддерживали типы, приходилось либо писать их самим, либо задавать тип "any". Также отсутствовали туториалы и best practices по использованию typescript'а. В духе javascript каждый разарботчик писал и использовал типы как хотел, не понимая где их объявлять, в каком случае нужно наследовать типы, в каком случае наследовать, в какой папочке хранить. Где объявлять типы, в редьюсерах или в соответствующих api методах?
А если вы хотели использовать не самую популярную технологию совместнос ts - начинались настоящие танцы с бубном. Подружить typesctip с бабелем, вебпаком или уже готовым бойлер плэйтом было достаточно дорого.
Сейчас же разработчик, который раньше не имел опыта с ts без большого труда вольётся в проект. Да, он не сможет, например, прикрутить ts к редаксу, но выполнять обычные задачи и расширять существующий функционал - без проблем. Это не React-native, где легко было выстрелить себе в ногу и потратить пару дней, а то и больше, на поиск ошибки.


Сейчас же база знаний на stack overflow и документация подматерела, велосипедов с костылями стало меньше. Подтвержу выводы многих статей о том, что typescript не так сильно сокращает количество ошибок, добирающихся до production. Я не измерял, но уровень в 10-20% звучит достаточно достоверным.


ИМХО кажется, что typescript - это надолго. И это хорошо)

Тема дня: рисуем архитектуру или давайте говорить на одном языке.

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

Причина таких недопониманий - разный бэкграунд. ФПшник и ООПшник будут очень долго спорить об одном и том же, совершенно не понимая термины друг друга. Ну не учат нигде архитектуре - универсальному языку, на котором по-хорошему должны разговаривать разработчики. Потому что в ИТ мы попадаем в основном через небольшие проекты и халтурки, самообразование и курсы типа "Сделаем первое мобильное приложение".
Как бороться с этим?

Добавьте контекст. Оформите его схемами и выложите в Readme файл. Одной Dynamic view достаточно, чтобы разработчики начали понимать друг друга и мыслить одинаково.

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

Сколько бы фронтенд разработчики не объясняли бэкендщикам, что их АПИ неудобно, пусть и правильно, бэкендщику очень сложно понять боль фронтендщика. У нас же "JSON API", это стандарт, признанный всеми, чего вам ещё не хватает?
Рисуешь Sequence diagram, на которой видно, что для загрузки главной страницы требуется 7 последовательных запросов, и бэкенд разработчик меняется в лице.

ИМХО: уважающий себя разработчик должен уметь рисовать схемы. Я уж не говорю про communication skills, это другая больная тема.
В данном посте и на 5% не раскрыта правильное проектирование и документирование архитектуры и не претендует на это. Это лишь первый шаг)

Тема дня: трэкинг. Трэкать время или нет.

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

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

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

Получается, что трэкать время мы можем только тогда, когда рассчитываемся с разработчиками за время. Но там и системы трэканья стоять сложные: следят за движением мышки, пытаются понять, когда пользователь out of keyboard. При этом даже в TopTal этого не делают. Лично я против такой тирании в офисе.

А что думаете вы?
Оставляйте свои комментарии

Код продакта | Александр Иосса pinned «Инженеры программного обеспечения - люди, которые берут на себя ответственность за выполненную работу. Этот канал о них. Руководствуясь лозунгом "It depends", они не спешат сразу отвечать на поставленный вопрос и предлагать решение проблемы. Ведь надо прикинуть…»