Как на самом деле работает профессиональный рост

Представьте что вы нанимаете разработчика, у которого 5 лет опыта. На вопрос о том, пишет ли он тесты к коду (любые), он говорит нет, объясняя это тем, что где-бы он ни работал, везде не было времени и возможности этим заняться. При этом он наверняка скажет, что-то в духе “а я так хотел чтобы тесты были”, просто потому что это вроде как считается правильным. Какие выводы вы для себя сделаете в этой ситуации?

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

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

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

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

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

Помните я недавно делал подборку вопросов для трудоустройства? Тот тред хорошо зашел, поэтому пробуем еще раз. В этот раз со спецификой под конкретную тему:

1. Предположим что вам надо раздавать большие файлы из приложения (а не напрямую через nginx). Как это организовать так, чтобы файлы не забивали память?
2. Раздаваемые файлы должны иметь ограничения на уровне приложения, например владение определенным пользователем. Как реализовать подобную авторизацию?
3. Как организовать хранение загруженных файлов на диске? Проблема в том что их нельзя просто так складывать в какую-то папку, потому что при большом количестве, чтение таких директорий начнет сильно тормозить.
4. Как бы вы организовали генерацию Thumbnails для загружаемых картинок? Уточнение: читают в 10 раз чаще чем грузят. Размеры картинок регулярно меняют так как меняется дизайн.
5. Как бы вы подходили к вопросу ускорению скорости загрузки и более эффективному использованию каналов, если бы ваши файлы часто скачивали в физически удаленных локациях? Хотя бы общие принципы

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

I wrote about how this model compares to SPA six years ago and those are still my thoughts today. SPA offers potentially great responsiveness at an excruciatingly high cost. In recent years, I've heard countless first-hand stories of products failing to launch because of some SPA horror story. The real world is all about cost/benefit, and plenty of shops choose – knowing it or not – to ignore cost when picking their stacks. As sad as it is, this gives Rails and Hotwire programmers a tremendous edge.

Software development is full of merchants of complexity. They will tell you about great engineering practices and how to optimize for the local, but they never stop to discuss cost/benefit or how the system as a whole will suffer. The recent debate was a great showcase of such a way of thinking.

I saw the term engineering used a lot in this debate. Here's my hot take: an engineer who overlooks costs is a bad one!

Mind the cost-ignorers.

Подробнее тут: https://world.hey.com/jorge/the-popover-drama-48e317b3

Вышел еще один подкаст с моим участием https://youtu.be/IFPY_VMRCQ4?si=jqL9HEHlcl0lclB5 поболтали с ребятами про обучение и образование

Next.js подход для больших фреймворков

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

