Итак поехали) Меня зовут Кирилл Мокевнин и я занимаюсь разработкой с 2007 года. Как специалист я прошел путь от разработчика в квартирной веб-студии, до технического директора и побывав по пути vp of engineering. Поработал в продакшене с большим количеством языков (php, java/kotlin/clojure, python, erlang/elixir, ruby, javascript), разными направлениями (frontend, backend, devops, testing). Несколько лет занимался и иногда продолжаю заниматься консалтингом, обучая программистов, тому как эффективно делать их работу, а бизнес решать задачи в с минимальным количеством ресурсов и с нужной скоростью.

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

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

p.s. Мои статьи, выступления и другие активности можно найти тут: https://mokevnin.github.io/

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

Идея “дежурного программиста” понятная, но у нее есть неочевидные проблемы. Такой подход снимает ответственность с тех, кто делал фичи и что-то не додумал/не доделал, что привело к проблеме. Соответственно ребята гораздо меньше критически оценивают то что делают. Если поменять подход и чинить это силами тех, кто отвечает за эту фичу как ее главный реализатор, то вначале да, может быть отвлечение, но постепенно люди поймут что им же потом придется расхлебывать, а значит не надо доводить. Плюс это еще и хорошая метрика, у кого чаще так ломается, к тому вопросики, все ли хорошо по тестам, по процессам и так далее.

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

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

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

На самом деле, большинство пунктов так же применимо и к другим языкам. Большая их часть универсальна, так же проста (js, php или ruby не сильно отличаются на этом уровне) и в целом универсально подходит для всего (php конечно тут выпадает). Реальная же причина популярности кроется в неожиданном аспекте. Питон уже давно основной язык изучения Computer Science в университетах по всему миру. Я не скажу сколько точно это добавляет пунктов, но если посмотреть использование питона в разрезе конкретных направлений, то видно что разрыв резко уменьшается. Та же django, внезапно, проигрывает rails в веб разработке. А это довольно серьезная часть проектов на Python. И даже лидерство в аналитике достигается скорее за счет числа людей, которые с питоном соприкасаются, но надо понимать, что реального программирования там мало и объемы кода в аналитике не идут ни в какое сравнение с веб-разработкой.

В каком-то смысле, питону некисло повезло, что он оказался в таком положении. От этого он не становится хуже, но факт остается фактом, в реальных проектах его меньше чем может показаться на первый взгляд. Пруф: https://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-us-universities/fulltext

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

В двух словах: при конкурентном доступе к ресурсу, например, одновременной правке, могут возникнуть проблемы. Если открыть один файл в двух разных редакторах и после этого поправить в одном, то изменения во втором редакторе перепишут изменения сделанные в первом (если это не слишком умные редакторы), что будет крайне неприятно. Чтобы такого не происходило, нужно вводить блокировки.

Самый яркий пример применения блокировок это контроль версий. Одна из первых систем контроля версий RCS не позволяла одновременно работать над файлом. Если кто-то начинал править файл с кодом, то другие программисты физически не могли начать править файл, так как он блокировался. Такой подход называется пессимистической блокировкой. Git же (как и svn и cvs) работают по другому принципу. Они позволяют править код одновременно, но во время фиксации изменений, отслеживают предыдущие изменение и если его находят то запрещают сливать файл, заставляя выполнить ручное слияние (если необходимо). Такой подход называется оптимистической блокировкой.

Где мы с этим встречаемся как программисты? Во всех местах где есть возможность одновременной работы. Представьте любой CRUD на сайте. Например у вас есть команда редакторов, которая публикует посты в блоге. Что произойдет если два редактора решили поправить одну статью одновременно? Если ничего специально не делать, то работает схема “кто последний тот и папа”. Чтобы решить эту проблему можно реализовать одну из этих блокировок.

Какая блокировка изображена на картинке в начале поста? :)
В вашей практике была задача реализации подобной блокировки?

Месяц назад я выступал (удаленно) на конференции CodeFest с докладом: “5 проектов выходного дня, которые значительно повысят ваши навыки кодинга”. Фактически он был посвящен тому, как прокачать свои навыки и стать более крутым инженером. Там я привел в пример типичный подход, который есть в голове примерно у всех разработчиков:

• Глубже изучить язык и фреймворк.
• Изучить новый язык и фреймворк
• Прокачать алгоритмы
• Фронт => бек, бек => фронт

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

• Разработать свою библиотеку
• Разработать свой фреймворк
• Разработать инструмент (базу, веб-сервер, очереди)
• Написать свой язык программирования

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

В докладе я предложил 5 проектов, которые можно сделать буквально за 2-5 часов. Посмотрите, не пожалете https://www.youtube.com/watch?v=X1GsnskqQ14

Какой из проектов вы бы реализовали?