Инженеры программного обеспечения - люди, которые берут на себя ответственность за выполненную работу. Этот канал о них. Руководствуясь лозунгом "It depends", они не спешат сразу отвечать на поставленный вопрос и предлагать решение проблемы. Ведь надо прикинуть то, как решение повлияет на:
- сроки реализации проекта,
- архитектуру,
- качественные метрики,
- процесс разработки,
- риски
Руководствуясь принципом "Все ошибаются", SE специалисты ещё раз уточнят требования, задатут вопросы "А зачем? А это точно надо? Вы уверены, что сайт *обязательно* должен открываться за 100 миллисекунд и это требование не высосано из пальца?".
SE специалисты - идеальные тим лиды, системные архитекторы и руководители проектов. Они знают почему их код работает и знают что сделать, чтоб заработал ваш
- сроки реализации проекта,
- архитектуру,
- качественные метрики,
- процесс разработки,
- риски
Руководствуясь принципом "Все ошибаются", SE специалисты ещё раз уточнят требования, задатут вопросы "А зачем? А это точно надо? Вы уверены, что сайт *обязательно* должен открываться за 100 миллисекунд и это требование не высосано из пальца?".
SE специалисты - идеальные тим лиды, системные архитекторы и руководители проектов. Они знают почему их код работает и знают что сделать, чтоб заработал ваш
🔥1
Сегодняшняя тема - часть С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, то есть межличностные
Configuration management - это в первую очередь, чтобы среды разработки у разработчиков были схожие. Согласитесь, что если все разработчки программируют в одной IDE под одной операционной системой, с одинаковыми настройками среды - намного проще решать общие баги. Не надо думать, почему скрипт сборки работает у разработчика под ubuntu, а у разработчика на СentOS проект не собирается (докер вам в помощь).
Так вот, про code style.
В проектах командам рекомендуются использовать общие правила по написанию кода. Естесственно используются для этого автоматические тулзы. Обычно их называют линтерами (например, eslint). Общие правила для команды выбираются обычно следующим способом.
Кому-то назначается таска в джире на настройку общего конфига. Разработчик пишет правила, форматирует проект, завершает таску, правила и отформатированный проект попадают в репозиторий. Следующие ПРы других разработчиков вызывает маты , потому что столько конфликтов разработчики мёрджить не планировали. А когда начинаются проблемы с конфликтами, то начинаются придирки к правилам. И вот тут начинается холивар на несколько дней.
Вообще обсуждение правил - достаточно тяжёлая тема, при которой даже опытные разработчики не удерживаются от перехода на личности и взаимные оскорбления. "Да я 10 проектов делал, нигде мы *I* перед интерфейсом не писали, это прошлый век, так никто не пишет больше!". "Это очень удобно писать I перед интерфейсом, удобней пользоваться поиском, а то при поиске интерфейса Product мне ещё 10 Product'ов вылезает". И это может длиться вечно.
Что важно помнить:
1) ПР с форматированием проекта должен быть сделан в конце спринта, висеть минимальное количество времени, чтобы потенциальное количество конфликтов было минимальным
2) Правила не надо обсуждать, за них надо голосовать. Есть спорные мнения по правилу - пусть каждый выскажется в течение 1 минуты без перебиваний. После этого - голосование. Пофиг насколько _опытен_ тот или иной разработчик, каков его авторитет. Настоящий профессионал знает, что спорить можно бесконечно, главное - придти к консенсусу и следовать правилам. Зачастую разработчик хочет, чтобы приняли именно *его* предложение - вот истинная причина спора. "Я работаю 7 лет, как можно принять предложение не моё, а вот этого джуна?!" - вот обычно что скрывается за _аргументированным_ обоснованием того или иного правила.
3) Основные сложности при использовании общих правил написания кода - communication issues, то есть межличностные
😱1
Недавно вышло интересное исследование про удалённую работу. Основными респондентами стали жители США, Канады, Великобритании. Сфера деятельности - IT, маркетинг, консалтинг.
Краткий выводы исследования:
1) Специалисты этих сфер в подавляющем большинстве работают удалённо
2) Самое распросранённое место "Работы" - дом
3) Самым большим недостатком удалённой работы участники опроса назвали "невозможность перестать работать после работы". То есть они всегда на связи
Конечно данные опроса на данный момент не применимы к России, но скорее всего через несколько лет картина в нашей стране будет схожей
https://buffer.com/state-of-remote-work-2019
Краткий выводы исследования:
1) Специалисты этих сфер в подавляющем большинстве работают удалённо
2) Самое распросранённое место "Работы" - дом
3) Самым большим недостатком удалённой работы участники опроса назвали "невозможность перестать работать после работы". То есть они всегда на связи
Конечно данные опроса на данный момент не применимы к России, но скорее всего через несколько лет картина в нашей стране будет схожей
https://buffer.com/state-of-remote-work-2019
Buffer: All-you-need social media toolkit for small businesses
Buffer | State Of Remote Work 2019
Buffer | 2019 Remote Work Report
Тема дня связка бэка с фронтом.
Не секрет, что главные проблемы в ИТ не технические, а связанные с miss communication.
Типичная проблема - разногласия между командами бэкенда и фронтенда.
Рассмотрим ситуацию: бэкенд выставляет АПИ, фронтендщики им активно пользуются. И как обычно что-то в процессе разработки отваливается, ломается. Бэкендщики что-то задеплоили на дев в 2 ночи, с утра пришли фронтэндщики - и ничерта не работает.
Обычно команды митигируют этот риск следующем образом:
1) Команда фронтенда мокает бэкенд. С одной стороны это самый надёжный вариант: "Бэк" доступен с локальной машины или со специально отведённой на это машины. Но я этот вариант люблю меньше всего: его очень дорого поддерживать. Так как АПИ меняется, то много времени приходится тратить именно на доработку мока АПИшки. Также момент отлавливания ошибок на бэкенде откладывается до выката релиза на стэйджинг, ведь до этого момента фронтенд не взаимодействует с бэком, а по сути, именно фронтендщики являются тестировщиками бэка.
2) Разворачивать бэкенд локально на машинах фронтэндщиков. Более приемлемый на мой взгляд вариант, когда фронтендщик может локально развернуть бэкенд на своей машине. Сложности начинаются, когда бэкенд не представляет из себя монолит или требует очень много ресурсов. Это затрудняет работу разработчиков, но зато позволяет отлавливать ошибки бэкендщиков раньше. Ведь по умолчанию у разработчика будет развёрнут актуальный дев, и только в случае, если он некорректно работает, фронтендщик будет запускать устаревшую, но исправную версию.
3) Содержание стабильного стэйджинга для бэка, с которым по умолчанию работает фронт. Вариант очень хорош: фронтендщики по умолчанию работают с девом, но, если тот падает, переключаются на стэйджинг. С каким бэком работать - разработчики выбирают через переменные среды или заранее установленные константы. Минус - стоимость поддержки стэйджинга. Может быть высокой и нецелесообразной на начальных стадиях проекта.
Глупо было бы не использовать АПИ тестирование для избегания этих проблем. Причем стоимость этого решения значительно дешевле, чем вышеприведённые варианты.
Допустим, АПИ содержит 100 методов, из них фронтендщики активно используют 20-30. Достаточно написать 20-30 тестов с двумя assertions и прогонять их в рамках ci/cd процесса на бэке или хотя бы просто запускать их раз в 10 минут, чтобы знать состояние АПИ. Assertion'а достаточно два: на статус запроса и на проверку его контента. Обычно нам достаточно знать, что запрос возвращает 200 и ответ содержит какой-то id или какую-то стрингу. Дёшево и сердито, зато надёжно и является стартовой площадкой для последующего полноценного интеграционного и нагрузочного тестирования.
Конечно, можно было бы также сказать, что «Надо просто настроить нормальный мониторинг с нотификациями и алертами», и с этим сложно не согласиться. Но есть ситуации, когда подобные АПИ тесты будут более эффективны и востребованы.
Не секрет, что главные проблемы в ИТ не технические, а связанные с miss communication.
Типичная проблема - разногласия между командами бэкенда и фронтенда.
Рассмотрим ситуацию: бэкенд выставляет АПИ, фронтендщики им активно пользуются. И как обычно что-то в процессе разработки отваливается, ломается. Бэкендщики что-то задеплоили на дев в 2 ночи, с утра пришли фронтэндщики - и ничерта не работает.
Обычно команды митигируют этот риск следующем образом:
1) Команда фронтенда мокает бэкенд. С одной стороны это самый надёжный вариант: "Бэк" доступен с локальной машины или со специально отведённой на это машины. Но я этот вариант люблю меньше всего: его очень дорого поддерживать. Так как АПИ меняется, то много времени приходится тратить именно на доработку мока АПИшки. Также момент отлавливания ошибок на бэкенде откладывается до выката релиза на стэйджинг, ведь до этого момента фронтенд не взаимодействует с бэком, а по сути, именно фронтендщики являются тестировщиками бэка.
2) Разворачивать бэкенд локально на машинах фронтэндщиков. Более приемлемый на мой взгляд вариант, когда фронтендщик может локально развернуть бэкенд на своей машине. Сложности начинаются, когда бэкенд не представляет из себя монолит или требует очень много ресурсов. Это затрудняет работу разработчиков, но зато позволяет отлавливать ошибки бэкендщиков раньше. Ведь по умолчанию у разработчика будет развёрнут актуальный дев, и только в случае, если он некорректно работает, фронтендщик будет запускать устаревшую, но исправную версию.
3) Содержание стабильного стэйджинга для бэка, с которым по умолчанию работает фронт. Вариант очень хорош: фронтендщики по умолчанию работают с девом, но, если тот падает, переключаются на стэйджинг. С каким бэком работать - разработчики выбирают через переменные среды или заранее установленные константы. Минус - стоимость поддержки стэйджинга. Может быть высокой и нецелесообразной на начальных стадиях проекта.
Глупо было бы не использовать АПИ тестирование для избегания этих проблем. Причем стоимость этого решения значительно дешевле, чем вышеприведённые варианты.
Допустим, АПИ содержит 100 методов, из них фронтендщики активно используют 20-30. Достаточно написать 20-30 тестов с двумя assertions и прогонять их в рамках ci/cd процесса на бэке или хотя бы просто запускать их раз в 10 минут, чтобы знать состояние АПИ. Assertion'а достаточно два: на статус запроса и на проверку его контента. Обычно нам достаточно знать, что запрос возвращает 200 и ответ содержит какой-то id или какую-то стрингу. Дёшево и сердито, зато надёжно и является стартовой площадкой для последующего полноценного интеграционного и нагрузочного тестирования.
Конечно, можно было бы также сказать, что «Надо просто настроить нормальный мониторинг с нотификациями и алертами», и с этим сложно не согласиться. Но есть ситуации, когда подобные АПИ тесты будут более эффективны и востребованы.
Сегодняшняя тема - зрелые/незрелые специалисты.
Недавно со мной поделились случаем: Олегу дали сложное задание, связанное со сбором требований для подготовки среды для разворачивания системы. Проект содержал множество зависимостей, и под некоторыми версиями операционных систем некоторые используемые библиотеки работали некорректно.
Олег обратился за помощью к Кириллу, старшему разработчику за советом, главному герою нашего рассказа. Кирилл по доброй воле и в своё личное время начал разбираться с проблемой, провёл пару дней над сборками и вернулся к Олегу с ответом. Ответ был не тривиальным, поэтому на разъяснения и ликбез требовалось время. Начали.
Через несколько минут к коллегам подошёл Антон, товарищ по работе и начал с Олегом обсуждать последние новости. И Антон с Олегом разговорились, обсуждая крайне интересные пикантные подробности последней презентации Apple. Наконец, когда через 10 минут коллеги увлеклись смакованием выхода на сцену новоиспечённого Тима Эппла, Кирилл не выдержал и ушёл. Ибо нефиг.
Рассказывая эту историю, Кирилл спрашивал меня, правильно ли он сделал. Стоило ему сказать коллегам "а вы не охренели"? и вернуть внимание Олега к проблеме или забить болт и послать Олега в следующий раз, когда тот обратиться за помощью.
1) Очевидно, что Олег незрелый специалист. Может он крутой кодер, потрясающий девопс, великолепно печёт блинчики, но он незрелый специалист. Он не уважает время своего коллеги и видимо не умеет работать в команде.
2) А что насчёт Кирилла? Кто он в данном случае? С одной стороны, он помогает коллеге, решает сложную задачу, что и соответствует его статусу Старшего разработчика. С другой стороны, если смотреть по факту, то задача в итоге не решена, профита команда не получила, зато между коллегами назревает конфликт. Кирилл точно не остался в выйгрыше.
Если бы Кирилл смог разрулить ситуацию на корню, без конфликтов, донести проблематику до Олега, то тогда бы точно можно было сказать "Кирилл - красавец. Кирилл - однозначно зрелый специалист". Но этого не произошло. С другой стороны сказать, что Кирилл незрелый специалист - язык не поворачивается. Но если добавить в контекст, что Кирилл - кандидат на тим лида, то весы качнутся в сторону незрелого.
Если вы менеджер или тимлид - уволить косячащего сотрудника обычно несложно. Сложно - суметь перенаправить его энергию в правильное русло и сделать эффективным членом команды.
Недавно со мной поделились случаем: Олегу дали сложное задание, связанное со сбором требований для подготовки среды для разворачивания системы. Проект содержал множество зависимостей, и под некоторыми версиями операционных систем некоторые используемые библиотеки работали некорректно.
Олег обратился за помощью к Кириллу, старшему разработчику за советом, главному герою нашего рассказа. Кирилл по доброй воле и в своё личное время начал разбираться с проблемой, провёл пару дней над сборками и вернулся к Олегу с ответом. Ответ был не тривиальным, поэтому на разъяснения и ликбез требовалось время. Начали.
Через несколько минут к коллегам подошёл Антон, товарищ по работе и начал с Олегом обсуждать последние новости. И Антон с Олегом разговорились, обсуждая крайне интересные пикантные подробности последней презентации Apple. Наконец, когда через 10 минут коллеги увлеклись смакованием выхода на сцену новоиспечённого Тима Эппла, Кирилл не выдержал и ушёл. Ибо нефиг.
Рассказывая эту историю, Кирилл спрашивал меня, правильно ли он сделал. Стоило ему сказать коллегам "а вы не охренели"? и вернуть внимание Олега к проблеме или забить болт и послать Олега в следующий раз, когда тот обратиться за помощью.
1) Очевидно, что Олег незрелый специалист. Может он крутой кодер, потрясающий девопс, великолепно печёт блинчики, но он незрелый специалист. Он не уважает время своего коллеги и видимо не умеет работать в команде.
2) А что насчёт Кирилла? Кто он в данном случае? С одной стороны, он помогает коллеге, решает сложную задачу, что и соответствует его статусу Старшего разработчика. С другой стороны, если смотреть по факту, то задача в итоге не решена, профита команда не получила, зато между коллегами назревает конфликт. Кирилл точно не остался в выйгрыше.
Если бы Кирилл смог разрулить ситуацию на корню, без конфликтов, донести проблематику до Олега, то тогда бы точно можно было сказать "Кирилл - красавец. Кирилл - однозначно зрелый специалист". Но этого не произошло. С другой стороны сказать, что Кирилл незрелый специалист - язык не поворачивается. Но если добавить в контекст, что Кирилл - кандидат на тим лида, то весы качнутся в сторону незрелого.
Если вы менеджер или тимлид - уволить косячащего сотрудника обычно несложно. Сложно - суметь перенаправить его энергию в правильное русло и сделать эффективным членом команды.
Тема дня: сети как база для понимания архитектуры.
Самые модные и востребованные на данный момент архитектурные требования - это масштабируемость, производительность и надёжность. Когда мы говорим про high load - мы говорим именно про таких монстров. Так вот, именно сетевые инженеры построили системы, отвечающие этим качественным метрикам. Практически любому архитектурному подходу можно найти альтернативу из мира сетей.
Есть примеры решения стандартных задач по балансировке нагрузки, по обеспечению отказоустойчивости, по созданию peer-to-peer соединений. Как только вы спроектируете сеть на 40 пользователей, вы уже скорее всего познакомитесь с master-slave подходом. И он будет для вас нативным, понятным. Намного проще познакомиться с этими азами на примере сетей, нежели баз данных.
Для знакомства с сетями я рекомендую попробовать пройти сертификацию cisco CCNA. Есть огромное количество материалов, позволяющих это сделать. При подготовке, вы будете строить сети в cisco packet tracer'е. Работа через cli и знакомство с крутыми алгоритмами по оптимальной доставке пакетов вам обеспечена.
Я рекомендую вот этот https://www.youtube.com/playlist?list=PLcDkQ2Au8aVNYsqGsxRQxYyQijILa94T9
Самые модные и востребованные на данный момент архитектурные требования - это масштабируемость, производительность и надёжность. Когда мы говорим про high load - мы говорим именно про таких монстров. Так вот, именно сетевые инженеры построили системы, отвечающие этим качественным метрикам. Практически любому архитектурному подходу можно найти альтернативу из мира сетей.
Есть примеры решения стандартных задач по балансировке нагрузки, по обеспечению отказоустойчивости, по созданию peer-to-peer соединений. Как только вы спроектируете сеть на 40 пользователей, вы уже скорее всего познакомитесь с master-slave подходом. И он будет для вас нативным, понятным. Намного проще познакомиться с этими азами на примере сетей, нежели баз данных.
Для знакомства с сетями я рекомендую попробовать пройти сертификацию cisco CCNA. Есть огромное количество материалов, позволяющих это сделать. При подготовке, вы будете строить сети в cisco packet tracer'е. Работа через cli и знакомство с крутыми алгоритмами по оптимальной доставке пакетов вам обеспечена.
Я рекомендую вот этот https://www.youtube.com/playlist?list=PLcDkQ2Au8aVNYsqGsxRQxYyQijILa94T9
Код продакта | Александр Иосса pinned «Инженеры программного обеспечения - люди, которые берут на себя ответственность за выполненную работу. Этот канал о них. Руководствуясь лозунгом "It depends", они не спешат сразу отвечать на поставленный вопрос и предлагать решение проблемы. Ведь надо прикинуть…»
Тема дня: трэкинг. Трэкать время или нет.
Сразу скажу, что данный пост не относится к удалённое работе, когда сотрудник получает почасовую оплату. Сейчас мы говорим про работу в офисе.
Что даёт трэкинг мэнеджменту? Реально потраченное время на задачи, которые были занесены в джиру. Не больше.
Оно не даёт реальной стоимости выполнения задачи или эпика, времени работы над каким-то функционалом. Некоторые задачи проходят в обсуждениях, которые не трэкаются. Кто-то забывает трэкать время, потраченное на код ревью, тестирование. В итоге погрешность будет составлять около 20%. Нужна ли метрика с такой погрешностью?
Вы скажете, что нужна дисциплина трэканья времени и тогда метрики будут более точными, но так ли это? Ведь дисциплина выстраивается, когда есть мотивация, например, KPI. А ведь мы знаем, что как раз-таки затрэканное время нельзя использовать для расчёта KPI. Иначе цифры начнут врать сразу же, после первой зарплаты. Получается замкнутый круг с единственным вопросом: так зачем вообще трэкать?
Получается, что трэкать время мы можем только тогда, когда рассчитываемся с разработчиками за время. Но там и системы трэканья стоять сложные: следят за движением мышки, пытаются понять, когда пользователь out of keyboard. При этом даже в TopTal этого не делают. Лично я против такой тирании в офисе.
А что думаете вы?
Оставляйте свои комментарии
Сразу скажу, что данный пост не относится к удалённое работе, когда сотрудник получает почасовую оплату. Сейчас мы говорим про работу в офисе.
Что даёт трэкинг мэнеджменту? Реально потраченное время на задачи, которые были занесены в джиру. Не больше.
Оно не даёт реальной стоимости выполнения задачи или эпика, времени работы над каким-то функционалом. Некоторые задачи проходят в обсуждениях, которые не трэкаются. Кто-то забывает трэкать время, потраченное на код ревью, тестирование. В итоге погрешность будет составлять около 20%. Нужна ли метрика с такой погрешностью?
Вы скажете, что нужна дисциплина трэканья времени и тогда метрики будут более точными, но так ли это? Ведь дисциплина выстраивается, когда есть мотивация, например, KPI. А ведь мы знаем, что как раз-таки затрэканное время нельзя использовать для расчёта KPI. Иначе цифры начнут врать сразу же, после первой зарплаты. Получается замкнутый круг с единственным вопросом: так зачем вообще трэкать?
Получается, что трэкать время мы можем только тогда, когда рассчитываемся с разработчиками за время. Но там и системы трэканья стоять сложные: следят за движением мышки, пытаются понять, когда пользователь out of keyboard. При этом даже в TopTal этого не делают. Лично я против такой тирании в офисе.
А что думаете вы?
Оставляйте свои комментарии
Тема дня: рисуем архитектуру или давайте говорить на одном языке.
Многие разработчики говорят на совершенно разных языках об одном и том же и спорят до потери пульса, кто из них прав. Узнаёте ситуацию, когда вам приходилось объяснять коллегам свою точку зрения, её не понимали и не принимали, но через несколько часов жарких обсуждений оказывалось, что вы говорите об одном и том же?
Причина таких недопониманий - разный бэкграунд. ФПшник и ООПшник будут очень долго спорить об одном и том же, совершенно не понимая термины друг друга. Ну не учат нигде архитектуре - универсальному языку, на котором по-хорошему должны разговаривать разработчики. Потому что в ИТ мы попадаем в основном через небольшие проекты и халтурки, самообразование и курсы типа "Сделаем первое мобильное приложение".
Как бороться с этим?
Добавьте контекст. Оформите его схемами и выложите в Readme файл. Одной Dynamic view достаточно, чтобы разработчики начали понимать друг друга и мыслить одинаково.
У нас было около 4-5 бесполезных обсуждений архитектуры приложения до появления схемы. Как только она появилась - стороны конфликта примерились и наконец-то появился конструктив.
Сколько бы фронтенд разработчики не объясняли бэкендщикам, что их АПИ неудобно, пусть и правильно, бэкендщику очень сложно понять боль фронтендщика. У нас же "JSON API", это стандарт, признанный всеми, чего вам ещё не хватает?
Рисуешь Sequence diagram, на которой видно, что для загрузки главной страницы требуется 7 последовательных запросов, и бэкенд разработчик меняется в лице.
ИМХО: уважающий себя разработчик должен уметь рисовать схемы. Я уж не говорю про communication skills, это другая больная тема.
В данном посте и на 5% не раскрыта правильное проектирование и документирование архитектуры и не претендует на это. Это лишь первый шаг)
Многие разработчики говорят на совершенно разных языках об одном и том же и спорят до потери пульса, кто из них прав. Узнаёте ситуацию, когда вам приходилось объяснять коллегам свою точку зрения, её не понимали и не принимали, но через несколько часов жарких обсуждений оказывалось, что вы говорите об одном и том же?
Причина таких недопониманий - разный бэкграунд. ФПшник и ООПшник будут очень долго спорить об одном и том же, совершенно не понимая термины друг друга. Ну не учат нигде архитектуре - универсальному языку, на котором по-хорошему должны разговаривать разработчики. Потому что в ИТ мы попадаем в основном через небольшие проекты и халтурки, самообразование и курсы типа "Сделаем первое мобильное приложение".
Как бороться с этим?
Добавьте контекст. Оформите его схемами и выложите в Readme файл. Одной Dynamic view достаточно, чтобы разработчики начали понимать друг друга и мыслить одинаково.
У нас было около 4-5 бесполезных обсуждений архитектуры приложения до появления схемы. Как только она появилась - стороны конфликта примерились и наконец-то появился конструктив.
Сколько бы фронтенд разработчики не объясняли бэкендщикам, что их АПИ неудобно, пусть и правильно, бэкендщику очень сложно понять боль фронтендщика. У нас же "JSON API", это стандарт, признанный всеми, чего вам ещё не хватает?
Рисуешь Sequence diagram, на которой видно, что для загрузки главной страницы требуется 7 последовательных запросов, и бэкенд разработчик меняется в лице.
ИМХО: уважающий себя разработчик должен уметь рисовать схемы. Я уж не говорю про communication skills, это другая больная тема.
В данном посте и на 5% не раскрыта правильное проектирование и документирование архитектуры и не претендует на это. Это лишь первый шаг)
Тема дня: Полгода с 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 - это надолго. И это хорошо)
Для тех, кто торопится: всё огонь, в команде, в которой есть хотя бы один 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 - это надолго. И это хорошо)
HolyJS Conference for JavaScript developers
Evolution of TypeScript: curiouser and curiouser
19 - 20 мая в Санкт-Петербурге состоится JavaScript-конференция HolyJS 2018 Piter. Не просто фронтенд-конференция, коих много. HolyJS – единственная в своем роде конференция, посвященная только JavaScript.
Тема дня: 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.
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.
Тема дня: 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'а
Для статического анализа вашего кода помимо стандартного линтера подойдут инструменты типа Sonar Qube который покажет и ваш приблизительный уровень технического долга, и некоторые security issues, и откровенные баги. Прикрепляю пример отчёта с официального сайта.
Любое требование к системе можно отнести к одной из следующих качественных метрик:
- 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, и откровенные баги. Прикрепляю пример отчёта с официального сайта.
Тема дня: ода к 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'ами не обойдёшься
На разных проектах приходилось сталкиваться с 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'ами не обойдёшься
Тема дня: немного о процессах.
На днях разговаривал с молодой командой ребят, занимающихся своим стартапом.
Спрашивали меня, что нужно для стартапа? Какой процесс выбрать, как работу организовать. Почему-то очень удивились, когда я им сказал, что процессы и стартап это вещи друг с другом очень слабо связанные. То есть конечно круто, если вы сразу же можете организовать правильно свою работу, но для стартапа это последнее, на что стоит обращать внимание.
Из 100 потенциальных инвесторов 1 спросит хотя бы о языке, на котором вы делаете проект, не то что о процессе. Конечно, это касается в первую очередь России. В общем посоветовал им в бизнес инкубатор податься, куда ж ещё.
С другой стороны разговаривал с американскими коллегами, обсуждали стройность процессов, их зрелость и так далее. Разговор зашёл о CMMI. Спросил, у кого-то в организации есть корочка? Ответ был простым "Мы не индусы и гос заказы не выполняем, нафига нам это?" Полная аналогия с другими сертификатами. Нужны в основном для тендеров и резюме, практической пользы мало.
На днях разговаривал с молодой командой ребят, занимающихся своим стартапом.
Спрашивали меня, что нужно для стартапа? Какой процесс выбрать, как работу организовать. Почему-то очень удивились, когда я им сказал, что процессы и стартап это вещи друг с другом очень слабо связанные. То есть конечно круто, если вы сразу же можете организовать правильно свою работу, но для стартапа это последнее, на что стоит обращать внимание.
Из 100 потенциальных инвесторов 1 спросит хотя бы о языке, на котором вы делаете проект, не то что о процессе. Конечно, это касается в первую очередь России. В общем посоветовал им в бизнес инкубатор податься, куда ж ещё.
С другой стороны разговаривал с американскими коллегами, обсуждали стройность процессов, их зрелость и так далее. Разговор зашёл о CMMI. Спросил, у кого-то в организации есть корочка? Ответ был простым "Мы не индусы и гос заказы не выполняем, нафига нам это?" Полная аналогия с другими сертификатами. Нужны в основном для тендеров и резюме, практической пользы мало.