Недавно я зарелизил проект по приемке абитуриентов в наш колледж написанный с помощью этого подхода. В качестве бекенд фреймворка там используется Laravel (PHP), а в качестве фронтенда не встроенный шаблонизатор blade, а Inertia.js (https://inertiajs.com/) клей, который прозрачно соединяет бекенд с фронтендовым фреймворком на выбор, в нашем случае React, но мы могли бы легко использовать и Vue.

Бекенд, в такой схеме работает почти на 100% как если бы мы использовали классическую серверную шаблонизацию.

public function create(): Response
{
    $college = new College;

    return $this->render(['college' => $college]);
}

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

Эти данные автоматически прокидываются в клиентские компоненты отвечающие за соответствующие экшены.

type EditPageProps = PageProps<{ college: College }>

export default function Edit({ college }: EditPageProps) {
  const { props: { scope } } = usePage<SharedProps>()

Кроме прочего, Inertia.js дает кучку разных вспомогательных инструментов, например хук useForm который знает как работать с бекендом на Laravel, что дает автоматический захват ошибок и вот это все.

Но даже в таком подходе иногда нужен API, например для автокомплитов. Inertia.js и Laravel этому никак не мешают, всегда можно добавить любое API.

Ребят, есть возможность вложиться в опенсорс без боли. Есть такой проект для склонения имен в русском https://github.com/petrovich/petrovich-php но версия на php устарела. Нам в проекте она нужна, поэтому придется делать форк и добавлять туда composer. Задачка очень простая для современных PHP разработчиков. Если есть желание, бахните плс это дело и отправьте им пулреквест. А мы воспользуемся вашей форкнутой версией, пока они не примут реквест.

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

Серверная шаблонизация
После того как я написал про inertia.js, несколько людей спросило у меня, в чем же собственно крутость такого подхода? И действительно, получается так, что в современном мире много разработчиков, которые плотно не писали на классическом клиент-серверном MVC (его еще называют MVC model 2, потому что обычный MVC это как раз толстый клиент и событийная архитектура).

Исправляюсь. Опишу тут то, чего мы лишились и чего не хватает при переходе в режим SPA, когда у нас есть отдельно бек с API и приложение на клиенте.

Небольшой ликбез. Классическая серверная шаблонизация хотя технически и является серверным рендерингом SSR, но эти понятия не стоит смешивать, потому что под SSR понимают именно рендеринг JS кода, например компонентов React. А серверная шаблонизация подразумевает использование шаблонизаторов, написанных под тот язык, на котором пишется бекенд. Внутри этих шаблонов используется либо такой же язык, либо очень похожий. Например в этом смысле, PHP сам является шаблонизатором, так как в исходниках позволяет мешать себя с html.

В чем же плюсы?

SEO

Сео стало проблемой для программистов только с появлением SPA :)

Производительность

Максимальная. Это просто html с сервера

Цена (Один программист)

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

Скорость разработки

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

• Не нужно создавать api (!!!)
• Стейт только один и он в базе (!!!)
• Интеграция с самим фреймворком, многие вещи делаются автоматически, типа обработка и вывод форм
• Отсутствие дублирования логики так как нет отдельного фронтенда
• А еще посмотрите на haml-like шаблоны, я по ним скучаю

В общем и целом, скорость с которой создавались и создаются (на хекслете так) страницы и формы в такой форме, недосигаема для отдельного фронтенда, особенно если это SPA

Тестирование

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

Тогда почему от них ушли если все так сладко? Многие проекты требуют высокого уровня интерактивности, по сути многие современные сайты, это полноценные приложения (толстые клиенты) в браузере. Серверная шаблонизация тут не поможет, она stateless и это просто html который генерит сервер.

Домашнее задание: пройдите getting started на rails, чтобы заценить как это работает

Боже мой, это случилось. Первый выпуск на моем канале, который монтировали 4 месяца (хаха) https://www.youtube.com/watch?v=wnz5E6Vxfd4 Смотри, залетай, лайкай, шарь!

Когда вы последний раз видели в глаза PHP? Узнаете этот синтаксис? Эх, опять курсы дописывать)

Я перестал использовать Copilot после 2 месяц. И вот почему

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

Сетап

За это время я использовал copilot в основном с двумя языками: php (laravel) и typescript (react). В качестве редактора nvim (сборка LazyVim на скрине). Писал и фронт и бек и тесты.

Что понравилось

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

Почему я остановился

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

Уменьшение продуктивности

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

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

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

Импорты

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

Ошибки

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

Итого

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

p.s. А где вас раздражает Copilot?

Чего не умеет AI и не факт что научится

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

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

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

Какой бекендовый фреймворк лучше?

Мне повезло поработать на большом количестве разных бекендовых фреймворков, среди них: django, rails, laravel, spring boot, phoenix, fastify и тонне микрофреймворков. Плюс пару фреймворков разработал сам, один из которых активно использовался в продакшене. Каждый из этих фреймворков обладает чем-то, что сделано лучше чем в других, но среди них нет ни одного, который бы сочетал все плюсы. Поэтому программисты, которые пишут на каком-то одном или двух фреймворках, могут даже не знать о том, что какие-то вещи можно делать по-другому.

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

Что где сделано классно?

• Rails - миграции, роутинг, шаблоны, соглашения вместо конфигурации, тесты, фикстуры, fsm, i18n, дебаг, консоль, генераторы
• Spring boot - orm, управление зависимостями
• Django - формы, админка
• Phoenix - мидлвары
• Laravel - клиентская шаблонизация через inertia.js, трансляция в ts, jobs

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

⁃ code first vs db first
⁃ active record vs data mapper
⁃ fillable поля и mass assigment
⁃ колбеки в orm

p.s. Какие темы интересны вам в этом ключе?

Ссылки: Телеграм | Youtube | Подкаст

Заблуждения программистов относительно адресов

Мы говорили о времени, теперь поговорим об адресах. Выдержка из прекрасной статьи https://www.mjt.iss.one.uk/posts/falsehoods-programmers-believe-about-addresses/

• Почтовые индексы всегда состоят из пяти цифр
• У адреса всегда есть почтовый индекс
• Улицы всегда имеют названия, а дома — номера
• У улиц всегда есть название
• В каждом городе есть только один уникальный адрес для каждого местоположения
• Почтовые адреса всегда включают название улицы и номер дома
• Номера зданий идут подряд
• Названия улиц не повторяются в одном городе
• Адрес включает только одну улицу
• В одной стране не может быть двух городов с одинаковыми названиями

