Good dev knows

Что нужно отдыхать 🌴

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

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

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

◼️Ещё раз — умение отдыхать это софт скилл. Его нужно развивать. А вот отказ от переработок должен быть данностью.

Следите за своим отдыхом? Пишите в комментариях.

#софтскиллы

​​Что такое concurrency и parallelism

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

Когда мы это обсуждаем, то говорим, например, так: "Этот парсер будет работать в 10 потоков". И запускаем 10 горутин. Давайте разберемся, действительно ли это так? Что такое concurrency, а что такое parallelism.

1️⃣ Concurrency

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

2️⃣ Parallelism

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

Эти определения актуальны везде - при обработке транзакций в базе данных; на сервере; в сети, при использовании общих сетевых ресурсов.

Если у вас 1 процессор и вы запускаете 10 горутин, то ничего не будет обрабатываться параллельно. Это все еще concurrency. Но обрабатываться будет все равно быстрее, чем просто в одном потоке и последовательно. А вот если вы делаете пул потоков по количеству процессоров, и они обрабатывают задачи из очереди — это уже parallelism.

⬛️ Еще раз — concurrency и parallelism это разные вещи. Главное, что они обе позволяют обрабатывать информацию быстрее. Но разницу тоже знать важно — если будет нужна дальнейшая оптимизация.

Любите горутины? Или может worker threads? Пишите в комментариях.

#хардскиллы

Истории и чужой опыт

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

К концу прошлого года я работал в SHARE NOW уже более трех лет. Я ощущал, что я делаю намного больше вещей, чем когда я начинал в 2018. Я чувствовал, что делаю это лучше. По моим ощущениям это уже превышало тайтл Senior Software Engineer.

На очередном 1-1 я поднял этот вопрос со своим менеджером. Есть ли в SHARE NOW возможности расти дальше чем Senior и не переходить в менеджмент трек? Мне ответили, что сейчас как раз компания завершает формализацию требований для разных уровней и как только что-то будет, то мне скажут.

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

Так что я вызывался помогать с формализацией этого процесса. Я связался с другом, который работает в Amazon и поспрашивал как это происходит у них. В итоге, учитывая их опыт, в SHARE NOW мы решили делать так:

1. Промоушен на позицию Principle Engineer происходит по принципу in position. То есть человек должен уже какое-то время соответствовать этим критериям.
2. В первую очередь менеджер соискателя должен рекомендовать промоушен.
3. Желающий должен инициировать промоушен формально, главе своей локации. Для этого составив promotion document, где он/она описывает свое соответствие критериям приводя примеры. Там же есть рекомендация на промоушен от менеджера.
4. Дальше, если этого документа достаточно, созывается митинг со skip-level менеджерами, где соискатель презентует свой промоушен и ему задают вопросы.
5. Дальше решение принимается группой менеджеров, где ваш менеджер тоже участвует, но у него нет права голоса.

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

1. Больше влияния вне команды
2. Больше менторинга Senior специалистов
3. Больше влияния на весь инженеринг

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

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

Что думаете, у вас был когда-нибудь формальный промоушен процесс?

#истории

Хороший разработчик знает разные способы принятия решения на митинге.

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

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

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

1️⃣ Consensus — каждый из участников искренне поддерживает решение.

2️⃣ Consent — все участники согласны, что решение "достаточно" хорошее.

3️⃣ Compromise — каждый из участников отказывается от каких-то своих желаний, чтобы достичь общего решения.

4️⃣ Count — принимается то решение, которое набирает большее количество голосов.

5️⃣ Consult — человек, который принимает решение, заинтересован узнать мнение группы. Но решение принимает он/она.

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

Например, если решение принимается голосованием (Count), то могут быть люди, которые голосовали против. Вполне вероятно, что они не будут чувствовать себя ответственными за принятое решение.

◼️ Еще раз — если мы хотим чтобы исполняли решение, они должны быть вовлечены. На это напрямую влияет метод принятия решения.

Сколько митингов в месяц вы собираете? Пишите в комментарии.

Хороший разработчик знает как выбрать тип процессора в облаке

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

Давайте посмотрим, какие варианты у нас есть:

1️⃣ CPU — central processing unit. Самый обычный процессор, такой стоит в вашем компьютере. Такие процессоры проще всего программировать. Они подходят для большинства стандартных задач.
CPU состоит из нескольких ядер.

2️⃣ GPU — graphical processing unit. Изначально такие процессоры предназначались для обработки графики. Но стали применяться и в других задачах, где нужен большой объем параллельных вычислений.
GPU процессор состоит из тысяч ядер. Важно, что, чтобы использовать эти преимущества, ваша программа должна уметь работать с таким процессором.

