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

Тема дня: сети как база для понимания архитектуры.

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

Есть примеры решения стандартных задач по балансировке нагрузки, по обеспечению отказоустойчивости, по созданию peer-to-peer соединений. Как только вы спроектируете сеть на 40 пользователей, вы уже скорее всего познакомитесь с master-slave подходом. И он будет для вас нативным, понятным. Намного проще познакомиться с этими азами на примере сетей, нежели баз данных.

Для знакомства с сетями я рекомендую попробовать пройти сертификацию cisco CCNA. Есть огромное количество материалов, позволяющих это сделать. При подготовке, вы будете строить сети в cisco packet tracer'е. Работа через cli и знакомство с крутыми алгоритмами по оптимальной доставке пакетов вам обеспечена.
Я рекомендую вот этот https://www.youtube.com/playlist?list=PLcDkQ2Au8aVNYsqGsxRQxYyQijILa94T9

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

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

Через несколько минут к коллегам подошёл Антон, товарищ по работе и начал с Олегом обсуждать последние новости. И Антон с Олегом разговорились, обсуждая крайне интересные пикантные подробности последней презентации Apple. Наконец, когда через 10 минут коллеги увлеклись смакованием выхода на сцену новоиспечённого Тима Эппла, Кирилл не выдержал и ушёл. Ибо нефиг.

Рассказывая эту историю, Кирилл спрашивал меня, правильно ли он сделал. Стоило ему сказать коллегам "а вы не охренели"? и вернуть внимание Олега к проблеме или забить болт и послать Олега в следующий раз, когда тот обратиться за помощью.

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

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

Если вы менеджер или тимлид - уволить косячащего сотрудника обычно несложно. Сложно - суметь перенаправить его энергию в правильное русло и сделать эффективным членом команды.

Тема дня связка бэка с фронтом.

Не секрет, что главные проблемы в ИТ не технические, а связанные с miss communication.
Типичная проблема - разногласия между командами бэкенда и фронтенда.

Рассмотрим ситуацию: бэкенд выставляет АПИ, фронтендщики им активно пользуются. И как обычно что-то в процессе разработки отваливается, ломается. Бэкендщики что-то задеплоили на дев в 2 ночи, с утра пришли фронтэндщики - и ничерта не работает.

Обычно команды митигируют этот риск следующем образом:
1) Команда фронтенда мокает бэкенд. С одной стороны это самый надёжный вариант: "Бэк" доступен с локальной машины или со специально отведённой на это машины. Но я этот вариант люблю меньше всего: его очень дорого поддерживать. Так как АПИ меняется, то много времени приходится тратить именно на доработку мока АПИшки. Также момент отлавливания ошибок на бэкенде откладывается до выката релиза на стэйджинг, ведь до этого момента фронтенд не взаимодействует с бэком, а по сути, именно фронтендщики являются тестировщиками бэка.

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

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

Глупо было бы не использовать АПИ тестирование для избегания этих проблем. Причем стоимость этого решения значительно дешевле, чем вышеприведённые варианты.
Допустим, АПИ содержит 100 методов, из них фронтендщики активно используют 20-30. Достаточно написать 20-30 тестов с двумя assertions и прогонять их в рамках ci/cd процесса на бэке или хотя бы просто запускать их раз в 10 минут, чтобы знать состояние АПИ. Assertion'а достаточно два: на статус запроса и на проверку его контента. Обычно нам достаточно знать, что запрос возвращает 200 и ответ содержит какой-то id или какую-то стрингу. Дёшево и сердито, зато надёжно и является стартовой площадкой для последующего полноценного интеграционного и нагрузочного тестирования.

Конечно, можно было бы также сказать, что «Надо просто настроить нормальный мониторинг с нотификациями и алертами», и с этим сложно не согласиться. Но есть ситуации, когда подобные АПИ тесты будут более эффективны и востребованы.