Из моего личного опыта. Жил я некоторое время в славном городе Зеленограде (Это часть москвы за пределами москвы, как калининград). Так вот в этом городе у улиц нет названий, а номер дома однозначно определяет место в городе. Это супер удобно, только в онлайне на это мало кто рассчитывает, поэтому Зеленоградцы страдают)

Ссылки: Телеграм | Youtube | Подкаст

Как я положил продакшен базу на выходных
Вчера произошла эпическая история. После планового деплоя в субботу вечером (так было нужно), мне прилетело сообщение “кирилл, у нас почему-то не показываются заявки”. Наверное фильтры слетели, подумал я и пошел проверять. Фильтры не слетели. Я слегка напрягся и пошел в яндекс клауд посмотреть что там в базе. Как я и боялся, таблицы были пустыми. Причем не все, но многие. Самое интересное, что они были не просто пустыми, но у них сбросились счетчики.

Увидел я это не сразу после деплоя, поэтому было не до конца понятно, это деплой привел к удалению данных или что-то другое. Я быстро восстановил снепшот на новом кластере, благо это делается одним кликом и выполнил туда деплой заново. Какого было мое удивление, когда после деплоя база очистилась. Какого хрена подумал я, прикидывая, что могло быть причиной. В этот момент ко мне присоединился второй разработчик проекта, с которым мы весело провели 3 часа за дебагом.

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

Дальше мы полезли изучать код на предмет подозрительных вещей:

1. Логи
2. Изменения в конфигурации
3. Ишьюсы в Laravel (основной фреймворк)
4. Миграции

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

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

Открываем миграцию, а там тот самый пресловутый транкейт, который хоть и выглядел подозрительно, но не касался других таблиц. Смотрю в логи и вижу что транкейт выполняется так: TRUNCATE marketing_discounts CASCADE. И тут я как понял. Не знаю как так получилось, но я даже не был в курсе, что у трункейта есть такая опция. CASCADE приводит к тому, что дропаются все связанные таблицы (рекурсивно) независимо от того, есть ли там данные или нет. Сказать что я был в шоке, ничего не сказать. Тут же нашелся issues в ларавеле, где выяснилось несколько интересных деталей. Мы не единственные кто грохнул базу таким образом. Собственно сам issue появился с целью того, чтобы защитить всех остальных, на что разработчики сказали сорян, обратная совместимость. Самое смешное, что подобное поведение реализовано только для драйвера постгреса, у остальных такого нет.

When you truncate tables using the laravel illuminate db builder it truncates the table as expected. However, postgresql is different because it changes the DEFAULT behavior of truncate from RESTRICT to CASCADE. This means that you can loose all your data in other "related" tables (something that doesn't happen with the other sql drivers)

И ниже смешные комментарии в духе:

3 years passed, Laravel users still truncates their entire databases...

We were also a victim of this behavior this morning, fortunately we were on a test database. Very dangerous!

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

В итоге мы все поправили и восстановили данные, но открыли в себе новый страх. Давно в моей жизни не было таких приключений)

ишью: https://github.com/laravel/framework/issues/35157

Если вдруг пропустили, тут вышел подкаст подлодка про чистый код, где я срываю покровы и вспоминаю дядюшку Боба https://www.youtube.com/watch?v=3deXOXWlHeg хайли рекомендед!

Что такое чистый код?

По горячим следам хочу сделать саммари после выпуска, который породил вопросы: “так что же делать в итоге?”.

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

Но есть проблема, следованием этим вещам не делает ваш код классным, он может быть написан чисто, но при этом быть костылным/бажным/решать следствие а не причину/быть не нужным/дублироваться 100 раз. Поэтому качество кода важнее, чем его стилистическая чистота. Как сделать код качественным?

Универсальный совет такой:

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

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

Набор принципов и методик, которые стоит знать, но еще лучше понимать то, что за ними стоит:

⁃ Функциональное ядро, императивная оболочка
⁃ Программирование с явно выделенным состоянием
⁃ Предметно-ориентированное проектирование (DDD)
⁃ Чистота: Модели > Контроллеры > Вьюхи

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

p.s. А какие еще принципы вы бы добавили?

Ссылки: Телеграм | Youtube | Подкаст

У меня есть веселее история. В Badoo деплой был устроен так, что новые версии файлов докладывались на прод и менялась «карта» с актуальными файлами. Деплоили каждый день. Старые файлы удалялись кронами, проверкой по дате создания, через сколько-то дней. На новогодние праздники кроны потерли все файлы с прода, пока деплоя новых файлов не было…

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

А еще разок я забыл поменять контекст куба и в один проект влил другой, который нахрен угрохал все, что я потом пару часов восстанавливал

А какие у вас были веселые истории в продакшене? Как вы или ваши коллеги его ломали?