3️⃣ FPGA — field-programmable gate array. Это железо, которое можно низкоуровнево запрограммировать, чтобы оно стало лучше обрабатывать определенные задачи. Грубо говоря, такой процессор сперва нужно прошить, а только потом использовать.

4️⃣ ASIC - application-specific integrated circuit. В этом случае процессор сразу производят оптимизированным для выполнения определенных задач. Например, Google предлагает tensor processing unit для обработки TensorFlow задач.

Если характеризовать эти процессоры по цене 💰(больше мешков = дороже), эффективности 📈 и гибкости ⚖️, то будет так:

1. CPU: 💰, 📈, ⚖️⚖️⚖️⚖️
2. GPU: 💰💰, 📈📈, ⚖️⚖️⚖️
3. FPGA: 💰💰💰, 📈📈📈, ⚖️⚖️
4. ASIC: 💰💰💰💰, 📈📈📈📈, ⚖️

◼️Еще раз — процессоры бывают разные, обычно хватает CPU. Если не хватает и софт позволяет, то можно использовать GPU. Если все еще не хватает — поздравляю, вы работаете над чем-то интересным.

Использовали когда-нибудь GPU? Пишите в комментариях.

Произошел пивот!

Некоторые знают, что вместе с телеграм каналом, я пытался/юсь развивать TikTok. Где выкладываю видео ролики о том, что знает Хороший разработчик.

Так вот, после 3-х недель выкладывания роликов я сдался, потому что TikTok оказался не в состоянии найти мою аудиторию. А именно - он тестировал мои ролики в 🇩🇪Германии, где шансов стать просмотренными у них не было. Потому что я ведь говорю там по-русски.

Несмотря на все мои ухищрения, я не смог выбраться из этой ловушки. Поэтому я задействовал план Х. И теперь мои ролики выкладываются на другом аккаунте и на другом телефоне, прямо из 🇺🇦 Украины, с аккаунта зарегистрированного на украинскую симку. Сейчас посмотрим кто кого, TikTok.

Новый аккаунт пока тут: https://www.tiktok.com/@gooddevknows.official. Приглашаю вас зайти и посмотреть, подписаться и полайкать.

Например, 🎥 про YAGNI и аренду летучих мышей.

Еще я сделал такие выводы:
1. Ролики должны быть короче
2. Тогда их будет легче производить и монтировать
3. Поэтому в Телеграмме я буду продолжать писать большие посты, а в TikTok снимать кусочками.

Надеюсь боги китайских алгоритмов будут ко мне более благосклонны в этот заход.

Вы вообще как, смотрите TikTok?

Хороший разработчик знает истории и учится на чужом опыте

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

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

Однажды и мне поручили внести какое-то изменение в этот продукт. Процесс разработки был тоже простой — правь php файлы по ftp и смотри что получилось. В базу ходи через phpMyAdmin. Окружений было два - integration и production. Разница была в названии баз данных, которые они использовали.

И вот в какой-то чудный момент я, с помощью phpMyAdmin дропнул таблицу в базе данных. Я делал это уже десятки раз. Моя рука обладала мышечной памятью. Без секунды сомнения мой палец подтвердил удаление в появившемся попапе. Дело было сделано. Еще через минуту я понял, что я удалил таблицу в production базе данных. Это была основная таблица, та, где хранились таски.

Я обновил страницу в phpMyAdmin — таблицы не появилось 🙀. Через 5 минут судорожных кликов по табам в браузере я решил сказать об этом кому-то еще. Дальше пошел damage control.

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

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

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

1. Должна быть возможность развернуть проект локально. С локальной инфраструктурой.
2. Периодически нужно проверять что бэкапы работают. Сейчас лучше отдать это на аутсорс и использовать, например, AWS RDS.
3. Нужно чтобы команда знала как реагировать на такие ситуации. Лучше всего проводить 🎯 Game day.

◼️Еще раз — удалять базу данных на продакшене не страшно, такое точно будет происходить и в будущем. Но важно, чтобы команда была к этому готова. Design for failure.

Какие еще ошибки вы увидели? Пишите в комментариях.

Хороший разработчик знает кто такие Staff и Principal инженеры.

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

Большинство разработчиков как-то представляет карьерную лестницу до Senior. Давайте быстро по ней пробежимся (условно):

