хэллоуворлд | софтвэер инжениринг

Совет джунам не выглядеть лохами На работе мы сталкиваемся с непонятными задачами. И непонятные они всегда в независимости от уровня. И это абсолютно нормально. А еще нормально приходить к коллегам за помощью. Я делаю это каждый день. Этому подходу к решению жопы я научился в диких джунглях Школе 21. Вот рецепт: - RTFM - Погугли - Спроси AI - Спроси соседа слева - Спроси соседа справа - Если проблема не решилась, поменяй место и повтори заново Этот способ помогает не выглядеть глупым, когда приходишь к коллегам. Вопрос обычно выглядит так: «Слушай, я не могу сделать Х. Почитал, попробовал Y, Z. ЧЯДНТ???» Используйте, благодарите, подписывайтесь 🫡

Страдающая айтишка Недавно я получил удовольствие от удаления пачки функции и тестов к ним. Больше удовольствия, чем во время их написания. Кроме меня удовольствие получил и бизнес. Задача решена, кода на поддержку стало меньше, общая сложность кодовой базы снизилась. Но так бывает не всегда. Часто слышу от продакта жалобы о «разработке, которая ничего не хочет менять». Разработка страдает от «продакта, который меняет бизнес требования раз в квартал». Никто не получает удовольствие. Как бы нам этого не хотелось, коллеги, но проблема не в продактах. Проблема в том, как мы воспринимаем свою работу. Мы видим себя инженерами-изобретателями — описываем все в расчетах и схемках, а потом реализуем. Критерии успеха — работающее изобретение. True or False. На самом деле мы ближе к писателям и художникам. Как писатели удаляют и переписывают, так и мы удаляем и рефакторим. Как художники перерисовывают с эскиза, так и мы масштабируем мвп решения на коленке. На курсах и в универах не учат редактировать код. Учат только писать с нуля. Вот и получаем нашу родную страдающую айтишку 😫

Почему веб пошел по пути усложнения и добавления дополнительных сериализации в json? 99% веб приложений вполне могли обойтись без дополнительной сериализации. А главное для бизнеса — вторая схема дешевле во всех понятиях: разработки, вычислительных мощностей. В идеале все может быть сделано на одном технологическом стэке. Ну а микросервисы приходят с ростом команд (даже не нагрузки!).

Фронтенд для бэкендера — htmx Бэкенд для фронтендера — nextjs/sveltekit Вот и думайте сами, что происходит в мире веб разработки))

Про транзишн в другой пол язык Через неделю врываюсь на работу с Go. До этого я немного ковырялся с ним, но в этот раз подошел к изучению БАЗЫ. Все равно руку набью уже на работе, а теорию надо почувствовать. Чем больше встречаюсь с разными языками, тем больше вижу параллель языков программирования и религии. Все религии про одно и то же. Собственно как и языки программирования про одно и то же — перекладывание циферок туда сюда. Но отличия в том, как этого добиваются. Go не дает шансов выстрелить себе в ногу, проектируя код. Нет ООП, by design нет наследования и других вариантов усложнить себе жизнь. Ну и языковых конструкций гораздо меньше, чем в других языках. Чем больше человек знает про разные культуры, языки и религии, тем он интереснее и способнее понимать другие точки зрения. Так же и с инженером, который знает несколько языков программирования. Не зря холивары про языки программирования сравнивают с религиозными))

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

Про ORM Заметил, что в пайтон коммьюнити большинство любит ормки. Особенно если речь про ДжангоОРМ. В го коммьюнити большинство любит голый скуль и дико хейтят все ормки. Как так вышло, что инженеры делают одно и то же на разных языках, но имеют такие ярые противоречия в вопросе общения с базой и сериализация в языковую структуру этих данных? Не знаю. Я больше на стороне гоферов. Орм делает простые вещи проще, а сложные еще сложнее. Лишняя абстракция над уже существующим языком общения с базой. Действительно ли так сложно написать несколько чистых sql запросов для своего круд приложения?

💻 Питонисты разлогинтесь, не только в js появляются новые фреймворки https://www.evpetrovich.ru/posts/litestar-introduction/

🚀 Готовы улучшить свои навыки работы с текстом? Пора попрощаться с мышью и стрелками. evpetrovich.ru/posts/vim-motions-movements/

Не обязательно использовать vim, обязательно использовать vim motions Уйдем от холивара про текстовый редактор. Примем, что vscode популярен и действительно хорош. Моя претензия заключается в том, как мы редактируем текст внутри этого редактора. Поэтому призываю всех использовать vim motions. Да, их можно скачать плагином для vscode. Помните, ребята, vim может показаться трудным в освоении, но, по крайней мере, это приносит больше удовлетворения, чем изучение нового js-фреймворка каждые несколько месяцев. Помните об этом, когда не будете понимать, как сдвинуться на строчку вниз. Vim предлагает несколько режимов, включая обычный, вставку, визуальный и командный, что обеспечивает молниеностное редактирование и навигацию. Вот вам план действий для начала: - Сначала нужно развить новые нейрончики и мышочную память, чтобы вместо стрелочек тыкать hjkl — тренируемся тут. По итогу мы должны уметь свободно перемещаться по текстовому файлу. - Учимся понимать различные режимы normal, visual, insert, command. После этого можно уже не только бегать по файлу, но и что-то писать. - Учимся копировать, вставлять, удалять, прыгать вертикально и горизонтально. - Дальше уже копаем глубже в зависимости от желания, пишем свои шорткаты, команды. Будет трудно, но я обещаю, что это стоит того. Прокачивайте мозг новыми механическими движениями. Следующими будут несколько коротких туториалов по погружению в vim motions.

Начинайте учить vim motions С vim motions можно легко удалять до какого-то определенного знака. Супер удобно это может быть, например, при удалении части слов в кавычках: жмакаешь dt" и все удаляется. Либо удобно до определенного пробела dt<space>. В обычных редакторах пришлось бы несколько раз прыгать альтом по словам и удалять, либо сначала выделять, а потом удалять. На самом деле, применение вимовских шорткатов это не про хваставство и ощущение себя крутым хакером, хотя этот вторичный эффект достаточно приятный для эго. Это про использование инструментария текстового редактора на максимум. Программисты пишут символы так же, как столяр использует рубанок. Для качественного выполнения работы нужен не только хороший инструмент, но и безупречное знание этого инструмента. Подробнее про это в следующих заметках.