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

В этот канал я буду постить кусочки информации которую полезно было бы знать любому разработчику. В текстовом виде. А что еще интересно - у меня есть ТикТок: https://www.tiktok.com/@gooddevknows, где я в коротких видео тоже рассказываю о том, что знает хороший разработчик.

Поехали!

Хороший разработчик знает что такое OLTP и OLAP

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

1️⃣ OLTP - online transaction processing

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

Для OLTP часто используют реляционные базы данных, например PostgreSQL.

2️⃣ OLAP - online analytical processing

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

Для OLAP часто используются колоночные базы данных, предназначенные бля бизнес аналитики, например Amazon Redshift.

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

Хороший разработчик знает что такое KISS, YAGNI и DRY

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

1️⃣ KISS - keep it simple, stupid

Чем проще ваша программа, тем лучше она будет работать. Тем легче покрыть ее тестами. Не нужно выдумывать лишних абстракций, стараться сделать все максимально расширяемым в БУДУЩЕМ, делаем минимум, но хорошо, то есть просто и понятно.

2️⃣ YAGNI - you aren't gonna need it

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

3️⃣ DRY - don't repeat yourself

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

⬛️ Еще раз - не надо усложнять сейчас, если это нужно будет в будущем - время найдется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хороший разработчик знает что такое функциональные и нефункциональные требования.
🎥 видео в 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 (удобство использования)

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

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

Хороший разработчик знает про виды нефункциональных требований.
🎥 видео в 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
- Как можно упростить для пользователя использование приложения?

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

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

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

Хороший разработчик знает что такое 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.

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

Но что именно нужно мониторить? Исследования 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.

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

Хороший разработчик знает как использовать технику 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 можно быстро узнать есть ли в группе консенсус по вопросу.

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