1️⃣ Junior — в целом что-то понимает. Еще не понятно как настроить IDE, ошибки компилятора вызывают грусть. Не спешит принимать решения самостоятельно.
2️⃣ Middle — если кто-то расскажет что и как надо сделать, то он сможет это сделать. Может потом в мердж риквесте окажется что он не покрыл какие-то граничные случаи, но работать будет. Иногда предлагает оптимизации.
3️⃣ Senior — сформировавшийся специалист, задается вопросом ПОЧЕМУ мы должны это делать? Принимает информированные решения, анализирует трэйд-оффы, измеряет. Координирует разработку в команде, является тем "кто-то" для мидла. Делится знаниями, поддерживает Middle и Junior. В основном влияет на свою команду.

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

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

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

Для этого существуют уровни Staff и/или Principal. Обычно они появляются в компаниях с 30+ инженерами. Эти уровни можно объединить под Staff+

4️⃣ Staff+ — основное различие от Senior это уровень влияния. Он постоянно влияет на несколько команд, иногда на всю компанию. Улучшает процессы и технологии во всем инжинеринге. Менторит Senior людей. Хорошо знает доменную область. Координирует взаимодействие между командами. Учавствует в принятии стратегических решений.

Я описал продактового Staff+. Есть еще и с фокусом на технологию, например, у вас в компании работает создатель какого-то популярного опенсорс фреймворка.

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

Согласны с описанием? Пишите в комментарии.

Хороший разработчик знает как правильно сравнивать расходы на инфраструктуру или что такое TCO.

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

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

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

* далее все расчеты примерны

1️⃣ Предположим, что мы думаем разместить это на Hetzner - сервер для приложения и вебсокетов, сервер для базы данных и файловое хранилище для картинок на 5 терабайт. Примерно, это будет стоить 45€ + 45€ + 27€ = 120€ в месяц.

2️⃣ Теперь посмотрим на AWS. Приложение разместим в Fargate - 320€ в месяц. База данных около 420€ в месяц. S3 который сохраняет по 1Тб в месяц - 23€. Итого 765€ в месяц.

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

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

А в случае с облачным решением за нас это будет делать AWS.

💵 Поэтому нужно сравнивать суммы 2120€ и 765€. Правильно сравнивать суммы, которые мы платим за Total Cost of Ownership.

⬛️ Еще раз - TCO это стоимость покупки ресурса + стоимость его обслуживания.

Считали раньше TCO? Расскажите в комментариях.

Давайте немного познакомимся и посмотрим кто у нас тут где. Меня зовут Павел, я в IT уже более 15 лет. Сейчас по документам я Senior, а по ощущениям Staff+. Работаю в SHARE NOW, каршеринг сервис в 🇩🇪 Германии.

Расскажите плз, где вы в IT, это поможет мне лучше готовить контент. Отвечайте по свои ощущениям, а не по документам.

Хороший разработчик знает истории и учится на чужом опыте.

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

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

Однажды кто-то заметил, что один 🧑‍💻 получил больше 10.000€. По бизнес правилам это было невозможно, потому что максимальный кредит который мы давали был 1500€ в одни руки.

Мы стали разбираться, и выяснили, что он получил выплату по одной заявке 8 раз! Мы стали копать дальше, и выяснили что, скорее всего, 🧑‍💻 для результата достаточно было просто очень быстро нажимать на кнопку подачи заявки — когда происходит сабмит формы. Потому что мы успешно обработали одну и туже заявку 8 раз.

На фронт-энде мы просто делали кнопочку "серой", но не блокировали клики по ней. На бэк-энде мы проверяли статус заявки, но если нажимать с разницей в миллисекундах, то запросы будут обработаны разными копиями аппликейшена и статус не успевал обновляться. Это называется race condition, ну и наш security фэйл, конечно же.

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

⬛️ Еще раз, при проектировании всегда думайте что может пойти не так — design for failure. Мы не подумали и это стоило минимум 10.000€.

А у вас были какие-то security фейлы? Рассказывайте.

Хороший разработчик знает как использовать технику Fist to Five на митинге.

Иногда мы проводим митинги, например, чтобы договориться о чем-то с командой. В таком случае нам важно уметь оперативно узнать, что думают о том что мы обсуждаем участники. Здесь нам поможет техника Fist to Five.

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

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

С помощью техники ✊ To 🖐 мы получим фидбэк, есть ли у группы консенсус по вопросу. Готовы ли мы двигаться в направлении использования Kotlin? Для этого каждому нужно с помощью своей кисти отразить отношение к вопросу.

Можно показать 6 знаков:
1. Кулак — мне не нравится, я блокирую
2. Один палец — я вижу большие проблемы, которые нужно решить сейчас
3. Два пальца — я вижу небольшие проблемы, которые нужно решить сейчас
4. Три пальца — я вижу небольшие проблемы, которые нужно решить потом
5. Четыре пальца — мне нравится идея
6. Пять пальцев — идея супер, я готов вести этот проект

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

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

