Итак поехали) Меня зовут Кирилл Мокевнин и я занимаюсь разработкой с 2007 года. Как специалист я прошел путь от разработчика в квартирной веб-студии, до технического директора и побывав по пути vp of engineering. Поработал в продакшене с большим количеством языков (php, java/kotlin/clojure, python, erlang/elixir, ruby, javascript), разными направлениями (frontend, backend, devops, testing). Несколько лет занимался и иногда продолжаю заниматься консалтингом, обучая программистов, тому как эффективно делать их работу, а бизнес решать задачи в с минимальным количеством ресурсов и с нужной скоростью.
Последние 10 лет я занимаюсь построением школы обучения программированию и как предприниматель и как автор курсов и как наставник. Несмотря на то, что сама школа направления в первую очередь на обучение новичков, меня самого всегда тянуло к тому, чтобу прокачивать тех кто уже начал свой путь в разработке, но еще не дошел до уровня матерого синьора. Для этого я регулярно писал и пишу статьи, выступаю на конференциях и иногда общаюсь в комьюнити нашей школы. Кое что я записываю на ютубе в своем канале, но понимаю что видео это скорее сопровождение, которое нужно подпитывать чем-то другим. Поэтому в итоге я и вы оказались тут.
Я долго оттягивал запуск своего канала, так как боялся не выдержать хороший ритм публикаций и коммуникации. Но, кажется, время пришло. Мне есть чем поделиться и что рассказать. Поехали!
p.s. Мои статьи, выступления и другие активности можно найти тут: https://mokevnin.github.io/
Последние 10 лет я занимаюсь построением школы обучения программированию и как предприниматель и как автор курсов и как наставник. Несмотря на то, что сама школа направления в первую очередь на обучение новичков, меня самого всегда тянуло к тому, чтобу прокачивать тех кто уже начал свой путь в разработке, но еще не дошел до уровня матерого синьора. Для этого я регулярно писал и пишу статьи, выступаю на конференциях и иногда общаюсь в комьюнити нашей школы. Кое что я записываю на ютубе в своем канале, но понимаю что видео это скорее сопровождение, которое нужно подпитывать чем-то другим. Поэтому в итоге я и вы оказались тут.
Я долго оттягивал запуск своего канала, так как боялся не выдержать хороший ритм публикаций и коммуникации. Но, кажется, время пришло. Мне есть чем поделиться и что рассказать. Поехали!
p.s. Мои статьи, выступления и другие активности можно найти тут: https://mokevnin.github.io/
👍11🎉4🔥2🤔1😐1
В комьюнити Хекслета возникла дискуссия по поводу одной фичи, в которой всплыл интересный момент: в обсуждаемой компании есть понятие дежурного программиста. Вот что я об этом думаю:
Идея “дежурного программиста” понятная, но у нее есть неочевидные проблемы. Такой подход снимает ответственность с тех, кто делал фичи и что-то не додумал/не доделал, что привело к проблеме. Соответственно ребята гораздо меньше критически оценивают то что делают. Если поменять подход и чинить это силами тех, кто отвечает за эту фичу как ее главный реализатор, то вначале да, может быть отвлечение, но постепенно люди поймут что им же потом придется расхлебывать, а значит не надо доводить. Плюс это еще и хорошая метрика, у кого чаще так ломается, к тому вопросики, все ли хорошо по тестам, по процессам и так далее.
Плюс у вас будет более правильная оценка реальной производительности. Так как велосити уменьшится и будет точнее показывать, что команда часто косячит так, что приходится постоянно штопать то что уже на проде. И лучше такое не прятать за дежурного, а наоборот, сделать так чтобы ваша система подсвечивала подобные проблемы
в нормальной ситуации проблем что сломалось и прямо щас надо бежать чинить не должно быть много на уровне фич. Маркетинг бывает да, инфраструктура может сбойнуть, но не фичи в чистом виде. Это значит что реально есть косяки в процессе производства. Что кстати не значит что там тестировщиками и стейджингами обкладываться. Релизить можно часто и с косяками, просто мониторинг и система должна быть выстроена таким образом, что все это быстро и эффективно доводится до нормального состояния в первые часы или дни после релиза, а не бахнуло через неделю месяц
Идея “дежурного программиста” понятная, но у нее есть неочевидные проблемы. Такой подход снимает ответственность с тех, кто делал фичи и что-то не додумал/не доделал, что привело к проблеме. Соответственно ребята гораздо меньше критически оценивают то что делают. Если поменять подход и чинить это силами тех, кто отвечает за эту фичу как ее главный реализатор, то вначале да, может быть отвлечение, но постепенно люди поймут что им же потом придется расхлебывать, а значит не надо доводить. Плюс это еще и хорошая метрика, у кого чаще так ломается, к тому вопросики, все ли хорошо по тестам, по процессам и так далее.
Плюс у вас будет более правильная оценка реальной производительности. Так как велосити уменьшится и будет точнее показывать, что команда часто косячит так, что приходится постоянно штопать то что уже на проде. И лучше такое не прятать за дежурного, а наоборот, сделать так чтобы ваша система подсвечивала подобные проблемы
в нормальной ситуации проблем что сломалось и прямо щас надо бежать чинить не должно быть много на уровне фич. Маркетинг бывает да, инфраструктура может сбойнуть, но не фичи в чистом виде. Это значит что реально есть косяки в процессе производства. Что кстати не значит что там тестировщиками и стейджингами обкладываться. Релизить можно часто и с косяками, просто мониторинг и система должна быть выстроена таким образом, что все это быстро и эффективно доводится до нормального состояния в первые часы или дни после релиза, а не бахнуло через неделю месяц
💘6👍4🔥3❤1🤔1
Интересное наблюдение про питон. Если посмотреть графики популярности языков программирования, то складывается что питон один из самых востребованных языков программирования на земле. Обычно это связывают с его простотой, комьюнити, заточенностью на бизнес-задачи, универсальностью, популярностью в среде аналитиков и специалистов по искуственному интелекту и другим подобным вещам.
На самом деле, большинство пунктов так же применимо и к другим языкам. Большая их часть универсальна, так же проста (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
На самом деле, большинство пунктов так же применимо и к другим языкам. Большая их часть универсальна, так же проста (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
👍23❤4🤔1
Отличный рост до 500 человек за буквально один пост :) Раз уж мы тут собрались. Расскажите плс в комментариях чем вы занимаетесь и какую профессиональную цель вы перед собой ставите в плане развития. И опрос: Что вам интереснее
Anonymous Poll
27%
Инфраструктура, DevOps
28%
Тимлидерство, Команды, Процессы
18%
Бизнесовая сторона вопроса
15%
Автоматизированное тестирование
81%
Качественный код, архитектура проекта
35%
Базы данных, проектирование
3%
Другое (напишу в комментах)
🤔2
Вы когда нибудь слышали про оптимистические и пессимистические блокировки? Тема о которой говорят редко, но с которой мы сталкиваемся по работе каждый день. Понимание этих видов блокировок, часто оказывается ключевым, для принятия правильного решения в построении архитектуры кода как в бекенде так и во фронтенде.
В двух словах: при конкурентном доступе к ресурсу, например, одновременной правке, могут возникнуть проблемы. Если открыть один файл в двух разных редакторах и после этого поправить в одном, то изменения во втором редакторе перепишут изменения сделанные в первом (если это не слишком умные редакторы), что будет крайне неприятно. Чтобы такого не происходило, нужно вводить блокировки.
Самый яркий пример применения блокировок это контроль версий. Одна из первых систем контроля версий RCS не позволяла одновременно работать над файлом. Если кто-то начинал править файл с кодом, то другие программисты физически не могли начать править файл, так как он блокировался. Такой подход называется пессимистической блокировкой. Git же (как и svn и cvs) работают по другому принципу. Они позволяют править код одновременно, но во время фиксации изменений, отслеживают предыдущие изменение и если его находят то запрещают сливать файл, заставляя выполнить ручное слияние (если необходимо). Такой подход называется оптимистической блокировкой.
Где мы с этим встречаемся как программисты? Во всех местах где есть возможность одновременной работы. Представьте любой CRUD на сайте. Например у вас есть команда редакторов, которая публикует посты в блоге. Что произойдет если два редактора решили поправить одну статью одновременно? Если ничего специально не делать, то работает схема “кто последний тот и папа”. Чтобы решить эту проблему можно реализовать одну из этих блокировок.
Какая блокировка изображена на картинке в начале поста? :)
В вашей практике была задача реализации подобной блокировки?
В двух словах: при конкурентном доступе к ресурсу, например, одновременной правке, могут возникнуть проблемы. Если открыть один файл в двух разных редакторах и после этого поправить в одном, то изменения во втором редакторе перепишут изменения сделанные в первом (если это не слишком умные редакторы), что будет крайне неприятно. Чтобы такого не происходило, нужно вводить блокировки.
Самый яркий пример применения блокировок это контроль версий. Одна из первых систем контроля версий RCS не позволяла одновременно работать над файлом. Если кто-то начинал править файл с кодом, то другие программисты физически не могли начать править файл, так как он блокировался. Такой подход называется пессимистической блокировкой. Git же (как и svn и cvs) работают по другому принципу. Они позволяют править код одновременно, но во время фиксации изменений, отслеживают предыдущие изменение и если его находят то запрещают сливать файл, заставляя выполнить ручное слияние (если необходимо). Такой подход называется оптимистической блокировкой.
Где мы с этим встречаемся как программисты? Во всех местах где есть возможность одновременной работы. Представьте любой CRUD на сайте. Например у вас есть команда редакторов, которая публикует посты в блоге. Что произойдет если два редактора решили поправить одну статью одновременно? Если ничего специально не делать, то работает схема “кто последний тот и папа”. Чтобы решить эту проблему можно реализовать одну из этих блокировок.
Какая блокировка изображена на картинке в начале поста? :)
В вашей практике была задача реализации подобной блокировки?
👍24❤1🔥1🤔1
Месяц назад я выступал (удаленно) на конференции CodeFest с докладом: “5 проектов выходного дня, которые значительно повысят ваши навыки кодинга”. Фактически он был посвящен тому, как прокачать свои навыки и стать более крутым инженером. Там я привел в пример типичный подход, который есть в голове примерно у всех разработчиков:
Все это полезно, но не очень сильно помогает прокачаться в архитектуре (хотя функциональные языки в этом плане таки неплохо помогают). И я предложил другую схему, которую использовал для себя и своей команды еще в 2011 году:
Почему так? Потому что в современном мире мы работаем в границах фреймворков, которые за нас многое решили. У программистов складывается ощущение что они понимают происходящее и держат все под контролем. Но правда заключается в том, что если у программистов отобрать фреймворк, то мало кто из них сможет начать использовать правильные подходы и техники, так как все это было черным ящиком.
В докладе я предложил 5 проектов, которые можно сделать буквально за 2-5 часов. Посмотрите, не пожалете https://www.youtube.com/watch?v=X1GsnskqQ14
Какой из проектов вы бы реализовали?
• Глубже изучить язык и фреймворк. • Изучить новый язык и фреймворк • Прокачать алгоритмы • Фронт => бек, бек => фронтВсе это полезно, но не очень сильно помогает прокачаться в архитектуре (хотя функциональные языки в этом плане таки неплохо помогают). И я предложил другую схему, которую использовал для себя и своей команды еще в 2011 году:
• Разработать свою библиотеку • Разработать свой фреймворк • Разработать инструмент (базу, веб-сервер, очереди) • Написать свой язык программированияПочему так? Потому что в современном мире мы работаем в границах фреймворков, которые за нас многое решили. У программистов складывается ощущение что они понимают происходящее и держат все под контролем. Но правда заключается в том, что если у программистов отобрать фреймворк, то мало кто из них сможет начать использовать правильные подходы и техники, так как все это было черным ящиком.
В докладе я предложил 5 проектов, которые можно сделать буквально за 2-5 часов. Посмотрите, не пожалете https://www.youtube.com/watch?v=X1GsnskqQ14
Какой из проектов вы бы реализовали?
YouTube
Кирилл Мокевнин. 5 проектов выходного дня, которые значительно повысят ваши навыки кодинга
Программисты часто работают только в рамках фреймворков, которые используются на рабочем месте. Это может приводит к стагнации архитектурных навыков, так как за нас уже обо всем подумали. Фреймворк определяет архитектуру, сообщество дает наработанные практики…
❤38👍24🤔2🔥1😱1
Семантика (то есть смысл) функций или методов в программировании сильно влияют на легкость его чтения и даже наличие скрытых багов. Что это такое?
Представьте себе функцию, которая называется showResult(). Что она делает? Большинство разработчиков глядя на нее подумает, что эта функция печатает что-то на экран, так как в начале стоит слово “show”. При правильном проектировании, так и было бы, но проверяя проекты Хекслета я встречал такой код: const content = showResult(). Здесь я испытываю wtf, так как названия говорят об одном, а реальная инструкция о другом. Может эта функция одновременно возвращает результат и печатает его на экран? Возможно и такое. Из-за этого приходится дополнительно смотреть в код вокруг и вглубь, чтобы понять что же происходит.
Этот же подход важен и в обратную сторону, когда мы используем существующие методы и функции по назначению. Прекрасный пример это метод pop() у массивов в JS и других языках. По своему смыслу он работает с массивом как с очередью, удаляя и возвращая последний элемент в массиве. На практике же, его часто используют для того чтобы взять последний элемент: if (items.pop() === ‘some value’) … По смыслу этот код просто хочет проверить последний элемент (если это не так, то нужно разделять действия). Он иногда прокатывает, когда этот массив больше не используется дальше по коду. Но если предположить, что код может быть дописан, то программист с удивлением обнаружит что в массиве вдруг пропал элемент. Потом он конечно найдет эту строчку и поправит код на items.at(-1) (новый способ взять последний элемент в массиве).
Расскажите про примеры вашего кода, когда названия не соответствовали смыслам и к чему это приводило.
Представьте себе функцию, которая называется showResult(). Что она делает? Большинство разработчиков глядя на нее подумает, что эта функция печатает что-то на экран, так как в начале стоит слово “show”. При правильном проектировании, так и было бы, но проверяя проекты Хекслета я встречал такой код: const content = showResult(). Здесь я испытываю wtf, так как названия говорят об одном, а реальная инструкция о другом. Может эта функция одновременно возвращает результат и печатает его на экран? Возможно и такое. Из-за этого приходится дополнительно смотреть в код вокруг и вглубь, чтобы понять что же происходит.
Этот же подход важен и в обратную сторону, когда мы используем существующие методы и функции по назначению. Прекрасный пример это метод pop() у массивов в JS и других языках. По своему смыслу он работает с массивом как с очередью, удаляя и возвращая последний элемент в массиве. На практике же, его часто используют для того чтобы взять последний элемент: if (items.pop() === ‘some value’) … По смыслу этот код просто хочет проверить последний элемент (если это не так, то нужно разделять действия). Он иногда прокатывает, когда этот массив больше не используется дальше по коду. Но если предположить, что код может быть дописан, то программист с удивлением обнаружит что в массиве вдруг пропал элемент. Потом он конечно найдет эту строчку и поправит код на items.at(-1) (новый способ взять последний элемент в массиве).
Расскажите про примеры вашего кода, когда названия не соответствовали смыслам и к чему это приводило.
👍29🤔1
Не скрамом единым
Слова agile и scrum в разработке стали чем-то вроде культа карго. Что ни компания, то scrum. В свое время я тоже сильно упарывался и внедрял скрам, плюс работал в компании где это внедрение проходило сквозь меня (а это был skype/microsoft). И у меня есть что сказать по этому поводу.
Когда 10 лет назад я подключится к Хекслету, то было сразу решено адаптировать процессы под то как удобно нам. Например мы не стали вводить спринты, так как на таком небольшом объеме и малой команде они были не просто избыточными, но и создавали проблемы. Нам надо было делать то, что надо делать прямо сейчас и деплоить пока оно еще не сделано. Демо дни в такой система в принципе не нужны, я работаю рука об руку с командой. Митинги, при этом, мне, в целом, заходили если без фанатизма, но мне никогда не нравился формат встали в круг и укладываемся в 5 минут, поэтому мы внедрили асинхронные митинги в слаке, причем не только для разработки, но и вообще для всей команды, включая весь маркетинг и разработку курсов. Понятия скрам-мастера и продукт оунера из скрама вообще не ложились на нашу команду. За продукт в компании отвечал я сам, любое промежуточное звено бы сделало только хуже из-за большего количества коммуникаций, а на размере в 2 разработчика скрам-мастер ну никак не нужен.
Было довольно забавно, что немало людей которые тогда слышали от меня про такую структуру, говорили о потенциальном будущем с десятками разработчиков и тем, что такая система не заработает и что надо прямо сейчас все менять и следовать заветам старших. На что я резонно замечал, что если у меня будут деньги нанять 10 разработчиков, то мы и с этим справимся. По прошествии 10 лет, команда разработки состоит из 7 человек включая СТО. У нас по прежнему нет не то что скрам-мастера, продакт-оунера, даже проджектов нет (в маркетинге есть, в разработке нет).
Но за это время мой опыт не ограничивался лишь только Хекслетом. Я регулярно занимался консалтингом крупных компаний и даже входил в agile-команду тренеров (я отвечал за инженерную культуру) в крупной компании петер-сервис, где только команд разработки было более 70 штук. Там мы внедрялись в команды и помогали им решать их проблемы. Кстати из-за этого я в 2017 году жил в Питере.
И мой вывод после всего этого наверное такой. Все эти способы организации имеют внутри себя классные механики, которые в большинстве своем существовали и без них и до них. Например проектная организация с кросс-функциональными командами это не изобретение скрама или те же карточки или визуализация. И все это имеет смысл использовать если вы понимаете какую проблему конкретно у вас решает эта штука. Но полное следование этому фреймворку даже с учетом адаптации под себя (помним что скрам это не методология), актуально скорее только для крупных компаний, в которых сложная, медленная, бюрократичная структура внутри. Там скрам однозначно принесет пользу.
p.s. Поделитесь своим опытом. Вы разделяете эту точку зрения иль нет?
Слова agile и scrum в разработке стали чем-то вроде культа карго. Что ни компания, то scrum. В свое время я тоже сильно упарывался и внедрял скрам, плюс работал в компании где это внедрение проходило сквозь меня (а это был skype/microsoft). И у меня есть что сказать по этому поводу.
Когда 10 лет назад я подключится к Хекслету, то было сразу решено адаптировать процессы под то как удобно нам. Например мы не стали вводить спринты, так как на таком небольшом объеме и малой команде они были не просто избыточными, но и создавали проблемы. Нам надо было делать то, что надо делать прямо сейчас и деплоить пока оно еще не сделано. Демо дни в такой система в принципе не нужны, я работаю рука об руку с командой. Митинги, при этом, мне, в целом, заходили если без фанатизма, но мне никогда не нравился формат встали в круг и укладываемся в 5 минут, поэтому мы внедрили асинхронные митинги в слаке, причем не только для разработки, но и вообще для всей команды, включая весь маркетинг и разработку курсов. Понятия скрам-мастера и продукт оунера из скрама вообще не ложились на нашу команду. За продукт в компании отвечал я сам, любое промежуточное звено бы сделало только хуже из-за большего количества коммуникаций, а на размере в 2 разработчика скрам-мастер ну никак не нужен.
Было довольно забавно, что немало людей которые тогда слышали от меня про такую структуру, говорили о потенциальном будущем с десятками разработчиков и тем, что такая система не заработает и что надо прямо сейчас все менять и следовать заветам старших. На что я резонно замечал, что если у меня будут деньги нанять 10 разработчиков, то мы и с этим справимся. По прошествии 10 лет, команда разработки состоит из 7 человек включая СТО. У нас по прежнему нет не то что скрам-мастера, продакт-оунера, даже проджектов нет (в маркетинге есть, в разработке нет).
Но за это время мой опыт не ограничивался лишь только Хекслетом. Я регулярно занимался консалтингом крупных компаний и даже входил в agile-команду тренеров (я отвечал за инженерную культуру) в крупной компании петер-сервис, где только команд разработки было более 70 штук. Там мы внедрялись в команды и помогали им решать их проблемы. Кстати из-за этого я в 2017 году жил в Питере.
И мой вывод после всего этого наверное такой. Все эти способы организации имеют внутри себя классные механики, которые в большинстве своем существовали и без них и до них. Например проектная организация с кросс-функциональными командами это не изобретение скрама или те же карточки или визуализация. И все это имеет смысл использовать если вы понимаете какую проблему конкретно у вас решает эта штука. Но полное следование этому фреймворку даже с учетом адаптации под себя (помним что скрам это не методология), актуально скорее только для крупных компаний, в которых сложная, медленная, бюрократичная структура внутри. Там скрам однозначно принесет пользу.
p.s. Поделитесь своим опытом. Вы разделяете эту точку зрения иль нет?
👍25❤🔥8💯4💩2🤔1