Итак поехали) Меня зовут Кирилл Мокевнин и я занимаюсь разработкой с 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

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

Семантика (то есть смысл) функций или методов в программировании сильно влияют на легкость его чтения и даже наличие скрытых багов. Что это такое?

Представьте себе функцию, которая называется showResult(). Что она делает? Большинство разработчиков глядя на нее подумает, что эта функция печатает что-то на экран, так как в начале стоит слово “show”. При правильном проектировании, так и было бы, но проверяя проекты Хекслета я встречал такой код: const content = showResult(). Здесь я испытываю wtf, так как названия говорят об одном, а реальная инструкция о другом. Может эта функция одновременно возвращает результат и печатает его на экран? Возможно и такое. Из-за этого приходится дополнительно смотреть в код вокруг и вглубь, чтобы понять что же происходит.

Этот же подход важен и в обратную сторону, когда мы используем существующие методы и функции по назначению. Прекрасный пример это метод pop() у массивов в JS и других языках. По своему смыслу он работает с массивом как с очередью, удаляя и возвращая последний элемент в массиве. На практике же, его часто используют для того чтобы взять последний элемент: if (items.pop() === ‘some value’) … По смыслу этот код просто хочет проверить последний элемент (если это не так, то нужно разделять действия). Он иногда прокатывает, когда этот массив больше не используется дальше по коду. Но если предположить, что код может быть дописан, то программист с удивлением обнаружит что в массиве вдруг пропал элемент. Потом он конечно найдет эту строчку и поправит код на items.at(-1) (новый способ взять последний элемент в массиве).

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

Не скрамом единым
Слова agile и scrum в разработке стали чем-то вроде культа карго. Что ни компания, то scrum. В свое время я тоже сильно упарывался и внедрял скрам, плюс работал в компании где это внедрение проходило сквозь меня (а это был skype/microsoft). И у меня есть что сказать по этому поводу.

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

Было довольно забавно, что немало людей которые тогда слышали от меня про такую структуру, говорили о потенциальном будущем с десятками разработчиков и тем, что такая система не заработает и что надо прямо сейчас все менять и следовать заветам старших. На что я резонно замечал, что если у меня будут деньги нанять 10 разработчиков, то мы и с этим справимся. По прошествии 10 лет, команда разработки состоит из 7 человек включая СТО. У нас по прежнему нет не то что скрам-мастера, продакт-оунера, даже проджектов нет (в маркетинге есть, в разработке нет).

Но за это время мой опыт не ограничивался лишь только Хекслетом. Я регулярно занимался консалтингом крупных компаний и даже входил в agile-команду тренеров (я отвечал за инженерную культуру) в крупной компании петер-сервис, где только команд разработки было более 70 штук. Там мы внедрялись в команды и помогали им решать их проблемы. Кстати из-за этого я в 2017 году жил в Питере.

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

p.s. Поделитесь своим опытом. Вы разделяете эту точку зрения иль нет?

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

1. Настройки фреймворка которые меняют его поведение
2. Файловая структура, которая отличается от заложенной в инструмент
3. Использование не стандартных расширений
4. Кастомизация линтера, отключение правил, потому что не согласны
5. Использование своих решений, вместо готовых, заложенных в инструмент
6. и т.п.

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

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

Где-то в 2010 году, я решил попробовать разработку в Vim, так как мой ноутбук не тянул netbeans да и я слышал, что крутые ребята им пользуются. К вопросу тогда я подошел очень серьезно, сразу стало понятно, что вимом нельзя начать пользоваться просто так, нужно потратить время на понимание его концепций и перестроить свое мышление. Поэтому я принудительно запретил себе идти поперек его подходов, например, не использовал стрелочки. Как это было тяжело, первые две недели я хотел все бросить, так как моя производительность упала почти до нуля. Меня немного спасало то, что я отлично владею слепым набором на обоих раскладках, но все равно было сложно.