⬛️ Еще раз — митинги важны, а правильные инструменты сделают митинги эффективными. С помощью техники Fist to Five можно быстро узнать есть ли в группе консенсус по вопросу.

Хочешь узнать больше про митинги? Пиши в комментариях.

Хороший разработчик знает какие метрики нужно измерять.
🎥 Видео в TikTok.

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

Но что именно нужно мониторить? Исследования Google говорят, если вы можете мониторить только четыре метрики, то начните со следующих:

1. Latency
2. Traffic
3. Errors
4. Saturation

Они назвали их Four Golden Signals.

1️⃣ Latency

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

2️⃣ Traffic

Сколько трафика получает наш сервис? Для http сервисов это как правило измеряется в количестве запросов в секунду.

3️⃣ Errors

Коэффициент ошибок. Какой процент запросов заканчивается ошибкой? Если большой, то вероятно что-то идет не так, нужно проверить.

4️⃣ Saturation

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

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

⬛️ Еще раз - чтобы не было проблем, нужно на них оперативно реагировать. Для этого можно мониторить четыре золотых сигнала - latency, traffic, errors, saturation.

Было что-то новое для вас? Расскажите об этом в комментариях.

Хороший разработчик знает что такое DORA метрики.
🎥 видео в TikTok.

Современные процессы разработки включают в себя DevOps практики.

Как мы можем измерить насколько они хороши в нашей организации?

В течение 6 лет DevOps Research and Assessments (DORA) группа из Google проводила исследование, чтобы выявить метрики, которые отражают качество DevOps в командах.

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

1️⃣ Deployment frequency

Частота деплоев. Как часто ваша команда успешно релизит на продакшен? Чем чаще тем лучше.

2️⃣ Lead Time for Changes

Время внесения изменений. Сколько времени занимает путь от коммита в master до релиза на продакшен? Чем меньше тем лучше.

3️⃣ Change Failiure Rate

Коэффициент ошибок. Процент деплоев, которые привели к проблемам на продакшене. Чем меньше тем лучше.

4️⃣ Time to Restore Service

Время восстановления. Сколько времени нужно, чтобы восстановиться после ошибки на продакшене. Чем меньше — тем лучше.

Регулярно измеряя эти метрики вы можете получить оценку уровня DevOps и следить за ее прогрессом. Оценка может быть такой: Elite, High, Medium или Low.

⬛️ Еще раз — с помощью DORA метрик можно следить за качеством DevOps в вашей команде или организации. Для этого нужно измерять четыре метрики.

О чем еще рассказать про DevOps? Пишите в комментариях.

Хороший разработчик знает про виды нефункциональных требований.
🎥 видео в TikTok.

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

Большинство нефункциональных требований можно отнести к таким категориям:

1. Performance (производительность)
2. Security and compliance (безопасность и соблюдение правил)
3. Recoverability (возможность восстановления)
4. Maintainability (удобство в обслуживании)
5. Reliability (надежность)
6. Availability (доступность)
7. Scalability (масштабируемость)
8. Usability (удобство использования)

Теперь рассмотрим примеры.

Performance
- Как быстро для пользователя должен открываться сайт?

Security and compliance
- Как мы обезопасим приложение от неавторизованного доступа?
- Как мы можем обеспечить исполнение закона о защите персональных данных?

Recoverability
- Если база данных упадет, как мы можем восстановить данные?

Maintainability
- Если что-то идет не так, наш сервис шлет разработчикам уведомления об этом?

Reliability
- Как мы можем убедиться, что сервис работает стабильно?

Availability
- Если датацентр затопит — наш сервис продолжит работать?

Scalability
- Если ссылку на сайт разместят на reddit — он выдержит нагрузку?

Usability
- Как можно упростить для пользователя использование приложения?

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

Очень важно обдумывать и документировать такие требования как можно раньше.

Было интересно? Поделись каналом с другом.

Хороший разработчик знает что такое функциональные и нефункциональные требования.
🎥 видео в TikTok.

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

1️⃣ Функциональные требования или functional requirements
Чаще всего, когда мы разрабатываем программное обеспечение, мы знаем что оно должно делать. Еще лучше, когда мы знаем почему оно должно это делать. Для решения какой бизнес задачи мы пишем эту программу?

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

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

2️⃣ Нефункциональные требования или non-functional requirements

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