Недавно вышло интересное исследование про удалённую работу. Основными респондентами стали жители США, Канады, Великобритании. Сфера деятельности - IT, маркетинг, консалтинг.
Краткий выводы исследования:
1) Специалисты этих сфер в подавляющем большинстве работают удалённо
2) Самое распросранённое место "Работы" - дом
3) Самым большим недостатком удалённой работы участники опроса назвали "невозможность перестать работать после работы". То есть они всегда на связи
Конечно данные опроса на данный момент не применимы к России, но скорее всего через несколько лет картина в нашей стране будет схожей
https://buffer.com/state-of-remote-work-2019

Сегодняшняя тема - часть Сonfiguration Management'а - code style.
Configuration management - это в первую очередь, чтобы среды разработки у разработчиков были схожие. Согласитесь, что если все разработчки программируют в одной IDE под одной операционной системой, с одинаковыми настройками среды - намного проще решать общие баги. Не надо думать, почему скрипт сборки работает у разработчика под ubuntu, а у разработчика на СentOS проект не собирается (докер вам в помощь).

Так вот, про code style.
В проектах командам рекомендуются использовать общие правила по написанию кода. Естесственно используются для этого автоматические тулзы. Обычно их называют линтерами (например, eslint). Общие правила для команды выбираются обычно следующим способом.

Кому-то назначается таска в джире на настройку общего конфига. Разработчик пишет правила, форматирует проект, завершает таску, правила и отформатированный проект попадают в репозиторий. Следующие ПРы других разработчиков вызывает маты , потому что столько конфликтов разработчики мёрджить не планировали. А когда начинаются проблемы с конфликтами, то начинаются придирки к правилам. И вот тут начинается холивар на несколько дней.
Вообще обсуждение правил - достаточно тяжёлая тема, при которой даже опытные разработчики не удерживаются от перехода на личности и взаимные оскорбления. "Да я 10 проектов делал, нигде мы *I* перед интерфейсом не писали, это прошлый век, так никто не пишет больше!". "Это очень удобно писать I перед интерфейсом, удобней пользоваться поиском, а то при поиске интерфейса Product мне ещё 10 Product'ов вылезает". И это может длиться вечно.
Что важно помнить:
1) ПР с форматированием проекта должен быть сделан в конце спринта, висеть минимальное количество времени, чтобы потенциальное количество конфликтов было минимальным
2) Правила не надо обсуждать, за них надо голосовать. Есть спорные мнения по правилу - пусть каждый выскажется в течение 1 минуты без перебиваний. После этого - голосование. Пофиг насколько _опытен_ тот или иной разработчик, каков его авторитет. Настоящий профессионал знает, что спорить можно бесконечно, главное - придти к консенсусу и следовать правилам. Зачастую разработчик хочет, чтобы приняли именно *его* предложение - вот истинная причина спора. "Я работаю 7 лет, как можно принять предложение не моё, а вот этого джуна?!" - вот обычно что скрывается за _аргументированным_ обоснованием того или иного правила.
3) Основные сложности при использовании общих правил написания кода - communication issues, то есть межличностные

Инженеры программного обеспечения - люди, которые берут на себя ответственность за выполненную работу. Этот канал о них. Руководствуясь лозунгом "It depends", они не спешат сразу отвечать на поставленный вопрос и предлагать решение проблемы. Ведь надо прикинуть то, как решение повлияет на:
- сроки реализации проекта,
- архитектуру,
- качественные метрики,
- процесс разработки,
- риски
Руководствуясь принципом "Все ошибаются", SE специалисты ещё раз уточнят требования, задатут вопросы "А зачем? А это точно надо? Вы уверены, что сайт *обязательно* должен открываться за 100 миллисекунд и это требование не высосано из пальца?".
SE специалисты - идеальные тим лиды, системные архитекторы и руководители проектов. Они знают почему их код работает и знают что сделать, чтоб заработал ваш

Channel photo updated

Channel created