С тех пор прошло 13 лет и настройка вима, в сумме заняла недели три, а то и месяц моей жизни. Кто-то скажет что это много, но для меня настройка вима это не просто задача, которую надо делать иначе не сможешь пользоваться редактором. В какой-то момент, особенно когда я стал меньше программировать, настройка вима для меня стала чем-то вроде похода в гараж для моего деда. Я просто испытываю невероятный кайф от того, что обновляю все по последним веяниям и вим преобразуется на глазах. За эти годы он конечно прошел большой путь и вся концепция суммарно менялась раза 4-5 с почти полным изменением набора плагинов.

Кстати, я переодически таки пробую другие редакторы, смотрю что там есть и как с этим работать. Причем речь не только про VScode или Intellij. Одно время я изучал emacs, и научился эффективно работать со spacemax. Но все равно, каждый раз понимаю что не могу, вим удобнее и это единственный редактор, в котором есть ощущение рыбы в воде. Клавиатура в этот момент ощущается как продолжение моих рук.

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

В любом случае если вы задумывались об этом или хотите что то полезное почитать, то вот мой список:

Гайд о философии вима https://guides.hexlet.io/ru/vim/
Тред про мой опыт использования и рекомендации по изучению https://twitter.com/mokevnin/status/1567594899859546115

А как вы относитесь к виму? Или пробовали emacs?

Функциональное ядро, императивная оболочка
Пожалуй, самый фундаментальный принцип программирования. Концепция очень простая, код с логикой нужно оставлять как можно более чистым, вынося побочные эффекты наружу в начало и конец выполнения программы.

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

const linter = new Linter(/* сюда передаем набор правил /*);
const result = linter.lint(‘список файлов’);

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

• Сложнее тестировать. Вам нужны не только исходные файлы с проблемным кодом, но и место для записи выходных файлов, которые должны стираться после каждого перезапуска тестов
• Код завязан на файлы, хотя смысловая часть линтера не работает с файлами, она работает со строками. Мы не сможем просто так подключить туда любой другой источник, например сеть. В случае js мы не сможем запустить линтер в браузере.
• Работа с файлами сразу добавляет задачу по работе с файловыми исключениями

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

const linter = new Linter(/* сюда передаем набор правил /*);
const filesData = readFiles(); // С учетом исключений и добавлением метаданных
const result = filesData.map((data) => linter.lint(data));

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

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

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

Как становятся более крутыми инженерами

Знаете как часто это бывает, когда разработчики говорят что мой код, который я написал полгода назад сейчас выглядит отвратительно. Знакомо? Через это проходят все, кто так или иначе начинает заниматься разработкой и нарабатывает опыт в свои первые годы. Но сколько это может продолжаться?

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

Смотря назад, я понимаю что поворотным моментом в моей карьере стал период, когда я увлекся функциональными языками и курсом СИКП, по которому потом во многом строилось обучение на Хекслете. Произошло это так, я видел что вокруг меня, многие профессионалы, говорят и используют функциональные языки и какие-то связанные с этим подходы. В тот момент речь шла про erlang, scheme/racket (для сикпа), clojure и haskell, которые я в разной степени начал изучать. На эрланге даже получилось сделать проект codebattle.hexlet.io, который потом, спустя много лет переписали на elixir (это опенсорс).

Изучение этих языков многое перевернуло в моей голове и дело даже не в том что они функциональные, а в том, что в среде программистов на этих языках поднимались вопросы, с которыми я раньше не сталкивался. Я понял что смотрел на разработку не на том уровне. Весь мой предыдущий опыт был скорее в стиле вот чистый код, вот мартин, вот фаулер, вот ООП, вот паттерны. Как оказалось, несмотря на здравые мысли в этой части, все же это была оболочка, а не фундамент. А фундамент лежал в таких областях как управление состоянием, изоляция побочных эффектов, конечные автоматы, statefull/stateless части системы и тому подобное.

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

p.s. рекомендую прочитать отзыв о сикпе http://vshabanov-ru.blogspot.com/2007/03/sicp.html