Например, есть множество вариантов куда сохранять картинки в нашем мессенджере — мы можем сложить их прямо на диск на сервере, а можем положить в S3. Но только вариант с S3 обеспечит хорошую долговечность этих картинок (99.999999999%).

Большинство нефункциональных требований можно отнести к таким категориям:

1. Performance (производительность)
2. Security and compliance (безопасность и соблюдение правил)
3. Recoverability (возможность восстановления)
4. Maintainability (удобство в обслуживании)
5. Reliability (надежность)
6. Availability (доступность)
7. Scalability (масштабируемость)
8. Usability (удобство использования)

⬛️ Еще раз - требования которые напрямую относятся к решению бизнес задачи — функциональные. А нефункциональные это требования которые могут напрямую быть не видны пользователю или клиенту, но могут сильно повлиять на их опыт.

Дальше мы подробно рассмотрим категории нефункциональных требований.

Хороший разработчик знает как что-то объяснить, часть 3
🎥 видео в TikTok.

Хорошее объяснение состоит из шести частей:

1. Соглашение
2. Контекст
3. История
4. Связь
5. Описание
6. Вывод

Давайте соберем все вместе на примере, я объясню почему аккаунт "Хороший разработчик знает" это маст хэв в подписках.

Известно, что быть разработчиком это супер. У тебя интересная работа, перспективы, хорошая компенсация.

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

🎬
Представьте Стаса, Стасу 25 лет, он back-end разработчик. Карьера Стаса топчется на месте, он миддл уже 3 года, менеджером быть не хочет, что делать дальше? Еще Стас любит TikTok, ведь тут можно залипнуть на смешные видео. Как-то раз Стасу в рекомендации попал ролик с аккаунта "Хороший разработчик знает", он был интересным, Стас узнал что-то новое. Стас решил подписаться на канал и через месяц понял куда ему расти как разработчику. Через 3 месяце Стаса запромоутили в синьора и подняли зарплату на 2 тысячи долларов.

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

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

Получать качественные знания из TikTok можно и это очень просто — подписывайся на аккаунт "Хороший разработчик знает" и расти как специалист.
🏁

Еще раз — хорошее объяснение состоит из соглашения, контекста, истории, связи, описания и вывода.

Сумели опознать все части в моем объяснении?

Хороший разработчик знает как что-то объяснить, часть 2.
🎥 видео в TikTok.

Мы разобрались что такое объяснение и какова его цель. Наша цель — чтобы человек, который нас слушает, почувствовал себя умнее и смог дальше углубиться в тему.

Существует простой рецепт как подготовить хорошее объяснение. Оно должно состоять из таких частей:

1. Соглашение
2. Контекст
3. История
4. Связь
5. Описание
6. Вывод

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

2️⃣ Контекст - почему вещь о которой мы говорим вообще важна?

3️⃣ История - без истории наши слова это просто факты. История добавляет эмоции, слушателю проще связать себя с проблемой. Простейший сюжет — был парень Стас. У Стаса была проблема и он был в отчаянии. Стас решил проблему и теперь он счастлив. Ты хочешь почувствовать себя как Стас?

4️⃣ Связь. Если нам нужно рассказать о чем-то, о чем слушатель вообще может не знать — рассказываем на примере того что он знает. Например, как рассказать про фильм "Чужой"? "Чужой" - это как фильм "Челюсти", только в космосе.

5️⃣ Описание. Чем дальше двигается человек по шкале понимания, тем более он хочет получить ответ на вопрос "Как?". Как сделать то о чем ты говоришь? Как мне тоже стать счастливым как Стас? Теперь можно начать описывать решение, упуская неважные подробности.

6️⃣ Вывод. Резюмируем все о чем мы сказали ранее и добавляем призыв к действию. Что человек должен сделать после объяснения?

⬛️ Еще раз — хорошее объяснение состоит из соглашения, контекста, истории, связи, описания и вывода.

Теперь соберем все вместе и посмотрим пример объяснения.

Подписывайся и смотри часть 3.

Хороший разработчик знает как что-то объяснить, часть 1

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

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

Когда мы что-то объясняем, мы помогаем слушателю ответить на вопрос "почему?". Почему, то что мы говорим это важно и стоит узнать больше про это? Объяснение снижает цену потребления информации. После того что он узнает, слушателю станет проще углубиться в тему самостоятельно.

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

Подумаем, кто будет нас слушать? Можно расположить слушателей на шкале понимания предмета.

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

⬛️ Еще раз - резюмируем, после нашего объяснения, слушатель должен почувствовать, что он стал умнее. Дальше он сможет сам начать разбираться в теме или спросить у нас подробности.

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